[RELEASE] Inovelli Device Drivers

[bptworld]

Having problems with nzw37. Using the current driver on Github, it throws this error...

dev:1492020-08-26 05:04:45.251 pm errorjava.lang.NullPointerException: Cannot invoke method split() on null object on line 426 (childOff)

I removed one to see what would happen if reinstalled. Bad things. It finds it right away but is stuck on Initializing. Tried 3 times, excluding and including, always finds it right away but just stays on Initializing.

C-3 running latest 2.2.3.135

I have 5 of these plug-ins in my system that don't work right now.

Thanks

@ericm @bcopeland

Log of excluding and including

[razorwing]

@ericm Ok, now it just got weird. I decided to put a 42 bulb on another hub just to see. Both hubs are updated to the same 135 and both are using the same built in driver. As per above the 3 bulbs worked fine on one hub. On the second hub the 42 bulb is failing the repair!! How?

[ericm]

Did it start with a firmware update or a driver update or anything else you can think of?

@razorwing very strange. I would say that for the LZW42 that we recommend using the built in driver since it has all the features and settings that the bulb has.

[bptworld]

@ericm

Did it start with a firmware update or a driver update or anything else you can think of?

Just noticed the other day that some lights were not working. I have some lights plugged into one of them that turn on/off when motion outside (side 1) and when my back gate in opened (side 2).

I tried going to an older driver from your GitHub but the error persists. My last attempt to fix was to remove and reinstall but now I can't do that either.

[razorwing]

@ericm Strange indeed. I am using the built in driver. Don't get why it would work on one hub but not another. Maybe @bcopeland can share any ideas as to why.

[mike.maxwell]

@ericm

If Hubitat has a driver for the device it will always be the default.

If a user installed driver has the correct fingerprint defined it will be chosen before a built in driver with the same fingerprint.
If this is not hapening then the user driver doesn't have the correct fingerprint defined.
If in doubt, install the Device driver, Then hit getInfo...
Use the fingerprint that's printed to live logs.

[razorwing]

@ericm Ok, what is happening is what @mike.maxwell has said. When the bulbs were first included there was a 3rd party driver InovelliUSA loaded in the Drivers on the Hub. The bulbs selected that driver when included. So I had to exclude them, delete the 3rd party drivers and then re-include them. At that time the built in driver was selected. The bulbs then went through the repair completely and correctly. Below is the log from one of the bulbs going through repair. Strange stuff though.

sys:12020-08-26 05:19:30.218 pm traceZ-Wave Node 52: Repair is done.

sys:12020-08-26 05:19:30.203 pm traceZ-Wave Node 52: Repair is requesting node neighbor info

sys:12020-08-26 05:19:30.196 pm traceZ-Wave Node 52: Repair is adding return route

sys:12020-08-26 05:19:30.193 pm traceZ-Wave Node 52: Repair is deleting routes

sys:12020-08-26 05:19:30.150 pm traceZ-Wave Node 52: Repair is requesting device associations

dev:38912020-08-26 05:17:59.995 pm debugparse:zw device: 34, command: 3304, payload: 04 00 , isMulticast: false

dev:38912020-08-26 05:17:59.955 pm debugparse:zw device: 34, command: 3304, payload: 03 00 , isMulticast: false

dev:38912020-08-26 05:17:59.950 pm debugparse:zw device: 34, command: 3304, payload: 02 00 , isMulticast: false

dev:38912020-08-26 05:17:59.931 pm debugparse:zw device: 34, command: 3304, payload: 01 00 , isMulticast: false

dev:38912020-08-26 05:17:59.915 pm debugparse:zw device: 34, command: 3304, payload: 00 FF , isMulticast: false

sys:12020-08-26 05:17:58.167 pm traceZ-Wave Node 52: Repair is requesting device associations

sys:12020-08-26 05:17:55.833 pm traceZ-Wave Node 52: Repair is updating neighbors

sys:12020-08-26 05:17:55.202 pm traceZ-Wave Node 52: Repair setting SUC route

sys:12020-08-26 05:17:55.136 pm traceZ-Wave Node 52: Repair pinging

sys:12020-08-26 05:17:55.132 pm traceZ-Wave Node 52: Repair starting

[razorwing]

@mike.maxwell, @ericm Well I spoke too soon. I did another repair just to make sure and all 3 bulbs that are using the built in driver have failed the repair again. They get stuck at "Requesting Device Associations" which is repeated 4 times and then repair just goes on to the next node.

[razorwing]

Any progress on this issue? It does have an effect on the routing because the bulbs do fail showing their status correctly once in a while. Dashboard shows them On but they are 0ff. Sometimes they refuse to change the CT right away unless you turn them Off and back On and then they respond to a change.

[EAN]

@ericm what is the difference between "Smart Bulb Mode" and "Disable Local Control" ?

Also, what does "Disable Physical On/Off Delay" do?

[Terk]

Disable Physical On/Off Delay makes the switch turn lights on instantly, I believe originally all switches had a 700ms delay this was primarily for the Red Series switches to facilitate the scene control capabilities so it could detect multiple taps with less than 700ms between them. With Black Series switches that wasn't necessary since they cannot do scene control anyway and many of us with Red Series decided to give up some of the scene control for instant response, you can still use held and the configure button for scene control.

Disable Local Control will make it so the physical switch won't work which is great if you have a little kid who loves to turn lights on and off over and over again. But you'll still be able to control it with Voice assistants or Rules.

Smart Bulb Mode I'm not sure, but I think it disables the relay on a switch or disables turning down the voltage on a dimmer so you can use scene control to control bulbs that need the power always on.

[ericm]

