I’m using 4 LZW31-SN (Red Series Dimmers) on Smarthings. I’ve set up a Webcore piston to activate different notifications on all the dimmers - persistent notifications to indicate my alarm state.
The problem I have is when the light switch is pressed, or given a command from the hub, the notification does not return - it stays on the level of the light switch.
Is there any easy way I’m missing to get the switch to return to the last notification after pressing the switch/receiving a command?
I’m also getting inconsistent notifications - I can see that webcore sends the command to turn on a notification, but the switch doesn’t respond about half the time. Any help?
Hey @Yooshaw – thanks for joining the community – we’re excited to have you here!
Let me make sure I’m understanding correctly (sorry, my mind is shot with all the pre-order dimmer stuff going on – I also wrote a sensor manual today lol).
So, if I’m understanding correctly, you have a notification turn on when your alarm is set (ie: maybe it turns green when armed) but if you physically toggle the switch, the permanent notification (green) goes away back to the default (blue). Is that correct?
I’m not sure what’s happening here – does the remote commands work for the switch itself all the time (ie: non-notifications)? I’m just curious if it’s only a problem with notifications or if it’s the entire switch.
Eric_Inovelli Founder / CEO:
So, if I’m understanding correctly, you have a notification turn on when your alarm is set (ie: maybe it turns green when armed) but if you physically toggle the switch, the permanent notification (green) goes away back to the default (blue). Is that correct?
This is correct - the green notification does not return after interacting with the switch. In the Smarthings Classic App, the notification still shows as “on,” but does not show on the switch itself.
Eric_Inovelli Founder / CEO:
I’m not sure what’s happening here – does the remote commands work for the switch itself all the time (ie: non-notifications)? I’m just curious if it’s only a problem with notifications or if it’s the entire switch.
The commands to turn on/off the switch work all the time with no issues at all - just the notifications seem to be flaky. I have 4 switches, and all 4 behave identically (meaning inconsistently) in this regard.
Thanks for your help and looking into this for me.
I have the exact same issue/concern. And humorously, it’l it’s the exact example that was used. Green light when armed, is Light is turned on and off, notification is blue. The notification it’s still on, but the color is blue instead of the notification color. Guessing it’s a device handle issue.
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.
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.
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.
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.
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.
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.
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.
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.
