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
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.
@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
Having the same issue. Have it turn to red when my garage door is open but that doesn’t help if I turn the switch on or off and then its just blue I will think my garage door is closed…
@Eric_Inovelli, @EricM_Inovelli Any updates? It’s been quiet from your end. I stink at Webcore and am struggling to get the notifications to come back reliably via a Webcore piston.
bookmarking as I am experiencing the same issue at the moment with my two dimmers. At first I thought my piston wasn’t working correctly but then I noticed that anytime I use the switch my notification disappears even when the conditions are still active and the notification is still stated as being on in smartthings app.
Bookmarking. Important feature I hope to see soon.
Hey guys, thanks for being patient with us. All of the workaround that have been suggested have been great and hopefully many of them can use them. As for the underlying reason for the notifications not being persistent, it is something that we are addressing in the firmware.
2 Likes
I’m seeing two different persistence problems being reported:
-
Changing the light level resets the LED, which makes the notification disappear. I ran into this problem myself. I see this being 100% a firmware issue.
-
If the switch got notification A and then notification B, and notification B is cancelled, then the switch returns to its default color, and notification A is lost. I’m a bit puzzled about how this would be a firmware issue… unless the firmware is going to be radically revamped. Let me explain…
I’m using Home Assistant to control my ZWave network. In HA when we access a ZWave device, we get the device directly as it exposes itself to the ZWave network. Looking at what the LZW31-SN exposes to the ZWave network, I don’t see any notion of “notification”. What we do get is parameter 16 which allows setting the LED to a different color, intensity, add an effect, etc. So looking just at what I see exposed to the ZWave network, I’m not seeing evidence that the firmware knows what a “notification” is.
From what I can tell, the people who have been reporting the 2nd issue use Hubitat or SmartThings. I’m not familiar with these platforms but I did take a look at the files Inovelli provides for these platforms and it seems to me that the notion of “notification” is an abstraction that is created in the Groovy files for those platforms. The code there converts the notification to an operation on parameter 16. Again, the switch has no notion of notification. Some logic in Hubitat or SmartThings would have to be implemented to keep track of active notifications.
Kind of, but this is separate from the parameters, these are inbuilt notifications in the preferences, and there are up to 5, each with 4 settings (type, color, persistence, etc.).
My expected behavior is that if Notification 1 is indefinite (garage door open) and the front door opens and I have a 10 second notification to Notification 2, then the Notification 2 would override Notification 1 for the 10 seconds, but then it would return to Notification 1 (assuming garage is still open). Right now the switch returns to “normal” operation (blue bar) while notifications are still active. That is what behavior is NOT expected.
Last example:
Notification 1 - Indefinite
Notification 2 - 30 seconds
Notification 3 - 10 seconds
Notification 4 - 5 seconds
If Notification 1 is already triggered, then Notification 2 is triggered, and while N2 is going N3 goes off, and while N3 is going N4 goes off, I would expect:
N4 for 5 seconds
N3 for remainder of 10s duration
N2 for remainder of 30s duration
N1 indefinitely until cleared and/or notification turned off.
Confusing perhaps, but I believe intended behavior.
1 Like