OpenZWave: Received timeout notification Topic is solved

[Varazir]

Hello,

I keep getting "OpenZWave: Received timeout notification" on all my devices.

Code: Select all

2017-08-19 08:17:10.634 OpenZWave: Received timeout notification from HomeID: 3260666225, NodeID: 8 (0x08)
2017-08-19 08:25:21.094 OpenZWave: Received timeout notification from HomeID: 3260666225, NodeID: 12 (0x0c)
2017-08-19 08:25:31.096 OpenZWave: Received timeout notification from HomeID: 3260666225, NodeID: 12 (0x0c)
2017-08-19 08:29:11.121 OpenZWave: Received timeout notification from HomeID: 3260666225, NodeID: 12 (0x0c)
2017-08-19 08:32:57.036 OpenZWave: Received timeout notification from HomeID: 3260666225, NodeID: 12 (0x0c)
2017-08-19 08:40:26.651 OpenZWave: Received timeout notification from HomeID: 3260666225, NodeID: 12 (0x0c)
2017-08-19 08:40:45.054 OpenZWave: Received timeout notification from HomeID: 3260666225, NodeID: 13 (0x0d)
2017-08-19 08:40:55.056 OpenZWave: Received timeout notification from HomeID: 3260666225, NodeID: 13 (0x0d)
2017-08-19 08:43:22.898 OpenZWave: Received timeout notification from HomeID: 3260666225, NodeID: 12 (0x0c)
2017-08-19 08:45:50.562 OpenZWave: Received timeout notification from HomeID: 3260666225, NodeID: 12 (0x0c)
2017-08-19 08:50:36.056 OpenZWave: Received timeout notification from HomeID: 3260666225, NodeID: 6 (0x06)
2017-08-19 08:50:46.058 OpenZWave: Received timeout notification from HomeID: 3260666225, NodeID: 6 (0x06)
2017-08-19 08:51:15.498 OpenZWave: Received timeout notification from HomeID: 3260666225, NodeID: 12 (0x0c)
2017-08-19 08:57:32.532 OpenZWave: Received timeout notification from HomeID: 3260666225, NodeID: 12 (0x0c)
2017-08-19 09:00:05.479 OpenZWave: Received timeout notification from HomeID: 3260666225, NodeID: 13 (0x0d)

2017-08-19 08_59_34-Domoticz.png (64.82 KiB) Viewed 12487 times

Anything I can change to get it to work better ?

TIA
Daniel

[Timothy]

I'm expieriencing the same problems. Mostly on a new "Qubino Flush 2 relays". The network seems to be working normaly but the notifications don't seem normal. I hope someone has a clue where to look to solve this problem.

[Timothy]

Some more information, in the OpenZWave control panel I have many from this errors. Do you have the same errors?

2017-08-22 16:44:36.613 Error, Node018, ERROR: Dropping command, expected response not received after 1 attempt(s)
2017-08-22 16:44:36.613 Always,
2017-08-22 16:44:36.613 Always, Dumping queued log messages

[Varazir]

I got a new beta update today and the spamming of notifications has stopped

[Varazir]

Some more information, in the OpenZWave control panel I have many from this errors. Do you have the same errors?

2017-08-22 16:44:36.613 Error, Node018, ERROR: Dropping command, expected response not received after 1 attempt(s)
2017-08-22 16:44:36.613 Always,
2017-08-22 16:44:36.613 Always, Dumping queued log messages

Nothing like that in the OpenZWave Control Panel.

[Plantje]

Ever figured this one out? I got the same issue and I am checking forum posts, but it is not really helping.

[dextm80]

same issue with the latest beta....

[XerachCruz]

Same issue here.

We has drag this issue from the last three beta updates.

I've realized that it only happens with the modules that are not directly connected to the stick. If the signal has to pass through other modules of the network before reaching the stick, the timeouts begin and the entire mesh become unestable for a time.

I hope the issue has resolve soon, is very annoying.

Thanks.

[Plantje]

Nice one, that you figured that out!

I have quite some Z-Wave devices, not all of them act as a repeater (smoke sensors for example), but in general I should have a pretty decent network signal everywhere. Still some of the smart plugs from Greenwave I have start flashing green every once in a while. Which, I think, means they lost the network.

[XerachCruz]

My mesh is still very small, I only have 5 modules installed and they are all the same (Qubino double relay and Qubino dimmer), so it is easy to make checks by moving the stick and recostuyendo the mesh from different places in the house.

If I put the Stick in the center of the house, the signal goes directly to all modules and there is no timesout, not have issue, everything works perfect. But if I put the Sitck in any room, the signal to some module on the opposite side of the mesh must arrive indirectly, and as soon as there is communication with this module, timeouts begin, and after that in the time that is "stuck" happen instabilities with the rest of the modules.

