Inovelli Red Fan/Light switches...preorders shipping

Hmmm... So I actually just switched my entire house over to Hubitat this weekend (holy crap it's fast) and had something similar happen (stuck on initializing). My understanding is that it means the Hub found the switch, but the data transfer fails to initialize. In my case, I rebooted the hub and everything worked perfectly. I didn't see this in your responses so apologies if I missed it.

I'm not sure on this one - @ericm, do you know?


Strangeness continues. I was able to pair after allowing the "initializing" stage to continue untouched for several minutes, longer after the one minute countdown timer ran out. Once I complete the pairing and add the device to a handful of pre-existing apps in my Hubitat setup, it's as if the switch loses connection with the ceiling module. I assume that's the problem because, whether I tried to issue commands from the switch physically or from the device details page within HE, the Fan/Light does not respond as it did right after I paired it.

If I remove the device from the apps, unpair the device, repair to the ceiling module, and then repair to the hub, then I can control it again from the app and from the switch. Until I re-add to the apps, and the whole process repeats.

I've checked logs to recheck for any virtual commands that could be countermanding mine, but no joy.

This is so weird (and I do have another Fan/Light switch that is up and running without an issue), I keep thinking I'm missing something obvious, but I've retraced these steps three full iterations, each time with the same results.

You should check the Inovelli forum about the light/fan module losing connection with the switch. It is a known firmware problem (now) and an OTA upgrade is available (via Z-Wave stick or the Z-Wave Firmware Upgrade that @bcopeland made for Hubitat).

1 Like

Welcome to the light side! :wink: Of course nobody here is going to ask how you got your hands on a Hubitat hub with supplies depleted, or if it says "C-7" on the bottom label....

Ahh, yeah ok - this could be related to what @snell talks about above. Good news is I think we were able to fix this and as mentioned, there is a firmware patch that should improve the disconnects.

Using the Firmware Updater: [RELEASE] Z-Wave Firmware Updater

Flash this file onto the switch:

Hopefully this fixes things for you. Sorry for the troubles - it was a real rollercoaster getting to the bottom of this one.

Edit: good catch @jerias.mitchell - just updated it!

1 Like

Lol, no comment.

1 Like

Eric -

It looks like you linked the shipped 1.31 firmware, and not the updated 1.34 beta?

Here is 1.34

1 Like

I flashed two LZW36 switches to 1.34 yesterday, using the linked Z-Wave Firmware updater and .gbl file.

I've been hammering both with my RM stress test routine, and have no issues to report after about two hours. It took the stress routine 3 days to lock up one switch, so I'm not going to declare victory beyond the firmware upgrading successfully.....

1 Like

Imported the latest version of the Z-Wave Firmware Updater (still lists itself as 1.00) but getting an error in the log with that link you posted, then it seems to sit with a status of:
firmwareUpdateProgress : Padding hex bytes...

Log below:
2020-07-20 03:18:26.456 pm java.lang.NullPointerException: Cannot invoke method and() on null object on line 461 (firmwareStore)
2020-07-20 03:18:26.430 pm [info]firmware total bytes: 0
2020-07-20 03:18:26.420 pm [info]Sorted all the bytes. cleaning up some memory...
2020-07-20 03:18:24.986 pm [debug]packing all the bytes...
2020-07-20 03:18:23.470 pm [debug]firmwareMdReport: checksum 0 firmwareId: 3585 manufacturerId: 798 maxFragmentSize: null firmwareTargets: 0
2020-07-20 03:18:23.464 pm [debug]FirmwareMDReport: FirmwareMdReport(manufacturerId:798, firmwareId:3585, checksum:0, firmwareUpgradable:false, numberOfTargets:0, maxFragmentSize:null, firmwareIds:[])
2020-07-20 03:18:22.982 pm [info]VersionReport- applicationVersion:1.31
2020-07-20 03:18:22.975 pm [info]VersionReport- zWaveProtocolVersion:7.13
2020-07-20 03:18:22.562 pm [info]FirmwareUpdateMd version:5

As a note... I also tried downloading the file from the link and posted it on my own server (I had a previous problem with an inovelli upgrade file and was curious if it was the same thing) but it got the exact same error. Since @vreihen got it to work fine, I must be doing something wrong. Any recommendations?

I’ve had the same experience as @Snell. Stuck on “Padding hex bytes...” for the last hour.

Edit: same error messages in my log

I just successfully updated mine from 1.31 to 1.34 using @bcopeland's newest Firmwave Updater. Took 2 tries, even though I my switch is really close to both the Hub and the Repeater. I expect the issue was simply too much Zwave traffic, but that would be a total WAG.

I think for the next one, I'll connect it to the Flashing harness, set it right by the hub, and flash it before installation.


@Eric_Inovelli, I'm continuing to get the same error messages as @snell. Completely dead in the water. Can somebody at Inovelli provide some kind of support to us?

dev:46842020-07-20 08:20:54.940 pm errorjava.lang.NullPointerException: Cannot invoke method and() on null object on line 461 (firmwareStore)
dev:46842020-07-20 08:20:54.905 pm infofirmware total bytes: 0
dev:46842020-07-20 08:20:54.902 pm infoSorted all the bytes. cleaning up some memory...
dev:46842020-07-20 08:20:54.699 pm debugpacking all the bytes...
dev:46842020-07-20 08:20:53.295 pm [debug( checksum 0 firmwareId: 3585 manufacturerId: 798 maxFragmentSize: null firmwareTargets: 0
dev:46842020-07-20 08:20:53.291 pm debugFirmwareMDReport: FirmwareMdReport(manufacturerId:798,firmwareId:3585, checksum:0, firmwareUpgradable:false, numberOfTargets:0, maxFragmentSize:null, firmwareIds:[])
dev:46842020-07-20 08:20:52.492 pm infoVersionReport- applicationVersion:1.31
dev:46842020-07-20 08:20:52.474 pm infoVersionReport- zWaveProtocolVersion:7.13
dev:46842020-07-20 08:20:52.253 pm infoFirmwareUpdateMd version:5
dev:46842020-07-20 08:20:44.088 pm debuglocked by:
dev:46842020-07-20 08:20:37.465 pm warnUpdate process is currently running
dev:46842020-07-20 08:20:37.448 pm debuglocked by: 7F

Just tried a bunch more times. But rather than work it here (since it is not necessarily the Z-Wave Firmware Upgrade driver's problem) I am continuing this part in Inovelli's thread for this.

1 Like

That error is because you are using the old version ..

You are going to have to get the new binary compatible version:


This = Solution. TYVM

Looking for something like this but in a version that will work all over the world except some backward areas where they have 120V / 60Hz grid. Who knows a good alternative for this in a 230V / 50Hz version?

Thanks! I wondered about that but did an import before just to make sure I had the latest... Now when I copy this one in that you linked above it is obviously different (line 461 is totally different for example). But the version number you have at the top is still the same. So that throws me off a bit.

Started the upgrade with the CORRECT driver... and it is moving along just fine now.


I got mine Friday. Went to install but not sure it’s going to work. It’s a fan that is already controlled by its own remote control. Sent a note to support but in the meantime does anyone know if it’s possible to use these switches with fans that have their own wireless control?

I would say most likely "no". My Harbor Breeze had a remote module in the canopy, roughly the same size/shape as a HBFC module, and a bit bigger than the Inovelli module. I took it out, threw it and the remote away, and installed the Inovelli module. If the remote is built into the fan unit someplace, (e.g. not in a separate canopy module) I suppose that would work., but I'm not sure if the Inovelli could detect the state changes you made with the remote.

If you want a unit with a remote, the Hampton Bay Fan Controller/King of Fans controller (AKA HBFC) is probably your only option.