[RELEASE] [Deprecated] Inovelli LZW31-SN Drivers with Child LED Devices

āš™ļø Custom Apps and Drivers
1

EDIT (November 2020): After using these for the better part of a year myself, I decided that, while interesting, the "standard" functionality provided by the child devices isn't as useful as I expected. While I still maintain custom drivers for some Inovelli products on my GitHub, I have overhauled these to work in a different manner. Inovelli, however, has adapted some of these ideas as options into their own driver, so the need for the driver here as originally envisioned is also probably less.

After using the Inovelli LZW31-SN (Red Series dimmer, the model with scenes and notifications), I wasn't 100% happy with any driver I had used, including my previous custom modification of the stock Inovelli driver. Additionally, while I like Hubitat's stock drivers, they don't include this particular device, and even if they did, the driver wouldn't support more than double-tap unless they change their minds or the device capability model.

Then it dawned on me: the LED bar in notification mode is basically an RGB bulb, so why not make it a child device with these capabilities (color, level, and effects), and then you can control it from pretty much any "standard" app via the typical commands? While I was at it, I also made the "default"/on-mode LED a child device (supporting color and level, no effects) and the "off-mode" LED another child device (supporting level; color comes from the "default" LED). I can't tell if this is such a great idea that I'm surprised nobody has thought of it or if it's such a crazy idea that someone did think of it and dismissed it for that reason. :slight_smile: The big advantage here, in my opinion, is that you don't need to use any custom commands to use the notification (or LED color/level) features of this device if they are exposed in this manner! (Or almost. There isn't a standard capability matching the "duration" part of the effect, but it will provide a default if you don't change it. And the effect commands are indeed standard on Hubitat but perhaps little-used...)

In any case, here are the drivers:

You'll need to do the following:

  1. Add the Red Dimmer (LZW31-SN) driver, https://raw.githubusercontent.com/RMoRobert/Hubitat/master/drivers/Inovelli/Red-Dimmer-LZW31SN-Advanced.groovy

  2. Add the Notification LED child driver, https://raw.githubusercontent.com/RMoRobert/Hubitat/master/drivers/Inovelli/Inovelli-Notification-LED.groovy

  3. Add the "Default" ("On") LED child driver, https://raw.githubusercontent.com/RMoRobert/Hubitat/master/drivers/Inovelli/Inovelli-Default-LED.groovy

  4. Add the "Off" LED child driver, https://raw.githubusercontent.com/RMoRobert/Hubitat/master/drivers/Inovelli/Inovelli-Off-LED.groovy

  5. After changing your device to the "Advanced Inovelli Red Series Dimmer (LZW31-SN)" driver (or the corresponding one for the switch) from step 1 (or if it gets added with this driver in the first place), click "Save Preferences" on the device page. This will update all Z-Wave parameters with your preference selection and also create child devices unless you disable that option.

The default and "off' LED drivers should be pretty self-explanatory. Changing color on the deafult will change the LED bar color for both "on" and "off" states (Inovelli doesn't differentiate there), and changing the level will affect the brightness for the on or off state status, depending on which child device you manipulate. Turning the child device off will set the brightness to 0 (turning off the LED bar), and turning the child device on will set it back to the last level you had it at (assuming the driver "remembers" it correctly--this is not not something the device can natively do).

The notification LED child may require more explanation. My recommendation would be to use it in this way:

  1. First, either use setHue and setLevel, or use setColor (this is really equivalent to setting hue and level; note that Inovelli does not support saturation, so that value is ignored).
  2. Optionally, call setDuration to set the effect duration in seconds. It will default to the highest value Inovelli's documentation suggests, 255, which I think might be "indefinite" (though in my opinion, given the way the dimmers work, you should manipulate the default LED instead of counting on any notification to really be indefinite).
  3. Last, call setEffect with your desired effect name or effect number, with the mapping as follows: [0: "Off", 1:"Solid", 2:"Chase", 3:"Fast Blink", 4:"Slow Blink", 5:"Pulse"] (you should also see this as the lightEffects attribute value on the child device). Alternatively, you could use on() and use the preference on the device to set a default effect for this command.

If you want to stop the effect, setEffect(0) or setEffect("None") should both work, as will off(). The notification will, of course, also stop after the timeout you've configured. Because the switch does not "reset" the notification parameter after this, do not count on the "Current States" of the notification LED child to show you what is currently happening, and I wouldn't use them as triggers in rules/apps. I would treat the child device only as something to manually manipulate via rules or apps.

