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

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

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

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.

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:

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!

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

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.

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.

It should be pretty similar to this, assuming they provide an OTA firmware file:

http://www.support.getzooz.com/kb/article/253-how-to-perform-an-ota-firmware-update-on-zooz-devices/

(I have done this on a few Zooz devices--easy if you have an external Z-Wave stick, a bit of a pain if you don't use one as your primary Z-Wave radio.)

Inovelli has also hinted that they're partnering with a "major company" for a test of Z-Wave OTA updates. Coincidentally, SmartThings has also announces they're testing Z-Wave OTA updates. My guess is that these coincidences are not unrelated. :slight_smile: (I would assume that would be simply another method, not the only method.)

1 Like

You will need a Z Stick and a windows computer that can send OTA files to the device. You join the Z Stick to the Hubitat hub as a secondary controller and with the Windows software you use you send the OTA file to each device.

If we see this is necessary we will have appropriate instructions on the OTA file location.

2 Likes

Being able to add it as a secondary controller makes me feel a lot better. I was afraid that I would have had to remove and rejoin all my devices. This would be much easier.

1 Like

I use Homeseer Zwave OTA updater to do this. I know there is other software out there is free which I will get a list of at some point to post on the Inovelli Community Forum.

1 Like

I'm not sure I understand. Rule Machine isn't used to create scenes; it can be used to respond to Z-Wave Central Scene events (typically parsed as button events in the Hubitat and ST world). I'm guessing that's what you meant? So like an easy way to control smart lights (or anything else, I guess) using a scene-capable dimmer/switch?

FWIW, I also have [RELEASE] Dimmer Button Controller (configure Pico to emulate Hue Dimmer or any button device to easily control lights), which I wrote for a similar purpose. Basically, similar in concept to Button Controller or ABC, but different in that its intended actions are lighting only. (It gets tiring to constantly select the same devices in each action of a rule...). It's not Inovelli-specific and actually might be a bit confusing to use with Inovelli devices--it's meant for ones like a Pico remote or Hue-Dimmer-on-Hubitat that do not natively support multi-taps but where you still want the mulitple-pushes-cycle-different-scenes actions à la Hue-Dimmer-on-Hue. (So ignore the "Press 1," "Press 2," etc. and just use "Press 1," then use the right button events and button numbers from the switch/dimmer.)

Any of the above apps would be a lot easier to use with Inovelli's stock driver if their button events were named more logically on Hubitat (I can sort of understand why they did this on ST, which doesn't support "released," and the Hubitat driver is just a quick port of that), so I guess one way a dedicated Inovelli app could help is by masking the button events/numbers from the user and just letting them choose based on what they do to the switch and let the driver and app interact with each other in ways they already understand and the user doesn't need to. That should be quite helpful for some people. :slight_smile:

I am struggling understanding how this driver works.

How are the child devices made? I made a virtual device but couldn't get it to associate as a child device. Am I think about this all wrong?

That is not my driver. If you are using mine, child devices are created automatically if the drivers are available (you'll see an error or warning in the logs if not), which I think should really be the same for Inovelli's too. In any case, you can't manually create devices and then make them child devices of a different device, and if you're trying to use Z-Wave association from Inovelli's driver, that is a different thing and only works with two Z-Wave devices.

ok thanks in the mass copy/paste I must of gotten the wrong driver.

Testing this driver out, I think it's the best solution for the notifications turning off when manipulating the switch. Being able to change the default LED color in RM is great!

With that said, all the example rules I've seen show setDefaultLED(red, 10) as the example. For me using "red" is not working, I have to use the numeric 1 for red, 170 for blue, etc... Is this a change in the driver since inception?

Also, is there a color chart in this 0-255 range? I've just been banging in random numbers until I find the color I'm looking for lol

EDIT: When I change the device type, the old Notification 1 child device stays and can't be deleted.

setDefaultLED doesn't exist in this driver. There are separate commands for color and level, plus (optional) child devices. Are you sure you aren't using my older version? I don't use that one anymore but would have to check if you are and intend to be using it.

Definitely using the new one, I must just be looking at example rules from the old one. I'm using setDefaultLEDColor to change the colors and finally seeing the "notification" results I've been looking for since installing these switches.

Does this version support the named colors or just the 0-255 scale?

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.