Possible incorrect node status

[VaticanUK]

This may be something I'm misunderstanding, or it could be a bug. I'm not sure.

I'm running: Zwave2Mqtt version: 3.2.2 Openzwave Version: 1.6.1133

in the official docker image.

I have 5 devices that are battery powered and around 15 that are mains powered. If the controller loses power (happens quite a bit atm because I'm playing around with z2m and home assistant to try and get things working how I want :D), or if a battery device loses power (simulate by removing battery), all battery devices (or the one that lost power) show up as dead and nothing I do in the dashboard seems to revive them.

If I grep the OZW logs for Node012, I see the following:

which seems to suggest that the nodes is marked as sleeping not dead? (see line before last - times are different in dashboard and log because of GMT vs BST timezone, or at least I think that's why!)

But... I currently have 4 devices in that state (the 5th for some reason says Sleep atm rather than Dead and I have no idea why that's different!) and the output of grepping the logs for dead shows:

but the dashboard says 4 dead and 3 asleep:

So I can't quite work out what's going on, and how I can revive my battery powered devices after changing the battery, or if the controller loses power?

Thanks in advance of any help or advice!

[robertsLando]

Did you try to simply send a testNode against this nodes? Or refreshNodeInfo api?

[VaticanUK]

Yep, I saw stuff going through in the OZW log but nothing changed wrt it's status on the dashboard 🙄

[VaticanUK]

In fact, the screenshot of the log above was after a refreshnodeinfo if I remember correctly

[robertsLando]

Does this happen even when using ozwdaemon?

[VaticanUK]

you'll have to help me out with what you mean there sorry? I'm just using the docker image at the moment

[robertsLando]

@VaticanUK there is another plugin out there check this discussion: https://github.com/OpenZWave/Zwave2Mqtt/issues/321

I would like to know if it's something related to z2m or something related to OZW itself. If the problem persists even with ozwdaemon it means it's something wrong with OZW

[VaticanUK]

Ah cool thanks.

I'll try it later and let you know how it behaves.

[VaticanUK]

Hmm. I can't get that docker image to work. The VNC connection keeps dropping as soon as I try to do anything. Plus, I'm not sure that docker image is really the way forwards, a desktop app exposed through VNC is just painful! I'm not sure it's really the most appropriate tech choice.

[robertsLando]

I can't get that docker image to work

Do you mean the openzwavedaemon or z2m?

[VaticanUK]

openzwavedaemon - I guess it is in beta, but it seems incredibly unstable

[robertsLando]

Sorry try this: https://github.com/OpenZWave/qt-openzwave

With this: https://github.com/cgarwood/homeassistant-zwave_mqtt

[VaticanUK]

that is the one I tried, I can't get it to work at all, just crashes. (https://github.com/OpenZWave/qt-openzwave)

[robertsLando]

@Fishwaldo

[Fishwaldo]

Looking at the screenshot of the logs - This is a Z2M/node-shared issue. If OZW detected a "dead" node it would be logged with messages such as:

ERROR: Dropping command because node is presumed dead

ERROR: node presumed dead

and you would get Notifications with Code_Dead events

[VaticanUK]

So, I've been thinking about this and experimenting a bit more, and there is definitely something odd going on.

After rebooting my z-wave controller about a week ago (simulating a power cut), this is the current status of all my nodes:

(Battery powered devices marked as "B").

Some devices show as "Last Active" 5 days ago and have missing metadata, yet are tagged as "Alive". Others in the same state (the battery powered ones) are tagged as "Dead".

But, 2 battery powered devices show up fine, so it's not that clear cut.

I've had a play with Z-Way and in that I could "force interview" a device which caused it to fetch all the metadata that is collected when pairing (in fact, it seemed to do that itself for devices missing information, but force interview let me tell it to do it immediately).

The devices with no info do, for the most part, seem to work. Device with ID 3 in my screenshot (for example) correctly reports it's state, but I can only control 1 of the two switches (my guess is that this is because of the missing metadata so Z2M isn't doing anything when I set the value on the second channel?)

So I wonder if this is mainly a UI/state issue within Z2M?

I haven't looked at the code (maybe I should), but from playing it seems that Z2M doesn't cache all the node information to disk, so if the controller reboots it has to "get" all the information again. Could it instead cache everything, so after reboot it comes back up in the exact same state, but then in the background, re-request that information to make sure everything is correct?

Also, is there an equivalent in OZW to the "Force Interview" command in Z-way? In the documentation I couldn't find anything that was obviously the same, but I could find a "RequestMetadata" method - is that the same thing? Could that be added as a node command in the UI to force requesting all metadata for the node? And maybe that's what needs to be called for every node after a restart?

[robertsLando]

AFAIK RequestMetadata should return info about a device like inclusion/esclusion help. But @Fishwaldo could tell you more about this for sure

Z2M doesn't cache all the node information to disk

It shouldn't as OZW already cache them in a file

Some devices show as "Last Active" 5 days ago and have missing metadata

Sincerly I dunno where the problem could be, maybe there could be a command or something else to send to battery devices to check and updated their status? IMO OZW should automatically handle this, but again let's see what @Fishwaldo can tell us about this. Even by double checking the code I cannot find what could be wrong

[github-actions[bot]]

This issue is stale because it has been open 90 days with no activity. Remove the stale label or comment or this will be closed in 5 days. To ignore this issue entirely you can add the no-stale label