Inovelli LZW30 lag/delays

Configuration Z-Wave
1

Hello, I am replacing some failing GE ZW4005 or Jasco 14291 with Inovelli LZW30 On/Off switches and I am ready to drop them in a lake…

I have been using HA for years without any issues with the Jasco/GE switches as Secure nodes and there is something wrong with Inovelli in which the lag and delay for turning a light on or off it can take several seconds or even close to a minute. If you try the same switch a few times they go nuts.

I was using HA in a Raspberry 4 and then switched to a regular PC i5 with 16 GB of RAM so it is not a hardware limitation of the host and I am using the AEON Labs ZW090 Z-Stick Gen5 stick. All the other remaining Jasco/GE switches work perfectly.

I have seen a multitude of posting about configuration changes and followed some of them but kind of lost if this is just not properly compatible or something I am missing in the configs.

I already have the following files in HA:

/opt/open-zwave/config/inovelli/lzw40.xml

/opt/open-zwave/config/manufacturer_specific.xml which contains:

<Manufacturer id="031E" name="Inovelli">
    <Product type="0002" id="0001" name="LZW30-SN Switch Red Series" config="inovelli/lzw30-sn.xml"/>
    <Product type="0004" id="0001" name="LZW30 Switch" config="inovelli/lzw30.xml"/>
    <Product type="0001" id="0001" name="LZW31-SN Dimmer Red Series" config="inovelli/lzw31-sn.xml"/>
    <Product type="0003" id="0001" name="LZW31 Dimmer" config="inovelli/lzw31.xml"/>
    <Product type="0005" id="0001" name="LZW42 Multi-Color Bulb" config="inovelli/lzw42.xml"/>
    <Product type="0006" id="0001" name="LZW41 Multi-White Bulb" config="inovelli/lzw41.xml"/>
    <Product type="0007" id="0001" name="LZW40 Dimmable  Bulb" config="inovelli/lzw40.xml"/>
    <Product type="000d" id="0001" name="LZW60 4-in-1 Sensor" config="inovelli/lzw60.xml"/>
    <Product type="000e" id="0001" name="LZW36 Fan/Light Dimmer" config="inovelli/lzw36.xml"/>
  </Manufacturer>

Any other parameter to adjust?

Thanks

Paul

2

My lzw31 switches have always been a bit slow. The UI for example from on after switching off, shows off, on, off. I think there was a good reason for this, but I forget why now.

You probably don’t want them as secure nodes either. Secure traffic is much slower iirc.

3

#1 Don’t include nodes as secure unless they need it, needlessly slows things down.
#2 Inovelli devices have a nifty feature that tells you the signal strength, check the manual.

All my Inovelli switches are instant, minus the 700ms delay, for scene support, that you can toggle off in the latest firmware.

4

As these are replacement switches there should not be any signal îssues, I have only used secure nodes and the previous GE/Jasco were too for over 3 years.

With an i5 CPU computer, SSD and 16 gb of ram there are no performance issues. They used to run perfectly on a raspberry before so that is not it.

Is the location /opt/open-zwave/config/manufacturer_specific.xml the correct one or should be inside the .homeassistant directory?

If not I will drop the invovelli and buy ge again…what a pain they have been…

5

It can be anywhere you like as long as the path is valid and the permissions are set so Home Assistant can read them.

6

As others have said, do not pair the new switches using secure inclusion. There is literally nothing to be gained from doing so. In fact there’s more to be lost due to the added overhead. Using Z-Wave security roughly increases the amount of messaging 3X to perform the same action securely vs without. That makes sense for devices like locks, GDO’s etc, but not simple light switches.

I ran a similar test a couple days ago with some new Eaton RFTR switches I was installing. When I had them connected the performance was terrible. Commands from the UI would take a full second or more while physical updates from the switch were in the 2-3 second range. Performance after re-pairing without security is nearly instant.

1 Like
7

So if the number of nodes i have has not increased, jasco switches under secure nodes worked perfectly for years, and the only change is a switch replacement in the indentical location a previous ge switch was the solution is to remove secure nodes?

Something is wrong with that logic…

8

You are correct in that there’s something wrong with your logic, or rather likely how you remember things… The 14291 that you are replacing it with does NOT pair securely. I have two dozen of them and can confirm with absolute certainty they do not. But you don’t have to take my word for it, it’s also called out in the Z-wave certification.

So when you had those connected and working they were not using S0 or S2 security… Just plain, unencrypted messaging.

9

Maybe, i am not arguing for sake but for the little I know.

For what I remember the switches were supported as secure nodes and indeed added them as secure, perhaps they are not fully compatible with the proper security definition is what you are saying?

I do have other devices which are secure for sure and don’t have any issues including several locks without the delays. I do have one old dimmer which does not support secure as far as I can see in the ha gui.

So again if the 14291 don’t support secure, but the inovelli do, the answer is still don’t use secure for inovelli?

If the overhead of secure is so high with 10 nodes, then who can use it?

Is it a zwave bandwidth issue? As far as the pc running ha the utilization is never higher than 2% for what I can see.

Thanks for the details…

10

No worries, I don’t think you’re arguing… There’s nothing wrong with looking for a logical explanation.

Here’s an example of a typical conversation between the hub and a device when polling for a current value… Each line represents a message that has to traverse your Z mesh, the arrows indicate direction…

Insecure:

Hub ----(get)---> Device
Hub <---(ack)---- Device
Hub <--(report)-- Device
Hub ----(ack)---> Device

Secure:

Hub ---(nonce get)--> Device
Hub <-----(ack)------ Device
Hub <----(nonce)----- Device
Hub ------(ack)-----> Device
Hub --(secure get)--> Device
Hub <-----(ack)------ Device
Hub <----(report)---- Device
Hub ------(ack)-----> Device

In this example, a polling request to a device generates two messages in each direction. That’s 4 messages that have to traverse the mesh. Securing this same conversation between devices now requires 9 messages, in addition to the processing overhead (encryption) of the Z-wave stack in both the hub USB stick and end device. Also keep in mind this is a single command… If the Innovelli is generating a report when the switch is controlled, that’s yet another conversation that is happening between devices.

Further adding to the sluggish feel would be if there are multiple hops between the controller and the device. Each routing device has to receive the message then forward it to the next hop, and so on, up to 4 times. The more hops that a message has to take, the more latency you’re going to have. Since secure communications requires more than double the number of back-and-forth messaging, the latency can grow by an order of magnitude versus insecure Z-wave when a device is multiple hops from the Z-Wave controller.

I recommend re-pairing the Innovelli switches without security. I bet they’ll be a lot snappier.

If you want to try something else, I’ve been installing the Eaton RF line of switches to replace my older GE 12722’s. The side-by-side performance between the Jasco 14291 and Eaton RF9601 is remarkable. A simple test to turn the switch on/off rapidly 4 times (on, off, on, off, on, off, on, off) bogged down the Jasco so much that it ended up reporting the wrong state. The same test with the RF9601 or one of the RFTR9605 receptacles I’m installing passed without any issue.

Just another option to consider.