Possible FW/Driver Issue with the LZW31-SN

@EricM_Inovelli Looks like I may have found a firmware or driver issue with the LZW31-SN.

I was one of the people that was seeing the dimmer turn off when the dumb switch, in my 3 way, was in the one position and the dimmer was set to above 90%. I decided to upgrade the dumb switch, in the kitchen, to the suggested GE add on switch so that I could dim the lights from both switches. Well worth the $20 IMHO. The WAF went up and as was pointed out to me, ON is always up and off is always down… You know, the important stuff :wink: . Also, the problem with the dimmer turning off at over 90% stopped and is now behaving just like my single pole dimmers.

However, shortly after doing so, I saw this in my Hubitat logs:


It appears that after swapping the dumb switch to the add on, the (kitchen) dimmer is timing out on something and turning off the Info logging. This switch has been been installed since early November (pre-order time frame) and I haven’t seen this behavior until now. Also, after a few tests, it appears to be constantly happening 5-10 minutes after reporting the Energy levels. Power and Energy Reporting values for the switch are set to defaults. I’ve turned on Debug logging to see if I can get any additional information. But, that hasn’t revealed anything new.

Let me know if there is anything else you’d like me to try.

Edit:

Update:
So I turned the Info Logging back on, and saved my preferences for the switch. I wanted to confirm that the info logging was “on” so I scrolled to the bottom of the devices page for this dimmer and look what I saw at the bottom of the page:


And guess what happened to at 6:31:24am?

So somehow, it looks like the handler is scheduling this? How do I kill this? Better yet, how do I control it?

Inovelli appears to be following the Hubitat custom of disabling debug logging 30 minutes after it is enabled (and again, by custom, it is also enabled by default on a new device installation). This is to limit the amount of information that gets logged, both to marginally cut down on the load to the system and also make the “Past Logs” more usable so they won’t be so cluttered or hit their limit so quickly. Debug logging is normally only necessary to turn on when investigating a specific problem.

Where they appear to be going an extra step is disabling info logging (description text logging) after this timeout as well. That is not Hubitat custom. Again by custom, this will normally log things like attribute changes: on/off state of the switch, level of the dimmer, power consumption, etc. I would suggest to the driver author that they not automatically disable info logging. If you don’t want this to happen, you can manually edit the driver by removing this line, which is at 184 in the current version:

device.updateSetting("infoEnable",[value:"false",type:"bool"])

The message you’re seeing in your logs is not bad–it’s just telling you that this is happening. (Again, the wording is a bit different from Hubitat’s customary message in this case, but the idea is the same.)

In related news, Hubitat is supposed to be releasing a built-in driver for these in their next hub firmware release. No word on when or what features it will include. They will undoubtedly write it in a way that matches the Hubitat customs they’ve created, but since of those is also “double-tap max” I suspect we’ll have to use Inovelli’s custom drivers to get full use of the switch anyway. But who knows!

@BertABCD1234 I am currently using Inovelli’s driver. So what is REALLY weird, is that this dimmer uses the same driver as my other 2 red series dimmers. They are not disabling Info logging, ever. So the only things that were changed was a dumb switch, to an add on switch. I also changed the driver from a 3-way with a dumb switch to a 3-way with a momentary. At this point, I think I’ll exclude the switch, then include it back in and see if the behavior fixes itself.

Yes, I’ver heard that Hubitat will have an integrated driver. Hopefully, it’ll be fully featured. We’ll see.

The only difference I could think of is that I think the log disabling was added recently. If you’ve had the other switches for a while and then added this one after updating the driver, it’s possible the others never scheduled the disabling (but they should if you click “Save Preferences” at any future point).

I’m also looking forward to the Hubitat driver. Hope I’m not disappointed. :slight_smile:

Close! Just hitting “Save Preferences” doesn’t do it, I tried it with my remaining dimmers and the “LogsOff” event didn’t get scheduled. What I found is that you have to actually change a field/value in the preferences section and then save it. In my case, I changed the existing dimmer from 3-way toggle to 3-way momentary. And blammo :sob:

Thanks for pointing out the line in the driver. For now, I just commented that line out. I may go back to delete the entire section altogether. I prefer that I have the Option/Choice to enable these for as long as I need/want them. Personally I like to have the Info Logging visible for day to day stuff and then disable the debug when I no longer need it. But I can see value in turning off debug logging, automatically, with drivers that don’t allow you to enable/disable it…

Yeah, as @BertABCD1234 mentioned, this is a Hubitat norm that I am trying to emulate (based on user request). I couldn’t find any documentation on it so I tried my best to make it the same. I didn’t know that the typical way to do it is to automatically disable only one form of logging. I figured that people look at their logs to investigate an issue and don’t when things are running fine.

Thanks @BertABCD1234 for the simple fix. :slight_smile:

So based on the Hubitat built in drivers I am using, the Debug Logging is disabled after the timeout where as the Info Logging is not.