Zwave JS LZW36 Driver

Integration is literally hours old at this point, but @EricM_Inovelli are you intending to/working toward drivers for the new new Zwave JS Server/Integration on HA?

It does pick up the device, but HA staff are basically stating it is non-compliant with the Z-wave specs (which I assume means that Z-wave hasn’t come up with a fan/light dual endpoint device spec lol).

Excited to try the new integration (feedback was impressive) but wanted to see what we might expect from Inovelli on this.

Thanks,

Kevin, superfan :smiley:

5 Likes

I already see a config file (lzw36.json), and this device seems to be working in zwavejs2mqtt, but it is not picking up the endpoints in HA.

Agreed, my device is showing as an LZW36 from Inovelli properly, but the driver isn’t working properly, it keeps saying the node isn’t responding to certain commands, marks it as dead, then it immediately wakes back up.

Hey all – I’ll start a PM on this topic so we can sort through everything. I’ll include @petro as well.

Then we can come back here and report back as it seems like there’s issues to be sorted out with LZW36 (Fan/Light) & LZW45 (Lightstrip).

4 Likes

Yeap, same issue here, no fan/light entities showing up with zwave js, and now zwave js is the official zwave platform for Home Assistant after Feburary’s release.

I spent the weekend getting my system updated (merged deprecated Z-Wave and Fibaro Home Center Light into Z-Wave-JS).

I don’t think the issue with the lights not showing up has anything to do with the driver. It works fine from the panel and if you get MQTT setup, it works properly through that channel as well (that’s my workaround for the moment).

Using Z-Wave Parameters for configuration isn’t working very good right now. You can setup the config from the Z-Wave-JS web page, but if you try to setup a notification using the partial config parameters, I’m finding it doesn’t work reliably.

Hopefully Z-Wave-JS will mature rapidly (it already seems to be, they added Dark Mode :crazy_face:).

Looks like this issue is expected to be fixed in the next HA patch (2021.2.2) per Update discovery scheme for zwave_js light platform by marcelveldt · Pull Request #46082 · home-assistant/core · GitHub

1 Like

I can confirm that the device now shows up in HA:
image

You will likely still need to use a fan template to get the fan to show up as something other than a light though.

3 Likes

Thanks for this, any chance you have completed code you could share? Was about to dive in but thought I would ask first!

Can you set parameters and color control? Looking to possibly move my zwave devices from Smartthings to Home-assistant, but losing the settings you can update easily in Smartthings for these switches has me on hold . Looks like basic control is working from the post by @jtronicus

The answer is a bit of “kind of”.

The current path forward for HA is ZwaveJS Server (Websocket) → ZwaveJS HA Integration. Right now the ZWave JS integration does not have a UI that can modify parameters, but it is on their path.

There is a second ZwaveJS2MQTT add-on that can be spooled up after taking down the ZwaveJS Server (however you are hosting) and using the same usb stick/network key, it can read in the nodes and DOES have a UI that can make changes. It can be used to serve the HA integration via websockets OR MQTT, but this is not the path forward for HA.

So what I currently do (again we are talking maybe a few months of this before HA integration has a UI) is:

  1. Take down ZwaveJS Server
  2. Spool up ZwaveJS2MQTT
  3. Change parameters, test, etc.
  4. Take down ZJS2M
  5. Spool up ZJS

Whole process takes about ~10 minutes to make changes, which, yes, admittedly is a pain, but it’s a workaround for MAYBE a few months for a MUCH better future outlook.

All of that said, they are ALSO working on a service that would allow automations to perform parameter changes based on events. The old integration you could program it to say “zwave.set_config_parameter”, send a snip of code, and it would change the parameter. That is ALSO in development and forthcoming, but is not currently available.

I am not sure why you are going through all of this complication. ZwaveJS2MQTT runs the ZwaveJS websocket server… you can just use that/keep that running since it can serve the UI and the websocket integration at the same time. I am doing this with HA Core.

Frankly because I don’t want to rename all of my entities AGAIN again. Plus I don’t change parameters often as a need so I’ve done this a total of MAYBE 3 times since switching over.

Plus plus I didn’t know about ZJ2M before I switched :D.

Yes having to move over from any of the other Zwave Home Assistant integrations and then rename everything again would be a huge pain, especially with having to redo all the automations. Fortunately for me, I’d be starting from scratch, and I now have ZwaveJS2MQTT up.

It looks to be a MASSIVE improvement over the prior alternatives. Poor Zwave integration in Home Assistant was the main reason I kept all my Zwave devices on Smartthings. However, this new ZwaveJS2MQTT seems like a game changer. I tested out a simple button remote (go control switch) and see all the parameters (screenshot below). Just curious about the LZW36 though since its so much more complex. The Smarthings device handler for that works great. I might just have to test one out on this new ZwaveJS2MQTT to see how it works. This is all new so I’m sure more features will be added in time.

ANNNND wouldn’t you know it there is already the ability in the latest beta:

the callout will be zwave_js.set_config_parameter (in beta as of this writing).

So literally I will just change my NR node from “ozw” to “zwave_js” and it should magically work again.

WOOT.

2 Likes

