New ZWave network unstable (4.9999 beta)

[Odiebla]

Hi All,

I've been using domoticz for a while with my Hue Zigbee network and some simple network/device stats but recently I wanted to start doing more and decided to look into Zwave. I bought myself some gear to start with: a Aeotec Stick Gen5, Aeotec Multisensor, Aeotect Switch, Qubino 0-10v dimmer and a Fibaro wall plug.

I started with the Zstick in a Ubuntu NUC with the latest beta (now 4.9999) on ground level (utilities cabinet), the Aeo switch on the first floor and the Qubino on the 3rd floor (it drives the ventilation of my house). Soon I started to experience network issues where devices would die on me. I noticed in the network graph that the Aeotec switch was not forming a full mesh and this was actually the device that died the most on me, although it was only 1 floor away from the controller. I replaced the device with the Fibaro plug and all problems seemed gone but after two days the Fibaro also lost contact with the controller. Oddly enough: the Qubino in the 3rd floor is still able to talk to the controller (3 floors away) so why would the Fibaro only 1 floor away refuse to talk to the controller? I then moved the stick to my laptop in the living room, moved the fibre plug to a new wall socket in my living room (2 meters from the laptop) and... nothing. Resetting domoticz did not help, resetting the stick did not help, resetting the plug did not help, initiating a node heal and a network heal did not help. But still the Qubino on the 3rd floor kept talking to the controller do surely the controller and domoticz are up. Also the Aeotec sensor in the bathroom (2 floors up from the controller, between the attic with the Qubino and the living room with the Fibaro plug) keeps reporting movement to Domoticz.

