Hello - I have a RM rule that turns the LED on the switch to "red, 100% level" if the front door lock is unlocked, otherwise "blue, 100% level" if the kitchen switch is turned on, "blue, 10% level" if the kitchen switch is turned off.
This works as expected when the kitchen switch is on. However, if the switch is off, then the LED does not come on at 100%. I think it may be related to or overridden by a setting on the switch for the LED strip intensity (when OFF). I am using the Inovelli supplied drivers.
I had it set to 10% but have changed it to 30% and can now see the red LED. My preference would be to NOT have the LED be at 30% all the time when the switch is off . What I would like it to do is be "blue, Level 10%"when the switch is off and door is locked; "blue , level 100%" if door is locked and switch is on; "red, 100%" if the door is unlocked (whether the switch is on or off).
The way that the parameters work for the "regular" (not notification) LZW31-SN LED is that you have three settings:
LED bar color (parameter 13)
LED bar brightness when on (parameter 14)
LED bar brightness when off (parameter 13)
Looking at Inovelli's driver (I haven't used it; just looking at the code), it appears to modify only parameters 13 and 14 with the child "LED Color" device, so it isn't possible to use it in exactly this way. You can do what it sounds like you don't want to do--set the "off" LED level manually to whatever you want and just leave it there all the time (the color will still change because there aren't separate on/off parameters for that).
Inovelli could modify their driver to provide a way to allow this, but it would involve either a custom command or yet another child device for the "off" level (something I actually played around with on a custom driver I wrote for these but wasn't sure how crazy of an idea that was or wasn't). Presumably they didn't because this matches the way the device parameters work. If you're proficient with Groovy and Hubitat's Z-Wave device model, you could also add it in yourself (e.g., with a custom command on the parent), but that might be more work than you'd want to take on just for this.
Yes - I don't think they are overwriting parameter 15 (LED bar brightness when off). Wonder if this is an oversight or by design? I will try posting in the Inovelli forums to see if they can clarify.
I don't really want to leave the default off level very bright - can see if being an issue at night. And I definitely would not want to mess around with the driver code . Will check out how acceptable it is at night with my current setting (30%).
Oh yeah, I forgot to mention the use of notifications at all, a gap that @Hasty1 filled in. I actually prefer changing the "default" LED in most cases instead of resorting to using the notification LED, which I guess explains why I forgot. For example, most of mine just show me my hub's mode based on LED color. I prefer the notification for short-term conditions, like outdoor motion; I know others who use it for doors unlocked, garage doors open, and similar, and that might actually be better for you here (plus you can get things like "effects"--blink, chase, etc.--that you can't with the regular-mode LED).
If you're using Hubitat's driver, setIndicator() is the command you'll need. For Inovelli's driver, that command is also available, or you can use the options in the driver to pre-create up to 5 "notification child" devices with your specified settings--configure the level, color, effect, and duration, then it will make a child switch device you can turn on to activate that notification. (This is the first screenshot Hasty1 posted above.) This would allow you to use standard commands or common apps like Simple Automation Rules. If you prefer the setIndicator() route instead, you'll need a custom command in RM (or a custom app) and a calculated value, which the tool linked to above is probably the easiest way to obtain.
Thanks @bertabcd1234 and @Hasty1. I was scouring the Inovelli forums for notifications and saw that there were issues with Notifications being overwritten (going back to default) if the switch was turned on/off (whether physical or rule based).
Apparently, there is a firmware fix for this in v1.41. However, my switches are at v1.35. For now, I may just stay with what @bertabcd1234 suggests until I figure out the z-wave firmware updater tool...
I was trying out your rule but got stuck at the startNotification - I did not see it in the list of action types. Is there something that I have to do to activate that?
Also, the parameters on level for the LED apparently now go from 0-100 (on the child device) whereas the tool for getting the value goes from 0-10.
Thanks - I have it working now with StartNotification. One issue that I ran into is that if I turn the switch on/off manually while the notification is active (door is unlocked), the switch LED goes back to default settings (like if the notification was stopped). Here is what I saw:
Switch was "off" - LED blue, level 10%
Door unlocked (switch still off) - LED red, level 100%
Switch on (manual) - LED blue, level 100%
Switch off (manual) - LED blue, level 10%
For actions 3 and 4, I would have expected the LED to remain red at 100% (like it did in action 2). Have you run into this?
I know with the dimmers this might be due to the firmware bug listed above. Or it might be the LED Timeout setting for the device.
I don't use many dimmers, only on off switches.
Maybe @Eric_Inovelli can help out!
@Hasty1 Quick question - have you had any issues with the "stopNotification" not working? Over the past couple of days, I have noticed that sometimes the LED will not go back to the default color when the door is locked. At first, I thought that the open/close events were happening too quickly (unlock door, come in, lock door) so I put in a 30 sec delay between the "Wait for condition..." and the "stopNotification". That did not fix the problem - actually made it worse (I had to "stopNotification" from the device page as the manual lock/unlock did not correct it).
I have one switch on 1.44 and the other on 1.35 firmware. Both seem to have this issue.