Basically what @Terk said. To add Smart Bulb mode puts the dimmer into a mode that prevents some of the issues people were seeing with Smart Bulbs (flashing, turning off, etc). It locks the output to either 0% or 100%.

[cpwilhelmi]

Yes it pulses, when I try the pairing the LED flashes then goes to solid green. However the light bulb keeps pulsing and is not controllable.

I’ve tried using inovelli support and they have now told me to do this again after 4-5 days wait. Not helpful.

[ronv42]

@ericm or anyone else seen this? Migrating z-wave Inovelli NZW31 w/Scene devices that have child devices for default level and disabling local control from a C-4 hub to C-7. Using the import config to new hub and the DNI method where the old DNI is changed to z new device unassociated and re-associated with new C-7, changed device label to "a remove" and the DNI to a. Then copied the new ID over x.

After that the device responds great though my dashboards and automations but what I am finding is now I have 3 orphaned child devices that can't be removed. I tried changing back the DNI to the old device and deselecting the options in the driver and I get these errors in the log:

[dev:230](http://ha-hubitat-c7.vargofamily.com/logs#dev230)2020-09-04 03:26:44.435 pm [debug](http://ha-hubitat-c7.vargofamily.com/device/edit/230)Hubitat has issues trying to delete the child device when it is in use. Need to manually delete them.

[dev:230](http://ha-hubitat-c7.vargofamily.com/logs#dev230)2020-09-04 03:26:44.432 pm [debug](http://ha-hubitat-c7.vargofamily.com/device/edit/230)Trying to delete child device ep101. If this fails it is likely that there is a SmartApp using the child device in question.

[dev:230](http://ha-hubitat-c7.vargofamily.com/logs#dev230)2020-09-04 03:26:44.429 pm [debug](http://ha-hubitat-c7.vargofamily.com/device/edit/230)Hubitat has issues trying to delete the child device when it is in use. Need to manually delete them.

[dev:230](http://ha-hubitat-c7.vargofamily.com/logs#dev230)2020-09-04 03:26:44.426 pm [debug](http://ha-hubitat-c7.vargofamily.com/device/edit/230)Trying to delete child device ep9. If this fails it is likely that there is a SmartApp using the child device in question.

[dev:230](http://ha-hubitat-c7.vargofamily.com/logs#dev230)2020-09-04 03:26:44.422 pm [debug](http://ha-hubitat-c7.vargofamily.com/device/edit/230)Hubitat has issues trying to delete the child device when it is in use. Need to manually delete them.

[dev:230](http://ha-hubitat-c7.vargofamily.com/logs#dev230)2020-09-04 03:26:44.418 pm [debug](http://ha-hubitat-c7.vargofamily.com/device/edit/230)Trying to delete child device ep8. If this fails it is likely that there is a SmartApp using the child device in question.

I don't have any automations or references to the child devices:

And they cannot be manually removed since the remove button is greyed out. Any idea on how to resolve this?

[ronv42]

Update:

After adding some debug code to follow the logic I determined that if I uncommented the code that deletes the child devices it should work and guess what It Works! I no longer have the children with the incorrect DNI. Just the base device now.

@ericm Looking at the driver code for theNZW31 w/scene the delete child options have all been commented out in your github most current entry. Is there a reason for it? I cannot find any other instances of deletechild except in these three entries and they are all commented out.

else if (!enableDefaultLocalChild && childExists("ep9")) {
        if (logEnable) log.debug "Trying to delete child device ep9. If this fails it is likely that there is a SmartApp using the child device in question."
        def children = childDevices
        def childDevice = children.find{it.deviceNetworkId.endsWith("ep9")}
        try {
            if (logEnable) log.debug "Hubitat has issues trying to delete the child device when it is in use. Need to manually delete them."
            //if(childDevice) deleteChildDevice(childDevice.deviceNetworkId)
        } catch (e) {
            runIn(3, "sendAlert", [data: [message: "Failed to delete child device. Make sure the device is not in use by any SmartApp."]])

When I run a small debug program I am able to determine the name is the old network address with ep8, ep9, and ep101 appended to the old network ID of 04. And it aligns with the device settings page that has the greyed out delete option.

I would hate the munge up a driver but looking for a way to insert code into the driver that would force it to just purge anything ending with those ep values.

Thanks.

[ericm]

I believe that was commented out because of some early problems back in the day. Like, years ago. If you uncomment those lines there should not be any problems.

An alternative that I sometimes use is to use the developer console of the browser (F12) or right click on the greyed out remove button and click "inspect" (easier).

Remove the disabled="disabled" text and then the button to delete the child should turn red.

[ronv42]

The uncommented code for the delete child has been working great. I have been testing it on my development hub and I can create the child devices and use them for testing and then remove them. Haven't seen an issue yet. Thanks for the trick on the disabled remove. I need to get more into the developers console for the browser.

[yototogblo]

I have a weird issue occurring. On 1 of my LZW30-SN switches, the "switch" status in HE only updates if I turn it on or off from the HE dashboard. If I turn it on/off physically or through association with another switch, it doesn't update. What's stranger about it is that the lastActivity and lastEvent updates but yet, the "switch" doesn't.

I'm using the exact same driver for all my other LZW30-SN switches (about 10 total) and none of the rest has this issue. Any help would be appreciated.

[yototogblo]

So for some reason, a basicReport command isn't being sent when I turn on or turn off the switch... Please any idea why?

Edit:
Ah, it's because I have "Association Behavior" set to 11... Didn't realize that would prevent the switch status from being correct in HE but I guess that makes sense.

[doctorkb]

Hey @bcopeland - have you had any luck in implementing level pre-staging in the LZW42 drivers? That would go a long way to improving the WAF of this setup...

Thanks!