This is kind of frustrating especially because I do not seem to be able to revive from this situation without doing a hard reset of all equipment and start including the devices again (which I've done before and this seems to solve the situation for a short time, hours to days).

At this point in time I'm stuck so any help would be appreciated. Especially interesting is: how does one deal with dead nodes, how do you normally force to revive them without doing an exclude/include again? The heal node and heal network seems not to do anything here.

I understand that my network is still minimal (with only 5 devices spread over 4 floors) but that does not explain why moving devices closer to each other does not automatically solve the connectivity.

[arass]

I thing you didn't need to do hard reset of z-wave controller - include lost devices is enough. I had the same issue after upgrade to 4.9999.

[gizmocuz]

The zwave stick has it's own memory and operates on it's own. There is no way that 'suddenly' you miss a node caused by a software application update

[Odiebla]

I’m not suggesting the problems started after a software update. However, I do read that OpenZwave handles a dead node list so your comment that this is entirely up to the software on the stick seems not accurate?

http://www.openzwave.com/knowledge-base/deadnode

[arass]

I had two cases of some nodes disappearing: after upgrading domoticz and after taking an image backup (dd). Indeed, I suggested that you were similar

[emme]

openZWave stack is included and compiled with domoticz releases (stable or beta) but it is not maintained by domoticz.... so, it is a good habit to take note of the stack version before updating and, in case, keep a copy of the old installation: just backup the /domoticz folder

the first tentative you can do is to hail the network (would take from mins to hours depending on the network): this would recreate the communication network between controller and nodes

You could also have interference problems... but this can depend by your home and external interferences
ciao
M

[Odiebla]

With 'hail' I think you mean 'heal' (under Node Management, Heal Network)? I've tried this, per node and network wide. Also I tried reviving the node in question by triggering a NIF frame (pressing the inclusion button on the affected node) and all 3 actions doesn't seem to do anything. At first sight no action seemed to happen, but when I turned on OZW debugging I could see that there is actual healing taking place. However, the network is currently up and running again after the manual exclusion/inclusion so there is little to see there. Next time the network breaks again I will dig into the debugging to see what happens. But one thing I already know: it didn't revive the dead node last time.

[emme]

With 'hail' I think you mean 'heal'

d'ho!

it is also good to get a copy of zensys tool (quite difficult to find right now) that can make some operations (like forcing to remove a dead node) that normally are not supported.

ciao
M

[Odiebla]

So I've got a dead node again and this is getting annoying. Because this is what happens when I initiate a node heal: the actual attempt is not even being transmitted because the node is assumed dead. Well yeah DOH, that's why I'm initiating a heal command on the node: because it's marked dead. What is the point of offering this if you refuse to try to heal the damn thing

I understand the dead marking: this prevents the network under normal circumstances to keep retransmitting normal instructions and flood the network unnecessary. However in my humble opinion a heal command should always be executed:

2018-09-22 11:30:43.247 Detail, Node002, Queuing (Controller) Request Node Neighbor Update
2018-09-22 11:30:43.247 Detail, Node002, Queuing (Controller) Delete All Return Routes
2018-09-22 11:30:43.247 Detail, Node002, Queuing (Controller) Assign Return Route
2018-09-22 11:30:43.247 Info, Requesting Neighbor Update for node 2
2018-09-22 11:30:43.247 Detail, Node002, Queuing (Command) ControllerCommand_RequestNodeNeighborUpdate (Node=2): 0x01, 0x05, 0x00, 0x48, 0x02, 0x23, 0x93
2018-09-22 11:30:43.248 Detail, Notification: ControllerCommand - Starting
2018-09-22 11:30:43.248 Error, Node002, ERROR: Dropping command because node is presumed dead
2018-09-22 11:30:43.248 Always,
2018-09-22 11:30:43.248 Always, Dumping queued log messages
2018-09-22 11:30:43.248 Always,
2018-09-22 11:30:43.248 Always,
2018-09-22 11:30:43.248 Always, End of queued log message dump
2018-09-22 11:30:43.248 Always,
2018-09-22 11:30:43.248 Detail, Node002, Removing current message
2018-09-22 11:30:43.248 Detail, Notification: ControllerCommand - Error - Failed
2018-09-22 11:30:43.248 Info, Deleting all return routes from node 2
2018-09-22 11:30:43.248 Detail, Node002, Queuing (Command) ControllerCommand_DeleteAllReturnRoutess (Node=2): 0x01, 0x05, 0x00, 0x47, 0x02, 0x24, 0x9b
2018-09-22 11:30:43.248 Detail, Notification: ControllerCommand - Starting
2018-09-22 11:30:43.248 Error, Node002, ERROR: Dropping command because node is presumed dead
2018-09-22 11:30:43.248 Always,
2018-09-22 11:30:43.248 Always, Dumping queued log messages
2018-09-22 11:30:43.248 Always,
2018-09-22 11:30:43.248 Always,
2018-09-22 11:30:43.248 Always, End of queued log message dump
2018-09-22 11:30:43.248 Always,
2018-09-22 11:30:43.248 Detail, Node002, Removing current message
2018-09-22 11:30:43.248 Detail, Notification: ControllerCommand - Error - Failed
2018-09-22 11:30:43.248 Info, Assigning return route from node 2 to node 1
2018-09-22 11:30:43.248 Detail, Node002, Queuing (Command) ControllerCommand_AssignReturnRoute (Node=2): 0x01, 0x06, 0x00, 0x46, 0x02, 0x01, 0x25, 0x99
2018-09-22 11:30:43.248 Detail, Notification: ControllerCommand - Starting
2018-09-22 11:30:43.248 Error, Node002, ERROR: Dropping command because node is presumed dead
2018-09-22 11:30:43.248 Always,
2018-09-22 11:30:43.248 Always, Dumping queued log messages
2018-09-22 11:30:43.248 Always,
2018-09-22 11:30:43.248 Always,
2018-09-22 11:30:43.248 Always, End of queued log message dump
2018-09-22 11:30:43.248 Always,
2018-09-22 11:30:43.248 Detail, Node002, Removing current message
2018-09-22 11:30:43.248 Detail, Notification: ControllerCommand - Error - Failed

[Solderbro]

Hmm with 4.9980 is found something nearby. Devices that get lost and included with a new ID will splitter into both devices, because the old one cannot be deleted for real.

Aeotech C5 00000D33 1 Bad Hzg Alarm Type Light/Switch Switch Off - 100 [Als unbenutzt festlegen] [Gerät umbenennen]
Aeotech C5 00000D32 1 Bad Hzg Alarm Level Light/Switch Switch Off - 100 [Als unbenutzt festlegen] [Gerät umbenennen] Aeotech C5 00000D36 1 Bad Hzg Power Management Light/Switch Switch Off - 100 [Als unbenutzt festlegen] [Gerät
Aeotech C5 00000D37 1 Bad Hzg System Light/Switch Switch Off - 100 [Als unbenutzt festlegen] [Gerät umbenennen]
Aeotech C5 00000D36 8 Bad Hzg Power Management 8 (0x08) General Alarm Event: 0xFE (254) - 100 [Als unbenutzt festlegen] Aeotech C5 00000D37 9 Bad Hzg: System 9 (0x09) General Alarm Event: 0xFE (254)
Aeotech C5 0601 1 Bad Hzg Temperature Temp LaCrosse TX3 23.3 C

As you can see here, one heating valve runs under #06 and #0d while both of them cause a lockup. It's unusable....

Greetz
Eric