Yeah, we are looking into a few issues with the C-7. The NZW37 is not working because it's multi-channel reports can't be parsed yet.
For the other devices users will have to use the built in Hubitat drivers until the issue is figured out.
@ericm & @Eric_Inovelli so we cant use the wall switches to their full extent on the C-7 even with the new firmware?
The wall switches should work fine aside from the SmartStart issue, but tbh it's hard to keep up on what works and what doesn't. Good news is both teams are working together to figure out how to make everyone happy. I couldn't be happier with the Hubitat team and kudos to them for their efforts to bring this 700 Series hub to market. With new technology brings new challenges and we're working thru it.
9 Likes
Currently that is the case, but we will get it worked out. I've reached out to Hubitat to see why some drivers aren't working on the C7.
1 Like
following the thread for NZW37
Frustrating, I bought the new Hubitat because the hurricane fan/light switch can’t be updated via home assistant, and I need the firmware updated to get the switch working with my hunter non-pull chain fan. Well now the c7 doesn’t fully work with the inovelli switches...
I'm assuming this problem will get sorted out soon, so it should be short-lived. 
But in the meantime, if you have access to a Windows PC, you can update the firmware without Hubitat or Home Assistant. Since you have Home Assistant, you probably have a Z-Wave USB stick, and all you'd need is the Z-Wave PC Controller software to perform the update--just use that stick and put it back on HASS when you're done.
1 Like
Do I have to reset my entire HA zwave setup? Or will it retain it when I plug back into the pi? Eventually I will port all to Hubitat when I have more free time, just need these darn new fan/light switches to work for now.
Seems to be a major oversight by Inovelli as most new and high end ceiling fans do not have pull chains and other switches handle it fine.
No, Z-Wave PC Controller will "see" all the nodes you've paired while it was in use with Home Assistant--that much is stored on the stick. You won't see device names (that exists only on the hub/software side, so Home Assistant in this case but it would be the same with Hubitat), so you'll have to get or know the Z-Wave node number. Just don't do a "Reset" on the stick in PC Controller and you'll be good!
I should note that some devices need to be re-paired after firmware updates (in which case it may be easier to just exclude and pair it to a special stick/network you use just for this purpose), but I did not have to do this with the LZW36-SN or any current-generation Inovelli devices to-date.
Thanks for this, I went through and did the update to the latest beta firmware. Still not working to control the fan module. Did I just get a bad unit? Also, it is still showing up as 1 controllable entity in HA, not 3 (fan, light, and combo).
Did I just get a bad unit?
There are definitely some Hubitat driver code problems for the LZW36. I posted an issue on their github site about it a few days ago. When I first pair the device, it sets up as a "Inovelli Fan/Light Switch" - but the "default" driver doesn't allow you to adjust the various configuratin parameters. When I then update the driver to the latest one on the Hubitat github site (the Aug. 14, 2020 version), it leaves extra child devices in the interface. I assume (hope) they'll sort this out soon, but for now, I also can't get the LZW36 to work correctly (Hubitat C-7 hub; latest firmware 2.2.3.119
and using the beta 1.36 firmware for the LZW36 (though it didn't work with the release firmware either))
That's the Inovelli Github, while the issue you noted about being able to delete (or rather not) the original child devices is an issue with the Hubitat driver that Inovelli can't fix. It's typical for built-in drivers to not have every single parameter exposed (the Basic Z-Wave Tool or third-party drivers can help there), but there are indeed some problems with at least the fan portion of that driver. I think Inovelli's hahe worked fine for me, but I'm not using it on the C-7 or with security at the moment, so there may still be something there. In any case, I've also reported the Hubitat-specific issues to Hubitat, so well see if they're addressed in the next update.
1 Like
I'm assuming it must be the case that if you switch from the built-in driver to Inovelli's, then the Inovelli driver should construct the child devices properly using the getChildDevices and deleteChildDevice methods to remove anything left over from a prior driver and addChildDevice method to add its child devices. It doesn't seem to do this. Also, from what I can see, even if you install the Inovelli github driver before pairing the switch, Hubitat defaults to its built-in driver. Thus, you have to switch over after pairing -- so there is no way to get the Inovelli driver to work as it creates the extra child devices during the switch over. The solution may be simply to make the "github" version of the Inovelli driver the default / built-in version so the correct driver installs in the first instance.
There currently is no way to do this that I know of. If Hubitat has a driver for the device it will always be the default. Depending on how the child devices are created, you may have the ability to delete them. The Hubitat driver makes the child devices in a way that they can't be deleted from the web interface (easily). If you are familiar with the browser developer tools you can temporary remove the "disabled" tag from the button and it will let you delete it.
I have added code to delete the Hubitat created child devices, but it should have worked before without removing them (it just looked cluttered with extra devices).
@cpwilhelmi When you restore power from the breaker does the light on the fan start "pulsing"?
That should be fixed in the current release
1 Like
Thanks. I'll give the update driver a try.
As for the seletion of defaults, if there is a user-installed and a Hubitat default driver, it seems the user-installed one should override the Hubitat built-in (user-installed drivers often have more functionality; and why else would a user install a driver with a matching fingerprint if not to override the built-in one), or else the user should be presented with a choice at the time the physical device is paired.
1 Like
Does the current release fix the issue with the LZW42 bulbs not communicating during a z-wave repair?
I haven't heard of this issue. Is this with a specific firmware for the hub or a specific version of the hub (C-7, C-3, etc.)?
@ericm The hub is a C4. It was at version 2.2.3.132 when I tried this. When the z-wave repair gets to one of these bulbs it starts the repair and when it gets to the part called "Repair is requesting device associations" it then repeats that step 4 times and simply goes on to the next device. See below. Node 49 is there to show that it goes on without completing 209.
sys:12020-08-25 11:30:25.160 am traceZ-Wave Node 49: Repair starting
sys:12020-08-25 11:27:24.756 am traceZ-Wave Node 209: Repair is requesting device associations
sys:12020-08-25 11:25:54.345 am traceZ-Wave Node 209: Repair is requesting device associations
sys:12020-08-25 11:24:24.332 am traceZ-Wave Node 209: Repair is requesting device associations
sys:12020-08-25 11:22:52.026 am traceZ-Wave Node 209: Repair is requesting device associations
sys:12020-08-25 11:22:49.746 am traceZ-Wave Node 209: Repair is updating neighbors
sys:12020-08-25 11:22:49.274 am traceZ-Wave Node 209: Repair setting SUC route
sys:12020-08-25 11:22:49.248 am traceZ-Wave Node 209: Repair pinging
sys:12020-08-25 11:22:49.246 am traceZ-Wave Node 209: Repair starting
This is how it is supposed to look like. Node 48 is right before 209 and completes.
sys:12020-08-25 11:22:42.260 am traceZ-Wave Node 48: Repair is done.
sys:12020-08-25 11:22:42.250 am traceZ-Wave Node 48: Repair is requesting node neighbor info
sys:12020-08-25 11:22:42.248 am traceZ-Wave Node 48: Repair is adding return route
sys:12020-08-25 11:22:42.247 am traceZ-Wave Node 48: Repair is deleting routes
sys:12020-08-25 11:22:42.210 am traceZ-Wave Node 48: Repair is requesting device associations
sys:12020-08-25 11:22:40.093 am traceZ-Wave Node 48: Repair is updating neighbors
sys:12020-08-25 11:22:39.293 am traceZ-Wave Node 48: Repair setting SUC route
sys:12020-08-25 11:22:39.243 am traceZ-Wave Node 48: Repair pinging
sys:12020-08-25 11:22:39.242 am traceZ-Wave Node 48: Repair starting
@ericm Well, I just updated to 2.2.3.135. I included 3 of the LZW42's onto the hub. All of them went quickly through and finished. There is a slight difference to the log which I have shown. New info shown for dev:1250 which is not in the log above. 
dev:12502020-08-26 01:59:00.418 pm debugAssociation Report - Group: 1, Nodes: [01]
dev:12502020-08-26 01:59:00.414 pm debugparse:zw device: 2D, command: 8503, payload: 01 01 00 01 , isMulticast: false
sys:12020-08-26 01:59:00.411 pm traceZ-Wave Node 45: Repair is done.
sys:12020-08-26 01:59:00.401 pm traceZ-Wave Node 45: Repair is requesting node neighbor info
sys:12020-08-26 01:59:00.397 pm traceZ-Wave Node 45: Repair is adding return route
sys:12020-08-26 01:59:00.395 pm traceZ-Wave Node 45: Repair is deleting routes
sys:12020-08-26 01:59:00.359 pm traceZ-Wave Node 45: Repair is requesting device associations
sys:12020-08-26 01:58:59.576 pm traceZ-Wave Node 45: Repair is updating neighbors
sys:12020-08-26 01:58:59.223 pm traceZ-Wave Node 45: Repair setting SUC route
sys:12020-08-26 01:58:59.202 pm traceZ-Wave Node 45: Repair pinging
sys:12020-08-26 01:58:59.198 pm traceZ-Wave Node 45: Repair starting
Funny thing is that the update 135 does not mention a fix for the color bulb just the white.
