OpenZWave: Received timeout notification Topic is solved

[Plantje]

After a reboot of the Domoticz server the motion detection stayed disabled. But still timeouts were coming in.

[heggink]

Maybe I am not following you but I would not expect polling to work at all on a battery operated zwave device since it goes into sleep in order to limit power usage. All you can do is lower the time in which the device itself reports states but you can't poll...

[Plantje]

Thanks for thinking along, but the multi sensors are not battery powered (fortunately!) They get power through USB.

[lost]

The Greenwave power nodes and power strip do blink green occasionally… as I understood that means they cannot report to the main station either. But they don't report time outs in the Domoticz log.
I will do more investigating, but at first glance it looks like a multi sensor is only reporting a time out as soon as it notices movement.
(...)
Seems logical that devices that have polling disabled don't present time outs.

As already noticed, your multi sensor is a battery device that'll shutdown it's z-wave radio to save battery almost all the time. Radio will only be powered when device have some data to send (like a switch that change state... temperature that'll change over a configurable step vs last reported one).

How can you expect such device with an almost always-off radio to answer pool requests from controller?

Your power node, on main supply, will probably be able to answer pools (it's radio being always on). Your multi just can't hear the controller screaming with it's ears blocked!

Generally speaking, pooling is now almost useless as current devices are intelligent&configurable enough to report only when needed. So you don't have to pool them + this will use radio bandwidth that may create problems if device nb grows.

The only use case I have for pooling, for a very specific device (on main supply but rechargeable battery backed) is this poor's man z-wave jamming detection setup:
https://www.domoticz.com/wiki/Alarm_Set ... ct_jamming

[Plantje]

Euh…. as already mentioned: my multi sensors are USB powered, not battery powered.
But perhaps disabling polling will work... As long as the device will continue to work as well

[heggink]

Euh…. as already mentioned: my multi sensors are USB powered, not battery powered.
But perhaps disabling polling will work... As long as the device will continue to work as well

True but that does not mean that you can poll. Many zwave devices are not pollable.

[heggink]

You can check in the control panel whether a device is asleep.

[Plantje]

Euh…. as already mentioned: my multi sensors are USB powered, not battery powered.
But perhaps disabling polling will work... As long as the device will continue to work as well

True but that does not mean that you can poll. Many zwave devices are not pollable.

Hmmm... ok, like that. I always thought that it had to be polled rather than it sending push messages as soon as something happens.
Let me just check this... If this is the case, what "lost" says makes a lot more sense.

[Plantje]

The Greenwave power nodes and power strip do blink green occasionally… as I understood that means they cannot report to the main station either. But they don't report time outs in the Domoticz log.
I will do more investigating, but at first glance it looks like a multi sensor is only reporting a time out as soon as it notices movement.
(...)
Seems logical that devices that have polling disabled don't present time outs.

As already noticed, your multi sensor is a battery device that'll shutdown it's z-wave radio to save battery almost all the time. Radio will only be powered when device have some data to send (like a switch that change state... temperature that'll change over a configurable step vs last reported one).

How can you expect such device with an almost always-off radio to answer pool requests from controller?

Your power node, on main supply, will probably be able to answer pools (it's radio being always on). Your multi just can't hear the controller screaming with it's ears blocked!

Generally speaking, pooling is now almost useless as current devices are intelligent&configurable enough to report only when needed. So you don't have to pool them + this will use radio bandwidth that may create problems if device nb grows.

The only use case I have for pooling, for a very specific device (on main supply but rechargeable battery backed) is this poor's man z-wave jamming detection setup:
https://www.domoticz.com/wiki/Alarm_Set ... ct_jamming

My apologies, switching off polling does seem to work. It is not a battery operated multi sensor, but as heggink mentioned as well: that doesn't mean it needs to be polled.

[heggink]

Glad it's clear now.

[Plantje]

Ok, the enormous list of timeouts is clear now. Since polling is switched off that doesn't occur anymore.

Still some timeouts do occur. If motion is detected in the bathroom the lights switch on for 15 minutes. I do that by switching on the lights and setting the "on time" of the sensor at 900 seconds.
In the logging I noticed a new timeout of the multisensory at 15 minutes after it detected motion; so when it switched off again.
Then I went into the bathroom again (in order to switch on the lights by the motion detected) and upon checking the logging I noticed that the "motion detected" also fired a timeout.

Could this perhaps be prevented by changing the blockly script to switch on the lights "for 15 minutes" and setting the "on time" to 0 seconds (or whatever the default is)?
The motion switch (and thus the lights) have just switched off again, but no new error is logged.
Triggered the motion again and no new error.

So, it is a lot better!

Edit: setting the lights to switch to level 100% for 15 minutes doesn't work. The lights simply don't switch on. Really strange...I have to figure out why.
I changed that back to just switch to level 100%. And I set the movement sensor to stay "on" for a minute. That does seem to work.

However, after switching off polling the light sensor is stuck. It doesn't retrieve that anymore. Should that be pushed at the moment motion is detected?

[jvdz]

So, what's the use of a multi sensor if you're not polling it?

You really should not be polling the sensor ( or any ZWAVE device for that matter) from the domoticz server as these are sensor devices which "sleep" between operations to preserve battery energy. They will obviously wakeup and send a status update each time the device has a change to report.
Some powered devices are known for not always properly updating their status, so those could be polled, but they need to be powered and always on or else it makes sense there are timeouts.

Jos

[Plantje]

Hmmm... ok, I'm a liiiittle bit at a loss here... I always thought that the reason I see usage of a power node and lux values of a multisensory is because of the polling... But it's the other way around? I set the devices to push every now and then?

With this in my mind I will review my setup...

[heggink]

You can usually configure the update interval through parameters in the zwave config screen. If the device is usb powered then no need to worry about batteries and put it on the minimum interval...

[Plantje]

Hmmm... that is not available for the greenwave power nodes and power strip, so I have to re-enable polling there.
The Aeotec power node does have a setting like that and it pushes the values every now and then.

As for the multi sensors: they do have quite some settings in order to push the values, but they don't seem to get pushed. The lux value stays the same constantly

Edit: found somewhere that someone had set the first group to send 255. Did that and now, without polling, every so often the illumination is sent

[lost]

Euh…. as already mentioned: my multi sensors are USB powered, not battery powered.
But perhaps disabling polling will work... As long as the device will continue to work as well

If this device is USB powered as an alternative to internal battery, it may behave as a battery-only device from a z-wave features point (i.e. most of the time sleeping, no ability to mesh/relay other devices radio etc).

I see later than pooling cause problems but a greenwave device does not allow setting upgrade rates (or when current value differ from last sent by a configurable figure). In fact, other peole complain about this manufacturer...

[Vopis]

Hi all,
I had this issue as well. I have an Aeotec Z-Stick Gen5 connected to my Raspberry Pi4 and 2xEurotronic Spirit Thermostats connected to it and once a day I loose connection with both Thermostats. I tried to re-connect the Z-Stick but it is not recovering, only reboot of RPi helps.
My Aeotec Z-Stick Gen5 is connected to an USB Hub, in the same HUB is also connected Zigbee2MQTT stick. When I was looking in the logs I found next interesting things:
2020-10-13 16:58:45.706 (Zigbee2MQTT) Zigbee2mqtt bridge is online
2020-10-13 16:58:45.821 (Zigbee2MQTT) Joining new devices is disabled on the zigbee bridge

After this, the Z-Stick timeout messages started coming:
2020-10-13 16:59:20.193 Status: OpenZWave: Received timeout notification from HomeID: 3585946855, NodeID: 7 (0x07)
2020-10-13 17:00:27.867 Status: OpenZWave: Received timeout notification from HomeID: 3585946855, NodeID: 6 (0x06)
2020-10-13 17:01:35.540 Status: OpenZWave: Received timeout notification from HomeID: 3585946855, NodeID: 6 (0x06)
2020-10-13 17:02:43.214 Status: OpenZWave: Received timeout notification from HomeID: 3585946855, NodeID: 6 (0x06)
2020-10-13 17:03:50.887 Status: OpenZWave: Received timeout notification from HomeID: 3585946855, NodeID: 6 (0x06)
2020-10-13 17:04:58.560 Status: OpenZWave: Received timeout notification from HomeID: 3585946855, NodeID: 6 (0x06)
2020-10-13 17:06:06.233 Status: OpenZWave: Received timeout notification from HomeID: 3585946855, NodeID: 6 (0x06)


The problem was solved by removing Zigbee2MQTT stick from the HUB and leave only Aeotec Z-Stick connected to the HUB and HUB connected to USB 2.0 port.
After this, I didn't have any timeouts. Probably the Raspberry Pi4 restarts the USB port connected to USB Hub which causes the loosing connection with Z-Stick and this triggers further timeouts.

[Plantje]

Thanks for sharing! I have a Conbee Zigbee stick. I will check if I see similar behavior.

[Vopis]

Let us know if this helped you.

[Plantje]

The problem was solved by removing Zigbee2MQTT stick from the HUB and leave only Aeotec Z-Stick connected to the HUB and HUB connected to USB 2.0 port.
After this, I didn't have any timeouts. Probably the Raspberry Pi4 restarts the USB port connected to USB Hub which causes the loosing connection with Z-Stick and this triggers further timeouts.

So, the main thing is that the Conbee stick cannot be connected to the same hub as the Aeotec Z-Stick? How has it been for you since you changed this?