LZW31-SN Persistent Notifications

Hey guys, sorry with all the dimmers being shipped out today, I haven’t had a chance to test this.

I’ve added it to my calendar to test tomorrow!

Edit: Also, thanks for tagging me – I get a ton of notifications, but when you tag me, I get a Google Chrome notification and those I do not miss!

Same issue/concern with persistent notifications. I’m using CoRE because the “Smart Lighting” option was a bit under whelming for my plans.

It seems any notification will cancel another notification. For instance, I have a persistent notification set to have the LED chase when any garage door is left open. I also have a notification set for when a door is unlocked.

If someone opens the garage door the persistent chase activates. Once the person unlocks the people door to the house I have a flash notification to indicate the door is still unlocked. If the person leaves the garage door open but remembers to lock the person door the flash notification will cease and return to normal (blue). The appropriate response should be to go back to the first chase notification because the garage door is still open.

Lastly, like the member above, if I physically interact with the switch in any manner, the notification will also cancel. In all instances, CoRE indicates the piston is triggered and SmartThings shows the notification on.

The dimmers are AWESOME and I love the look and functionality. The notification features are what put it over the edge for me to pre-order four. I hope this is something that can be addressed.

@Eric_Inovelli Any update?

I’m experiencing the same thing as well in trying to create a persistent notification when we disable the garage door at night. Any state change to the dimmer will eliminate the persistent notification.

Bookmarking. Same issue here (with openHAB as zwave hub).

+1 Another bookmarking this topic, I have the same issue of persistent notifications dissappearing after the switch is turned on or off.

Just discovered the same issue for hubitat.

I use persistent notification to display mode.
for now I created a RM that is triggered by a change on the switch and then turn notification back on.

Have any of you considering just changing the “default” LED rather than the “notification” LED for things that you want to be persistent? I modified the driver on Hubitat for a few reasons (re-mapping the button numbers and events to something that makes more sense to me), one of which was adding custom commands to set the default LED (only possible on the device/driver page otherwise) and notification LED (only possible otherwise by activating the child devices): https://github.com/RMoRobert/Hubitat/blob/master/drivers/inovelli-dimmer-red-series-lzw31-sn-advanced.groovy

I did this because I wanted my LED bar to reflect my hub’s mode most of the time. I originally tried an “indefinite” notification LED but ran into the same issue as above. So instead, I changed the default LED, then have “real” notifications do their thing when necessary–e.g., door unlocked, motion on specific sensor, etc.

I think the persistent notification thing is something that will have to be addressed via firmware. As I understand it, it is, for all intensive purposes, just a “light” that can be turned on or off. When you add another notification, you are merely switching with “light” is turned on and therefore you lose the last state. I am not sure if there is onboard memory for the switches, but that is a bit of logic that needs to be handled locally on the switch to get the result most people are looking for. Not saying that it can’t be done, just that it will take some work on their end.

I think what Inovelli has done in just giving us notification lights generally at the switch level is pretty intense and the way they do it is fairly eloquent. I’m not saying this isn’t a good feature to add giving that most people when they hear notifications, they immediately assume stackable. I just don’t think the device is currently coded for this.

All that being said, I am fairly certain a pretty simple piston in WebCore could be written to at the very least understand TWO stacked notifications. It would just be a matter of detecting whenever a notification is “turned on” and storing a value for that notification. If another goes on, doing the same. If the current “notification” is then turned off, the piston would check if there is a stored previous notification and if so, turn it back on. I’m sure I’d have to work through the logic a bit to make it fallback correctly, but conceptually I worked it out and should be able to be done. If anyone REALLY wants to go at this, I can try to carve some time to build out a piston to try my theory.

Tony

good idea, I saw you had a custom driver but hadn’t thought about this use for it.
Will take a look.
What I liked about the child notifications is that I put them all in a group and just turn on the group to set notifications on all my switches.

Hi,

I had the same issue and I fixed it myself by using the following (using Hubitat):

My notification pulses RED when HSM is set to Armed Home/Night. If the dimmers being used for LED notifications are toggled, the RED LED is gone (just like you). My rule will re-enable the notification after 30 seconds because it monitors the same dimmer switches for any change.

Hopefully it can give you some ideas to fix your own implementation. I realize you’re using SmartThings, but the logic in the rule is still valid if there’s a way to use it for your hub.

1 Like

Yes, this can be resolved through software from some hubs.

However, in my case, the reason I brought this up was because i noted this behavior is different between the switches (LZW30-SN) and the dimmers (LZW31-SN).

The switches return to the previous notification setting whereas the dimmers don’t.

2 Likes

Hey guys, what may be happening here is that an older version of the handler was installed. The wrong handler got pushed to GitHub by accident causing an issue with notifications.

Here’s the correct one for LZW31-SN (Red Series Dimmer).

Can you let us know if this fixes what you’re seeing?

Also, thanks @BertABCD1234 for your modification to the driver for Hubitat, really well done!

Hi Eric,

I tried with Device Handler provided by you in previous message but, seems like I still see same issue. As soon as I interact with switch notification light go away and not coming back. But, in smart thing App notification still showing “ON”. Not sure if I am missing something.

Kush

@Eric_Inovelli … Just tagging you.

@Eric_Inovelli

I updated the DH right away when it was posted to GitHub - no change in behavior, the notification does not return after interacting with the switch (physical or through the HUB). In the SmartThings Clasic App, the notification still shows as “on,” but does not display that notification on the switch itself.

@EricM_Inovelli – can you take a look at this?

Seeing the same thing on Hubitat

@Eric_Inovelli @EricM_Inovelli Any update here?

@Eric_Inovelli Seeing the same thing. 3 different dimmers, same results. Tried original and updated version of the DH. If any interaction with the switch happens whether physical switch push or through smarthings, the notification goes away and shows the dimmer level. The smarthings app shows the notification as on, but it is not actually on. Also, it would be nice if the indicators would toggle back and forth if multiple scenarios are met. IE (if a door is open and indicator shows red, and then the garage door opens it should show cyan…I would like to see red for a period of time, then cyan, back to red etc.)
Loving the dimmers so far. I’d be happy to help in any way I can if you need more info.

2 Likes