All the functions the child devices can provide are also exposed as custom commands on the main/parent device. The child device states will not get updated when you do this, but again, I do not recommend relying on those states for any triggers/subscriptions/etc. As metioned above, you can disable the option to create the child devices and only use the parent device with these commands if you want.

Finally, as with my other driver, button numbers and events are different from Inovelli's drivers. Taps up are buttons 1, 3, 5, 7, and 9 pushed. A hold up is button 1 held, followed by button 1 released on release. Taps down are buttons 2, 4, 6, 8, and 10 pushed, plus button 2 held and released for holds and releases (so 1-5 taps up are odd button numbers 1-9, and 1-5 taps are even numbers 2-10; the button events for single taps, holds, and releases match Hubitat's conventions). The config button is button 11 pushed.

Let me know if you notice any problems! (And coming soon, probably something similar for the Red Series switches! And I could do the same for the default and "off" LEDs on the Black Series to let you squeeze psuedo-notification features out of those...)

8 Likes
2

Is it crazy that I just jumped from oh, that's cool to..."OMG I can make my light switches do that Cylon/Kit thing with the sweeping red light!"?

Despite my own craziness, this is seriously cook @bertabcd1234!

S.

5 Likes
3

Do a video of that if it's possible LOL That would pretty badass.

4

@anon61068208 @scottgu3 You can already do that with the Inovelli driver. Set the LED Effect Type to 'Chase' in the driver Notification settings.

5

That's what I thought/I'm already doing. Are we missing something?

6

For this specific effect? Probably not, but I don't really know what it is, to be honest. In general, my purpose with creating this driver is so you can set the notification LED to arbitrary states on the fly with standard color/level/effect commands without needing to either use a custom command (as in some drivers) or precreate child devices set to specific effects (as with Inovelli's drivers). Here you use one notification LED child device and set it to whatever you want whenever you want with whatever standard apps or rules you want, just as you might with an RGB bulb. I also exposed the defaul/"on" and "off" LED settings as child devices so you could do the same (I use them sort of like indefinite notifications, changing color based on my location mode).

7

It's funny how I somehow missed this the first time around. Nice work. Definitely another way to accomplish this.

8

Chase isn't available in the Red series LZW30-SN

9

@bertabcd1234

I noticed earlier I tried to click on each of the Driver Links, but keep getting 404 error.
So I clicked on the "GitHub RMoRobert/Hubitat" banner (above the links) and was able to get to the GitHub page listing all the driver. It showed that they just been updated an hour ago.

Just clicked on all 4 driver links again and still noticed the links are not working. Keep getting a 404 Error. Might need to update the links for each of the driver.

10

Done, thanks! Anyone who has imported them before will need to re-paste the URL (or file contents) to get the updates since I fixed a typo in the names.

I also added drivers for the switches, LZW30-SN, and made a few fixes. I'll probably also add pared down drivers for the Black Series (no notifications, obviously....but you can still play with the "default" LED) at some point, too.

1 Like
11

@bertabcd1234 I'm loving the features of this driver so far but I am having a few odd issues:

On the LZW31-SN the driver doesn't seem to apply parameter settings changes to the switch. Using the previous version of your Advanced Driver that was based on the Inovelli provided driver the parameters update immediately when I save the preferences. When I save preferences using this driver nothing is updated. I've been able to work around this by swapping drivers to make the parameter changes and then swapping back to this driver.

I've also noticed that if I set the Power and Energy reporting interval to "disabled", the parameter value is set to "0". While in theory this should disable the reporting it actually causes the switch to generate the reports continuously. The Inovelli documentation on this parameter isn't very clear. It states that "0 = 0 Seconds" which I suppose is technically accurate. It will generate the reports as rapidly as it can, which is multiple times per second. This is likely a firmware issue. I've set the parameter to the Maximum value as a workaround.

If you need any additional information on these issues I'll be happy to provide what I can.

12

18 = 99
19 = 32000
20 = 99

Should basically disable energy reporting.

13

