Hi there,
I have about 20 Z-Wave devices in my environment, including several battery based door/windows contacts, all working fine.
Two days ago I successfully migrated from microSD to SSD via Full Backup and it seems that everything is basically working.
However, there is one issue with Z-Wave JS:
The network graph shows one of the door/windows contacts (“Terassentürkontakt”) as not connected, that means it is shown as grey square symbol with no connection (edge) to any other node.
Nevertheless this node is operating normally and the Control Panel shows no problems, see screenshots.
I have tried to reset the node by disconnecting the battery, also tried to rebuild the connection, but with no success. I have not yet done an new inclusion, since the node is recognized wth all sensors working.
Is this a bug in the network graph part, or a problem with my setup?
Again: Before restoring the full backup to the SSD, it was all normal.
Gray means Unknown (the network graph has a legend) it does not mean “not connected”. Unknown simply means the software doesn’t have any routing information yet. It doesn’t have any relation to the device status. You will need to issue some command to the device and wake it up manually in order for the information to be updated, or just wait for it to wake up on its normal interval schedule which will have the same effect.
Thanks for your feedback.
The node has the same configuration like the other doorr/window contacts and the wake up interval is set to 6 hours, so it should have happened 3 to 4 times already.
But why is the Control Panel showing green states for “Rebuild routes” and “Interview complete”. Doesn’t it mean that the device and route is known?
Those have nothing to do with routing statistics. Routing statistics are provided by some messages from the device. You’ll need to dig into the debug driver logs if you want to investigate further. Look for instances of communication with the device and see if the route information is provided.
Problem is now solved, the node 30 is now shown with a route to the controller.
It looks to me that changing the debug settings caused a driver restart, and that somehow resulted in correct retrieving the routing info for node 30.
So there would be still the question, why the initial driver start was missing this one node route, but anyway thanks for pointing me into this area!
Nob
