Closed rrozema closed 3 years ago
You could press the Refresh node info button again and on your device press the little button to send the node information frame There is no need to exclude or include Also it is not removed from Domoticz, but from OpenZWave, maybe even the controller If you have access to your node's little button, it is better if you just press it, instead of pressing the button in Domoticz to query this. If the device is powered (like a switch or wallsocket) it is easier to press the button then to walk to the node
The refresh node info button doesn't work once the type and id shows 0x0000 because the device is no longer available: there is no node information to send it to.
And yes, you're right: the device is no longer available in openzwave, but that is because openzwave was explicitly instructed by Domoticz to remove it... Domoticz expects it to be added some time later in response to the command issued after that, however if anything goes wrong (for example when domoticz shuts down before the response is received & processed), that response won't come, but the device will still be removed.
Not entirely true. The reason why I added this button was exactly this reason, it showed 0x0000. I experienced it myself again this morning after I needed to hard power off/on my system. In my case I did not remove any nodes, so all nodes are available, only there where a few without config. Waking up the nodes, and pressing this button solves it. But maybe it works different in different enviroments Anyways, this button is the same as performing this action from the control panel.
Version: 2020.2 (build 12824) Build Hash: 83d89fd31-modified Compile Date: 2021-01-05 17:20:33 dzVents Version: 3.1.1 Python Version: 3.7.3 (default, Jul 25 2020, 13:03:44) [GCC 8.3.0] Raspberry Pi 3B+ with zwave.me Razberry GPIO shield.
In some situations zwave node information must be (re-)queried. This can be the result of a request of the end user via for example the 'Refresh Node Info' button or the 'Heal node' button or because zwave was just initialising upon startup of Domoticz. Currently when one of these situations occurs, first all known information about the node is removed from Domoticz' internal memory and then the controller command is issued to retrieve the new node information. If all is fine, the new node information is received and the internal structures in Domoticz' memory are rebuilt. If however something is (temporarily) wrong, and no (timely) response is received from the node, the internal structures for that node will remain empty, and this empty node information eventually even gets persisted. This results in nodes showing 0x0000 for their ID and Type and a red type indication in the Zwave nodes list when Domoticz is restarted: The device is now no longer accessible for any future attempts to resolve the situation. The only way I know to resolve this is to re-include the device. But for some nodes this can be very hard due to the distance to the controller or the procedure that needs to be followed to start the inclusion on the node.
You don't even need to start any of the above mentioned processes to lose the node information: simply restarting Domoticz quickly after it was started is sufficient to loose some nodes too. The openzwave initialisation process has exactly the same problem: it first removes the device information read from the cached file, then it queries for new information. And the incomplete information is written to the cache file when Domoticz is closed before all nodes are queried.
This situation can be prevented by keeping the node's information in memory until a valid response is received to the command issued. In other words: first successfully receive the response, then replace in-memory node information structures. If needed, a flag can be added that indicates that the node information is not (yet) correct/verified and a command is underway to refresh it, but the nodes information should never be removed from memory without valid replacement information being available.