Are specific parameters not saving? Perhaps I have something wrong, like the parameter size. (The in-box documentation was wrong about at least one, LED color, but it was easy to figure out since the value couldn't fit in the bite size provided...) It's certainly not all parameters if the energy ones are still saving. :slight_smile:

I did notice the oddities with the power/energy reporting, too, but I was just doing what Inovelli's docs say. I've set them to Scott's suggestions myself, too, which it sounds like you've also done, as a workaround until this gets clarified in either their firmware or documentation. Perhaps I could update the driver somehow to state that this should theoretically work but doesn't seem to? ("Basically disabled" is great, but truly disabled is best--I want my Z-Wave devices to be the least chatty than can be given that so many are including network-heavy features like power metering now.)

1 Like
14

It's a firmware issue and I believe there is a ticket in to have it fixed with the manufacturer.

15

Unfortunately, the energy parameters aren't saving either. I set them to 0 in the old Advanced Driver based on the assertion that 0 = disabled. I'm also trying to keep network chatter to a minimum so I've been working through my devices and cleaning up settings. Given the documentation I would have set the values exactly as you did in the driver. Hopefully Scott is correct and the fix will make it into the new firmware.

Another possibility is that the driver is setting the parameters correctly but the State Variables reported by the dimmer are not updating properly on the device page. I'm fairly new to Hubitat so I don't know if the display of the State Variables is written into the driver or if that's simply a function of the Hubitat interface.

I discovered the parameter issue because I had to factory reset one of my switches due to an association issue. I chose this new driver right from the start. Until I reverted to the old driver to set the parameters, the new driver was only displaying about half of the State Variables. After swapping back to the new driver they all appeared. I could probably replicate this if you need more data.

16

This would make sense. My driver does not set these, so they could be left over from another driver (Inovelli's or the Basic Z-Wave tool? not sure if either sets those). Switching drivers does not clear this area, so if you even briefly had another driver, this may be why. EDIT: I do see where these are getting written to state now, which I did not intend to do. I am not sure if those values are legitimate or not, but I'll look into it.

If you do want to check the parameter values, the Basic Z-Wave Tool would be one way--just switch to that driver, do a "Get Parameter" for the desired number and watch the logs to see what it spits out, then switch back.

EDIT 2: I think some may indeed be getting set wrong. Around line 499 or 500, try removing the ".format()" from the end of this line:

cmds += zwave.configurationV1.configurationSet(scaledConfigurationValue: p.toInteger(), parameterNumber: it.key, size: it.value)

I need to get to bed but think that was my problem. If this works (it did for one parameter I tested), I'll push it as a fix tomorrow. :slight_smile:

17

I removed the code you specified from the driver and was able to do some more testing this morning. With the change, the driver is setting the parameters correctly ion the dimmer. (I tested 1, 18, 20). I was able to save the preferences and verify using the Basic Z-Wave Tool that they were applied.

The State Variables section is still not populating with the correct values from the dimmer but I'm not sure if updating that area is an intended behavior of this driver. It sounds like this may be leftover from the previous driver. If you do not intend to populate it, it would probably make sense to clear it if possible just to avoid confusion and more support requests. :slight_smile:

I appreciate all your responses on this. I've experimented with the 3 other drivers for these dimmers and this one is by far the best. The approach to controlling the notification LED is far more intuitive than the Inovelli provided driver or it's variants. Also, the added support in your drivers for the "release" events has allowed me to implement smooth dimming for my Hue bulbs from the switch which has been awesome. Well Done!

18

I'll push out that change later today. The state variables should still get updated as far as I can see, but Hubitat doesn't dynamically refresh them; you'll have to reload the page for that. (I'm not sure if it would be good to keep these at all or not. I definitely didn't intend to but accidentally kept the behavior from Inovelli's driver, and considering there are almost two dozen of these, I could see it being useful to know the specific value of a certain parameter number and not just the friendly preference name the driver gives it...but I guess the Basic Z-Wave Tool can do that. Maybe remove? :thinking: )

And thanks for the feedback! Custom commands (which this driver still has) are certainly powerful, but I like the idea that standard capabilities can be used in pretty much any app, which is what started me down this path originally. My first driver was a modification of theirs that added "released" events and re-assigned some of the button numbers and events to make them (IMHO) more usable in Hubitat, which it sounds like you're also a fan of. (I can sort of see why they did this in their driver since it's a hasty port of the ST driver and ST doesn't support "released" as part of any button capability.)

1 Like
19

There is no real fix for this issue unfortunately. We want this fixed as bad as you do !

It is a bug that has been submitted to the manufacturer to create a firmware update.

According to @ericm the params settings wont stop it completely and will still report a couple times a hour.

20

When they release a new firmware what does the process look like to update the switches?

I have over 30 switches in my place. Just curious what Iā€™m going to be up against.