I’m using the advanced driver on hubitat c7 with a bunch of the lzw31-sn.
I have set up all of the the LED notifications to do their own thing. There is a problem where if you turn off a particular LED switch, all/any on that switch turn off.
For example, if notification 1 is blinking green, and notification 2 is pulse violet-- you can turn on pulse violet, then turn on blinking green, then turn off pulse violet-- you’ll see blinking green is shut off.
this happens with Rule Machine5 as well as just using the Device page in hubitat.
Which driver are you using, specifically? A link would help. It sounds like Inovelli’s, but theirs does not have “advanced” in the title. I wrote one that does, but this doesn’t sound like it.
This may matter, though possibly not (see below).
Regarding the behavior you’re seeing, that sounds normal to me. The switch/dimmer can only do one LED “effect”/notification at a time. (On the Z-Wave side, there is a single parameter that stores a calculated value corresponding to a sort of sum of the options you’ve selected.) When one is set, it overwrites the other. Unless you have an app or driver that is dome some special caching of its own and re-applying a previous value for this parameter, one overwrites the other, and clearing any also thus returns the bar to normal. Some people have asked for a feature that sounds like what you’ve want, but I’m not sure if they’ve committed to doing it or not, and I’ve also never been convinced of the necessity given that this logic can also be done on the hub side (say, with a rule or custom app in your case).
I think you are going to have to test to see if the previous notification is turned off and NOT send another off if it already is. Since as @BertABCD1234 mentioned, one notification trumps another, turning on a new notification will turn off the old one. So that should be easy to check.
Rule1 triggers on HSM Status armed, which switches on notification1/indefinite pulse red.
Rule2 triggers on HSM Status disarmed, which switches off notification 1.
Rule3 triggers on water sensor wet, which switches on notification2/fast blink red.
Rule4 triggers on water sensor dry, which turns off notification2.
if the water sensor reports wet while HSM is armed, i can go dry the water sensor, but then the previous pulse red will never turn back on, because the notification 2 switch cancelled the notification 1. or-- at least-- there is no memory of notification1 being on.
it wouldnt be too hard to go and check the previous status of the notification LED before turning on the notification2 LED. but that’s a race condition waiting to happen. and I’m using all 5 notifications for different things, i’m not imagining a simple/clear way to track it all reliably.
I guess I’d have to set a hub variable for each LED notification (5) on each LZW31 (~2 dozen). Then have a rule for each of them (120 rules) that would trigger on each changed, and set the appropriate hub variable to the current status (on/off). and in each rule that turns on a notification switch, i would have to go and check all the hub variables to see if there was one that was on - and not shut off - and switch it back on. yikes.
I see what you’re saying. It’s not that the “off” that’s turning them all off, it’s that either on or off don’t keep memory of any LED previous states. It’s not intuitive that way, based on the current UI/code. but makes sense.
So now that I’m understanding what’s going on, I guess what I’m really doing is asking for a feature request!
If something internal just kept state, these problems goes away. If i turned on notification1 and have not turned it off, the driver could know that notification1 should still be on even if i’ve switched notification2 on and off.
Why not use a single rule with whatever triggers you need, then conditional actions to set the LED appropriately? Here is one example:
Trigger: HSM status changes OR water sensor changes
Actions to run:
IF (Water sensor is wet) THEN
On: Notification 2
ELSE-IF (HSM status is armed) THEN
On: Notification 1
ELSE
(clear notification)
END-IF
The order of these actions matter, since that sets the precedence for which notification actually gets turned on (per the use of ELSE-IF and ELSE, only one of these blocks will actually execute).
It’s possible your actual automations are more complicated than this, but this simple example should still demonstrate the general idea. (I also wrote my own driver and don’t use the “child devices” at all—they’re not necessary for rules where you can run a custom command, and despite the ease of use they provide for some users, I find it simpler to just run the setIndicator() command with a parameter myself … but the idea is still the same either way.)
EDIT: I guess maybe you care about which of these was the most recent, not which you consider the most important. I can see where that would be more difficult. It did not cross my mind because all of my automations use some precedence like this (and I’d really use a push notification for a leak rather than an LED bar I wouldn’t see, but that’s another story and I understand the issue!). There is probably still an easier way to track that with, say, a hub variable and a tokenized/tokenize-able list of calculated parameter values… but more effort than I’d probably do, still, ha.
It’s behaving as expected/normally from the manufacturer, as there is only one notification setting in the switch, you will have to find YOUR workaround to build/prioritize notifications. Many options like mambers exist.
I would agree that trying to make the switch store X number of notifications deep just adds unnecessary complexity. You build the rules or such on the hub to handle whatever notifications you want.
Right, I get it now. It would be more clear if the UI in the driver is changed. For example, the “off” button in the LED notification device page should say “all off”. and under the switches in rule machine, it’s confusing to select a checkbox for “Hall Light - Notification 1/Pulse Red” and choose “off”, and have your Notification 2/Green Blinking turn off.
Then the device would not be usable as a switch in apps like Basic Rule, Simple Automation Rules, or others that expect switches, which I think is the main appeal of these child devices for most users. The Hubitat “Switch” capability (which these apps look for) requires implementation of two commands named “On” and “Off,” by definition of the capability. It might be good if the driver UI in Hubitat had a way to let the driver author explain a bit more about the command, but nothing like that exists right now so … I guess you just have to know. It’s possible this UI will become more flexible in the future for developers (or not).
Something like “All Off” certainly is possible, but then you’d be dealing with custom commands, so you’d need an app that lets you use them. Rule Machine does, but if you’re using custom commands already, I’ve always found it easier to just use the setIndicator() command myself instead of dealing with child devices at all. But that’s just me!
but more effort than I’d probably do, still, ha.
It’s possible this UI will become more flexible in the future for developers (or not).
I am the same way. 