Z-wave reaction time ro setting switch state in openhab

Setup, Configuration and Use Installation
,
1

I have noticed a ~1.5s delay between turning a z-wave switch on with openhab 3 z-wave binding and actually turning the light on. My network is currently a single light switch connected to a zw090-c aeotec z-stick gen 5 controlled by a rbpi 3 1gb. I am also using a proprietary gw by Keemple (Polish brand for OBLO) and their delay is so small that I cant even measure it. The switch reacts in an instant.

I also have a zigbee usb dongle cc2531 connected (~5 devices network). Is it possible that it slows down the serial connection to z-wave devices?

Now the main question: would zwavejs2mqtt over generic mqtt binding work faster than openhab’s z-wave binding?

2

It is doubtful changing bindings could help for a couple of reasons.

You may have zombie nodes defined in the network slowing down routing.

My research says zwavejs2mqtt is already deprecated in some systems of favor of using websockets instead of MQTT. Nobody has yet written an OH binding to use that.

3

You may have confused zwavejs2mqtt with zwave2mqtt. The first one is fine, the latter one is deprecated.

Thank you for your response. Maybe somebody was experimenting with zwavejs2mqtt?

4

I notice Home Assistant is using a preferred Websocket integration after starting with zwavejs2mqtt (after zwave2mqtt)

5

Can you tell about any possible usage lag with zwave js websocket integration in HomeAssistant? I mean the delay between setting a switch state in HA and seeing the device (a lightbulb?) turning on.

6

Usually such delays are caused in the Z-Wave network either by zombie nodes or poor signal.

I have not used HA for a couple of years but an intrigued with the changes.

7

Well I guess that zombie nodes are not possible in my case, because the network consists of a dongle and a single light switch. I also imagine that the signal is as strong as it may get, as the dongle is ~2.5m away from the light switch.

8

If you excluded and included multiple times zombie nodes are entirely possible nodes do not always get completely excluded from the controller.

1 Like
9

To get things sorted out, my z-wave network in openhab is kind of experimental, but I have paired my switch in a single attempt. I haven’t tried to remove any node yet, therefore I don’t think I have any dead ones.

10

We’re all just guessing, but zombie nodes can of course be caused by a bad inclusion. It seems unlikely if you only have the controller, and your light is node ID 2?

No doubt you have checked the debug logs to see what is happening? If not, this might help you understand why there is a delay - it’s always a good place to start troubleshooting :slight_smile:

1 Like
11

Is that why you included that in the binding documentation?

Perhaps it might be a useful thing to read. :wink:

12

Actually, upon further research, what confused me is that the zwavejs2mqtt Docker container also has their ws-server for websokets. MQTT is a publish-subscribe model and websockets are designed for bidirectional communication.

Their documentation is geared heavily toward home Assistant. Apparently their main developer works for an Italian IoT company.

I am starting to look at zwavejs2mqtt using their Docker container.

13

Any suspicious info in z-wave debug log?
Did you try to heal your node?
When you change the state of switch in OH is it shown instantly in event log?

14

I traced the problem to the way the mobile application works. When I use the Models in web browser, the Things react instantly. When I use the mobile application, the delay is present. Seems like the mobile application is reconnecting to the server with every command.