Anyone else not getting meter reports from their 36’s? I’ve just noticed that a change in state (with parameters set at defaults but also set differently to test) no longer reflects an update in the meter or energy sensors.

Can someone else validate they are having the same experience? @jtronicus @mwav3

Edit: Also my 1.31 firmware Guest Bedroom fan is turning on the light when I turn on the fan via z-wave dashboard??? Is this what I get for going on vacation???

Meter reports seem to be working fine for me.

Also, there was a recent change in the device config files for the LZW36 in order to work around a firmware bug. I would make sure you are on the latest version of zwavejs and reinterview the node if possible

1 Like

I reset the switch and still am not getting meter reports in ZJS, but I think it’s my cache that needs flushed.

On to the next problem. Anyone else seeing their light turn on when the fan is turned on? Mine is happening reliably on all 3 of my 36’s:

2021-04-28T15:46:02.641Z DRIVER » [Node 075] [REQ] [SendData]
│ transmit options: 0x25
│ callback id: 37
└─[MultiChannelCCCommandEncapsulation]
│ source: 0
│ destination: 2
└─[MultilevelSwitchCCSet]
target value: 0
2021-04-28T15:46:02.645Z SERIAL « [ACK] (0x06)
2021-04-28T15:46:02.654Z SERIAL « 0x0104011301e8 (6 bytes)
2021-04-28T15:46:02.654Z SERIAL » [ACK] (0x06)
2021-04-28T15:46:02.655Z DRIVER « [RES] [SendData]
was sent: true
2021-04-28T15:46:02.706Z SERIAL « 0x011800132500000501b97f7f7f7f000103150000000201000078 (26 bytes)
2021-04-28T15:46:02.707Z SERIAL » [ACK] (0x06)
2021-04-28T15:46:02.708Z DRIVER « [REQ] [SendData]
callback id: 37
transmit status: OK
2021-04-28T15:46:02.714Z CNTRLR [Node 075] [~] [Multilevel Switch] currentValue: 66 => 0 [Endpoint 2]
2021-04-28T15:46:03.794Z SERIAL « 0x010b0004004b03260300b80025 (13 bytes)
2021-04-28T15:46:03.796Z CNTRLR [Node 075] [~] [Multilevel Switch] currentValue: 99 => 0 [Endpoint 0]
2021-04-28T15:46:03.797Z SERIAL » [ACK] (0x06)
2021-04-28T15:46:03.798Z DRIVER « [Node 075] [REQ] [ApplicationCommand]
└─[MultilevelSwitchCCReport]
current value: 0
2021-04-28T15:46:03.811Z CNTRLR [Node 075] Mapping unsolicited report from root device to first supporting end
point #1
2021-04-28T15:46:03.812Z CNTRLR [Node 075] [~] [Multilevel Switch] currentValue: 99 => 0 [Endpoint 1]
2021-04-28T15:46:07.734Z SERIAL » 0x010d00134b06600d000226022526e4 (15 bytes)
2021-04-28T15:46:07.734Z DRIVER » [Node 075] [REQ] [SendData]
│ transmit options: 0x25
│ callback id: 38
└─[MultiChannelCCCommandEncapsulation]
│ source: 0
│ destination: 2
└─[MultilevelSwitchCCGet]
2021-04-28T15:46:07.740Z SERIAL « [ACK] (0x06)
2021-04-28T15:46:07.749Z SERIAL « 0x0104011301e8 (6 bytes)
2021-04-28T15:46:07.749Z SERIAL » [ACK] (0x06)
2021-04-28T15:46:07.750Z DRIVER « [RES] [SendData]
was sent: true
2021-04-28T15:46:07.799Z SERIAL « 0x011800132600000601b87f7f7f7f000103150000000201000079 (26 bytes)
2021-04-28T15:46:07.800Z SERIAL » [ACK] (0x06)
2021-04-28T15:46:07.801Z DRIVER « [REQ] [SendData]
callback id: 38
transmit status: OK
2021-04-28T15:46:07.881Z SERIAL « 0x01110004004b09600d02002603000000b8005a (19 bytes)
2021-04-28T15:46:07.883Z CNTRLR [Node 075] [~] [Multilevel Switch] targetValue: 0 => 0 [Endpoint 2]
2021-04-28T15:46:07.884Z CNTRLR [Node 075] [~] [Multilevel Switch] duration: {“value”:0,“unit”:“s [Endpoint 2]
econds”} => {“value”:0,“unit”:“seconds”}
2021-04-28T15:46:07.885Z CNTRLR [Node 075] [~] [Multilevel Switch] currentValue: 0 => 0 [Endpoint 2]
2021-04-28T15:46:07.886Z SERIAL » [ACK] (0x06)
2021-04-28T15:46:07.887Z DRIVER « [Node 075] [REQ] [ApplicationCommand]
└─[MultiChannelCCCommandEncapsulation]
│ source: 2
│ destination: 0
└─[MultilevelSwitchCCReport]
current value: 0
target value: 0
duration: [Duration: 0 seconds]

1 Like

Latest ZJS update fixed it. I reported the logs and they had not yet implemented the compat flag for the incorrect reporting by the driver.

I guess @EricM_Inovelli is aware of the issue and is working with the ZJS team to resolve, but for now it’s working great!

2 Likes