[Siewert308SW]

My mesh is still very small, I only have 5 modules installed and they are all the same (Qubino double relay and Qubino dimmer), so it is easy to make checks by moving the stick and recostuyendo the mesh from different places in the house.

If I put the Stick in the center of the house, the signal goes directly to all modules and there is no timesout, not have issue, everything works perfect. But if I put the Sitck in any room, the signal to some module on the opposite side of the mesh must arrive indirectly, and as soon as there is communication with this module, timeouts begin, and after that in the time that is "stuck" happen instabilities with the rest of the modules.

Thats true but doesn't reflect my/our issues, i think.
Don't have a big mesh either only 12 nodes.
Every battery powered node (3 Fibaro Motion and 4 Coolcam Door Sensors) have a powerplug (4 total) nearby.
I mean with in 2 to 3 meters while the controler is in the middle of the house and max distance is 4meters to any node.

I have one node (fibaro motion) within 1mtr from the Aeotec G5 stick and is spitting out timeouts.
Instead of connecting directly to the stick it finds a power plug to relay on but this plug is the farest away from them all.

Further more.
I also took a note on other node timeouts.
Those who timeout or sometimes declared dead aren't connected in any way to the controller.
They are connect to a powerplug which relays to the controller.
One node is relayed to two powerplug nodes which are connected to the controler while this node also reports to the controller directly.

Can't see why i do have timeouts.
in/excluding, resetting stick, removing xml or any other possible solution doesn't do the trick.
Only remember it started two weeks ago after a beta update.
I also suffer from the fact i don't see the Aeotec Config in cp.html while other nodes do.

[Plantje]

To be honest, isn't that exactly what XerachCruz said? Every node spitting out time outs isn't directly connected to the controller. Perhaps it is close enough that there is no need to connect through another node, but it DOES connect through another node and thus it is spitting out time outs.

I think I am seeing the same thing...

[Siewert308SW]

To be honest, isn't that exactly what XerachCruz said? Every node spitting out time outs isn't directly connected to the controller. Perhaps it is close enough that there is no need to connect through another node, but it DOES connect through another node and thus it is spitting out time outs.

I think I am seeing the same thing...

True... he mentioned earlier.
I was replying to his post where he mentioning changing position of the controller...

[Plantje]

Ah ok... my bad

[XerachCruz]

Also as I mentioned, when communicating with these modules indirectly and generate waiting times, the mesh is "obstructed" and for a while the rest of nodes also begin to generate waiting time, although they do communicate directly.

The nodes that communicate indirectly are the trigger. Simply, if one of those nodes communicates to read the energy consumption or the stick ask polling, creates timeouts with this node it and then, in others for a few seconds / minute.

Today I received the 3.8834 and the issue continues, I guess these new beta will be for other changes because nothing changes with this issue.

I placed my RPI3 with the stick in a bedroom where only communicates indirectly with one interuptor module that I hardly use, so I can check if the error continues when a new beta arrives, but my network is not unstable all the time because this node allways is off, only when I checking if the issue still there or switch on the terrace light.

[sysedit]

Did anyone find a solution for this issue ?
I've bought recently thermostatic heads to control room heating system ; it works ok, except that I'm getting very frequent timeouts, and if timeout occurs when Timers are supposed to change the setpoint, the change does not occur.

I can likely workaround that by not using timers and using a script, but that's weird ; I'd like to not have to move the controller to a closer place.

Is there anything I can do to help fixing this issue ? I'm building domoticz from source on Ubuntu x86 device - applying patches to add debug traces is not a problem if required.

[Plantje]

I placed my RPI3 with the stick in a bedroom where only communicates indirectly with one interuptor module that I hardly use, so I can check if the error continues when a new beta arrives, but my network is not unstable all the time because this node allways is off, only when I checking if the issue still there or switch on the terrace light.

Did moving the RPi3 help? Can you give an update on this? I am still seeing this issue.

[Siewert308SW]

I placed my RPI3 with the stick in a bedroom where only communicates indirectly with one interuptor module that I hardly use, so I can check if the error continues when a new beta arrives, but my network is not unstable all the time because this node allways is off, only when I checking if the issue still there or switch on the terrace light.

Did moving the RPi3 help? Can you give an update on this? I am still seeing this issue.

Have tried a lot, moving RPI and extending the USB cable to be able to move the Aeotec further away from any possible noise causing device and such but nothing helps.
I don't have timeouts during the day.
But only when i reboot the Pi i see timeouts when the Aeotec is initialized.
Nodes then have a timeout are powerplugs as well as battery powered devices.
Then i also see for all z-wave devices double entries like:

2018-04-07 09:27:16.720 (Aeotec Gen5) Lux (Gang - Lux)
2018-04-07 09:27:16.801 (Aeotec Gen5) Lux (Gang - Lux)
2018-04-07 09:27:16.814 (Aeotec Gen5) Lux (Gang - Lux)
This continues sometimes for 1 minutes and sometimes for 1 hour.

I tried to reset en setup all nodes several times as well as starting from scratch with Domoticz and such but this doesn't help.
Something aint right with the z-wave.
Issue seems to be resolved when all nodes awake queried.
Don't know what is happening in the background but looks like it stabilizes after a while.
Still it's annoying and rebooting the PI does trigger all Lua scripts as all z-wave devices are triggered like i mentioned above which is causing a high mem/cpu load.

My mesh looks stable.
All nodes do communicate directly to the controller and have routes via other nodes.
Side note: i do see after a reboot the mesh is empty and only shows the mesh as attached below after all nodes are quired.

Schermafdruk 2018-04-07 09.37.20.png (201.48 KiB) Viewed 10969 times

Schermafdruk 2018-04-07 09.24.09.png (112.24 KiB) Viewed 10969 times

[lost]

I don't have timeouts during the day.
But only when i reboot the Pi i see timeouts when the Aeotec is initialized.

Hello,

Try to look at this setup, leading to a problem I had at the very beginning with Domoticz. In my case, not true com problems but linked to my setup at the time: I only had devices I triggered (heater control) & still none reporting statues/measures, with a z-wave network unstable because of long inactivity & a Domoticz default TMO:

http://www.domoticz.com/forum/viewtopic ... ut#p113930

Not exactly the same symptoms & original post I made to explain the problem is over 2 years & not saved anymore but this 60s default timeout on z-wave network is too short & can lead to controller soft resets & z-wave topology being rebuilt... every minute...

[sincze]

I just added another NEO COOL Powerplug to the zwave network (secure node), running Domoticz V3.9138
It added just fine, And showed some values of Watt / KwH / Switch.

However a few minutes later ALL my powerplugs were not updated anymore.
seems.... my zwave network seems to be down.

I disabled and re-enabled the zwave stick (AEON LABS). -> No solution
I removed the zwave stick from the usb... and reattached it... -> No Solution

Code: Select all

[7927775.217400] usb 1-1.2: USB disconnect, device number 4
[7927785.241307] usb 1-1.2: new full-speed USB device number 8 using dwc_otg
[7927785.374618] usb 1-1.2: New USB device found, idVendor=0658, idProduct=0200
[7927785.374626] usb 1-1.2: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[7927785.375415] cdc_acm 1-1.2:1.0: ttyACM1: USB ACM device

But still no updates...

Code: Select all

2018-04-15 16:45:46.494 OpenZWave: Received timeout notification from HomeID: 3544590454, NodeID: 23 (0x17)
2018-04-15 16:45:47.496 OpenZWave: Received timeout notification from HomeID: 3544590454, NodeID: 24 (0x18)
2018-04-15 16:45:48.497 OpenZWave: Received timeout notification from HomeID: 3544590454, NodeID: 25 (0x19)
2018-04-15 16:45:49.498 OpenZWave: Received timeout notification from HomeID: 3544590454, NodeID: 27 (0x1b)
2018-04-15 16:45:50.502 OpenZWave: Received timeout notification from HomeID: 3544590454, NodeID: 30 (0x1e)
2018-04-15 16:45:51.503 OpenZWave: Received timeout notification from HomeID: 3544590454, NodeID: 31 (0x1f)
2018-04-15 16:45:52.505 OpenZWave: Received timeout notification from HomeID: 3544590454, NodeID: 32 (0x20)
2018-04-15 16:45:53.507 OpenZWave: Received timeout notification from HomeID: 3544590454, NodeID: 33 (0x21)
2018-04-15 16:45:54.508 OpenZWave: Received timeout notification from HomeID: 3544590454, NodeID: 34 (0x22)
2018-04-15 16:45:55.512 OpenZWave: Received timeout notification from HomeID: 3544590454, NodeID: 35 (0x23)
2018-04-15 16:45:56.513 OpenZWave: Received timeout notification from HomeID: 3544590454, NodeID: 36 (0x24)
2018-04-15 16:45:57.515 OpenZWave: Received timeout notification from HomeID: 3544590454, NodeID: 37 (0x25)
2018-04-15 16:45:58.517 OpenZWave: Received timeout notification from HomeID: 3544590454, NodeID: 38 (0x26)
2018-04-15 16:45:59.518 OpenZWave: Received timeout notification from HomeID: 3544590454, NodeID: 39 (0x27)

Door sensors don't respond. Clearly I have no clue.