Zwave2mqtt: [bug] V3.4.1 not working

[dick902]

Version

Build/Run method

• [ x] Docker
• [ ] PKG
• [ ] Manually built (git clone - npm install - npm run build )

Zwave2Mqtt version: 3.4.1
Openzwave Version: 1.6

Describe the bug
Update from V3.4.0 to V3.4.1, all devices stay DEAD afte restart.
Fallback to V3.4.0 now, and everything return to normal

[robertsLando]

@dick902 Were you using refreshNodeInfo at startup?

[dick902]

@dick902 Where you using refreshNodeInfo at startup?

No. below as my setting:

{"mqtt":{"disabled":false,"name":"zwave","host":"mqtt://xxx.xxx.xxx.xxx","_ca":"","ca":"","_cert":"","cert":"","_key":"","key":"","port":1883,"reconnectPeriod":500,"prefix":"homeassistant","qos":0,"auth":true,"retain":true,"username":"username","password":"password"},"gateway":{"values":[],"ignoreLoc":true,"type":0,"payloadType":1,"nodeNames":true,"hassDiscovery":true,"retainedDiscovery":true,"ignoreStatus":true},"zwave":{"port":"/dev/ttyACM0","networkKey":"0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08, 0x09, 0x0A, 0x0B, 0x0C, 0x0D, 0x0E, 0x0F, 0x10","logging":false,"saveConfig":true,"assumeAwake":true,"pollInterval":1500,"commandsTimeout":90}}

[robertsLando]

No changes have been made on my side in the code, what is different is the ozw library version. Could you try to ask in that repo if something has been broken?

---

Daniel

On 16 Jul 2020, at 11:14, dick902 [e-mail] wrote:


@dick902 Where you using refreshNodeInfo at startup?

No. below as my setting:

{"mqtt":{"disabled":false,"name":"zwave","host":"mqtt://xxx.xxx.xxx.xxx","_ca":"","ca":"","_cert":"","cert":"","_key":"","key":"","port":1883,"reconnectPeriod":500,"prefix":"homeassistant","qos":0,"auth":true,"retain":true,"username":"username","password":"password"},"gateway":{"values":[],"ignoreLoc":true,"type":0,"payloadType":1,"nodeNames":true,"hassDiscovery":true,"retainedDiscovery":true,"ignoreStatus":true},"zwave":{"port":"/dev/ttyACM0","networkKey":"0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08, 0x09, 0x0A, 0x0B, 0x0C, 0x0D, 0x0E, 0x0F, 0x10","logging":false,"saveConfig":true,"assumeAwake":true,"pollInterval":1500,"commandsTimeout":90}}

—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub, or unsubscribe.

[Altycoder]

This is the same for me too, for v3.4.1 all my battery powered sensors are now dead, only my plugged in sensors and sirens are still alive.

I've tried to heal the network but that didn't work. I've also tried manually triggering and waking the sensors and that didn't work either.

(And yes I've turned it all off and on again)

Last 1000 lines of my log attached to see if that helps?

log.txt

[Altycoder]

Going to v3.4.0 for me and now ALL my sensors and sirens are dead (I've not updated for 2-3 weeks so not sure what my previous version was).

Log from 3.4.0 attached for diagnosis.

log3.4.0.txt

Edit: my plugged in sensors have now woken up in 3.4.0 but battery powered sensors still dead.

[Altycoder]

v3.3.0 is no better but I'm sticking at this version for now and manually removing and re-adding my battery powered sensors grrrr!

[robertsLando]

@Altycoder I saw another user was reporting me the same problem but said that after some time (hours) they come back

[robertsLando]

It's for sure not something related to z2m itself but more likely a bug in newer versions of OZW as I have no control of devices status

[Altycoder]

But OZW is the same version between all 3 versions of zwave2mqtt, it's reported as v1.6.0 so hasn't changed? This can't therefore be an upstream bug (unless there's also a bug in the version of OZW that's displayed of course)?

Also regarding the battery sensors and time, this will be because battery sensors only wake to report their status 1-2 times a day normally to save on battery life. I've manually woken all mine up in turn and tried to heal whilst they are awake but that didn't make a difference.

So I'm going to manually remove and re-add all my battery devices later today as that seems to be the only fix for me.

[dick902]

@robertsLando On the pervious versions of Z2M, the OZW version always with the build number follow like (1.6.0.xxxx).
That coluld help to identify if the problem may related to OZW.
Why this is removed now?

[robertsLando]

@Altycoder 1.6 is the minor, what changes is the build version.

On the pervious versions of Z2M, the OZW version always with the build number follow like (1.6.0.xxxx).

Didn't know about this, I need to investigate.

@chrisns Could it be caused by the swith to the prebuild docker images? (the missing build)? I know build is missing when you don't have git installed (so it cannot fetch the build when installing ozw)

[chrisns]

Yeah. Could probably find a way to replicate that behaviour

[robertsLando]

@chrisns You could simply add git to apk

[Altycoder]

@Altycoder 1.6 is the minor, what changes is the build version.

Yes but the minor version hasn't changed, it's always been zero as in 1.6.0

[chrisns]

@robertsLando not sure that'll work since its a submodule, happy to try though

[robertsLando]

@chrisns AFAIK it just need to be installed when you run make install command, in this way during install it can fetch the build using git

Yes but the minor version hasn't changed, it's always been zero as in 1.6.0

Sure, the build number (that is the git commit hash) is what changes ( not really the best versioning system )

[wwebers]

What's the workaround for now? Right now, my whole Zwave network is plain dead (with the exception of just one outlet). As far as I understand the log all devices respond as expected. Still all of them are marked dead.

[hvbommel]

@wwebers If you have a backup of your ozw_xxxxxxx.xml cache file try to restore it.

I noticed the same problem today (in my case OpenZwave on Domoticz). Also I noticed my manufacturers_specific.xml was updated from Revison 108 to 109. I restored my ozwcache_0xef8d06fd.xml file (I happened to have one this time). My devices worked again after restore.
Theory (at this time): The cache becomes incompatible or broken after update.

[jtscott]

I managed to get my wired nodes and locks back after a few refresh node infos, freezes, restarts of the container cycles. However my battery powered sensors are dead/removed.

[robertsLando]

Hi guys, I'm very sorry for the bug but as I said and as I can assume based on your comments seems something that has been borokem with new releases of OZW. Hopefully @Fishwaldo could tell us more about this

[robertsLando]

About workarounds, what usually fix this is likely send some brodcast refreshNodeInfo commands, otherwise the last choice is to exclude all nodes and add them back to the controller, also once all are excluded an hard reset of the controller. Unfortunately I don't know why this happened but is the same that hs happen when I switched from ozw 1.4 to 1.6

[Altycoder]

About workarounds, what usually fix this is likely send some brodcast refreshNodeInfo commands, otherwise the last choice is to exclude all nodes and add them back to the controller, also once all are excluded an hard reset of the controller. Unfortunately I don't know why this happened but is the same that hs happen when I switched from ozw 1.4 to 1.6

I don't want to sound ungrateful but should this not have been caught in beta testing before release then, both upstream in the OZW repo but also in this repo?

I haven't looked yet but does the upstream OZW repo mention any breaking changes in their release notes?

[wwebers]

Can someone explain this debug output for me? (FYI: Node 3 is marked dead in Z2M GUI):

zwave2mqtt       | 2020-07-18 09:12:34.298 Info, Node003, Received Basic set from node 3: level=0.  Sending event notification.
zwave2mqtt       | 2020-07-18 09:12:34.299 Detail, Node003, Notification: NodeEvent
zwave2mqtt       |   z2m:Zwave node event 3 0 +5s
zwave2mqtt       | 2020-07-18 09:12:34.314 Detail, Node003,   Received: 0x01, 0x0b, 0x00, 0x04, 0x00, 0x03, 0x03, 0x20, 0x01,0x00, 0xb5, 0x00, 0x64
zwave2mqtt       | 2020-07-18 09:12:34.314 Detail,
zwave2mqtt       | 2020-07-18 09:12:34.315 Info, Node003, Received Basic set from node 3: level=0.  Sending event notification.
zwave2mqtt       | 2020-07-18 09:12:34.315 Detail, Node003, Notification: NodeEvent
zwave2mqtt       |   z2m:Zwave node event 3 0 +17ms
zwave2mqtt       | 2020-07-18 09:13:30.061 Detail, Node003,   Received: 0x01, 0x0b, 0x00, 0x04, 0x08, 0x03, 0x03, 0x20, 0x01,0xff, 0xb9, 0x00, 0x9f
zwave2mqtt       | 2020-07-18 09:13:30.061 Detail,
zwave2mqtt       | 2020-07-18 09:13:30.062 Info, Node003, Received Basic set from node 3: level=255.  Sending event notification.
zwave2mqtt       | 2020-07-18 09:13:30.063 Detail, Node003, Notification: NodeEvent
zwave2mqtt       |   z2m:Zwave node event 3 255 +56s
zwave2mqtt       | 2020-07-18 09:13:30.078 Detail, Node003,   Received: 0x01, 0x0b, 0x00, 0x04, 0x00, 0x03, 0x03, 0x20, 0x01,0xff, 0xb1, 0x00, 0x9f
zwave2mqtt       | 2020-07-18 09:13:30.078 Detail,
zwave2mqtt       | 2020-07-18 09:13:30.079 Info, Node003, Received Basic set from node 3: level=255.  Sending event notification.
zwave2mqtt       | 2020-07-18 09:13:30.079 Detail, Node003, Notification: NodeEvent
zwave2mqtt       |   z2m:Zwave node event 3 255 +17ms
zwave2mqtt       | 2020-07-18 09:13:34.112 Detail, Node003,   Received: 0x01, 0x0b, 0x00, 0x04, 0x08, 0x03, 0x03, 0x20, 0x01,0x00, 0xb9, 0x00, 0x60
zwave2mqtt       | 2020-07-18 09:13:34.112 Detail,
zwave2mqtt       | 2020-07-18 09:13:34.112 Info, Node003, Received Basic set from node 3: level=0.  Sending event notification.
zwave2mqtt       | 2020-07-18 09:13:34.112 Detail, Node003, Notification: NodeEvent
zwave2mqtt       |   z2m:Zwave node event 3 0 +4s
zwave2mqtt       | 2020-07-18 09:13:34.128 Detail, Node003,   Received: 0x01, 0x0b, 0x00, 0x04, 0x00, 0x03, 0x03, 0x20, 0x01,0x00, 0xb6, 0x00, 0x67
zwave2mqtt       | 2020-07-18 09:13:34.128 Detail,
zwave2mqtt       | 2020-07-18 09:13:34.129 Info, Node003, Received Basic set from node 3: level=0.  Sending event notification.
zwave2mqtt       | 2020-07-18 09:13:34.129 Detail, Node003, Notification: NodeEvent
zwave2mqtt       |   z2m:Zwave node event 3 0 +17ms

Looks for as the node isn't dead at all. More like Z2M doesn't realize it's alive.

BTW: Node 3 is a simple door magnet

[wwebers]

Another thing I observed is that your docker image is based on that from @chrisns , which in turn uses dependabot. That one seem to always use the master branch of openzwave. Is that intention? I would have expected Chris would use the latest stable branch.

Maybe this explains why things break like this bug and become fragile. Maybe it's time for me to create a fork which is based on the stable releases and not the latest commits....

[robertsLando]

When I spoke about this with OZW author @Fishwaldo he told me that master is always stable. The first version was using stable releases downloaded from OZW site but them are not updated regularly. Hope he can tell more to us about this

[Altycoder]

Another thing I observed is that your docker image is based on that from @chrisns , which in turn uses dependabot. That one seem to always use the master branch of openzwave. Is that intention? I would have expected Chris would use the latest stable branch.

Maybe this explains why things break like this bug and become fragile. Maybe it's time for me to create a fork which is based on the stable releases and not the latest commits....

That would be a good idea if the owner of this repo is to stick with latest branches. With zwave sensors mostly being used for alarms etc, a conservative and reliable route forward would be good as an alternative

[Altycoder]

When I spoke about this with OZW author @Fishwaldo he told me that master is always stable. The first version was using stable releases downloaded from OZW site but them are not updated regularly. Hope he can tell more to us about this

you've tagged that person a few times now do you think they will respond? :-)

[robertsLando]

Unfortunately if you check OZW repo you will not see any tags or "stable" branches. It uses git commits for versioning builds of specifics minor/major versions

[Fishwaldo]

Sigh. @robertsLando - As i already pointed out in https://github.com/OpenZWave/Zwave2Mqtt/issues/559#issuecomment-641463149 OZW is not reporting any dead nodes. The problem you are facing is with Node-Shared or Z2M and its not OZW.

OZW will report those log messages and send a Notification of "Type_Notification" with a event of Node_Dead. I do not see that in any of the logs posted. That is the only way OZW signals a dead node. So OZW is operating correctly.

Please investigate your bug reports stop tagging me on everything. I simply do not have the bandwidth to support you unless you do at least some basic troubleshooting.

Also - As i have mentioned countless times - The tested builds are only the tar/zip files on the OZW site. if you continue to use HEAD of master - You are playing with fire. There Could be potential breakages etc in HEAD at any time.

[wwebers]

Thanks @Fishwaldo. That supports my suspicions.

Looks like the only final bugfix for this is to remake the base Docker image and only use the latest stable tarball coming from the OZW homepage (not the master branch here from Github). Any chance that @chrisns is making one?

As proposal he could make two versions: one using the unstable master branch of OZW and one using the stable source from the OZW homepage.

[Fishwaldo]

Stable/unstable wont fix the dead node issue. It's not a problem with OZW but rather somewhere else.

[robertsLando]

Nothing has changed both on z2m or openzwave shared in nodes management, they should both work as before this is why I said it's something related to a change in ozw, I firstly mark nodes as alive when I receive a node ready event or a notification, so maybe with latest ozw versions notifications has changed or else? If things were working before I don't know what could have break them. About versioning I remember I had a conversation some time ago with you about tagging stables commits at least, but then someone (you or your collaborator) said it was ok to use master as it is always stable. Anyway I will try to fix this with @chrisns

[chrisns]

Hey. Been a manic few weeks, will fix the docker git thing ASAP. Pull requests welcome if someone else gets to it before me

[Fishwaldo]

Nothing has changed both on z2m or openzwave shared in nodes management, they should both work as before this is why I said it's something related to a change in ozw, I firstly mark nodes as alive when I receive a node ready event or a notification, so maybe with latest ozw versions notifications has changed or else? If things were working before I don't know what could have break them.

OZW is not tagging anything as dead. The problem is NOT with OZW. If something was dead it would be logged. Additionally:

2020-07-16 11:48:26.819 Warning, CheckCompletedNodeQueries all=0, deadFound=0 sleepingOnly=0

"deadFound=0" means no dead nodes. How much more clear can I make the message that this is NOT a OZW issue.

About versioning I remember I had a conversation some time ago with you about tagging stables commits at least, but then someone (you or your collaborator) said it was ok to use master as it is always stable.

I have never said this. Stop putting words in my mouth. Forever and a day I have told you that the only supported, tested versions are those released on the website. It's been that way for years

[Villhellm]

Just adding my voice to the issue at hand, I also have 2 battery powered door sensors that are marked as dead since updating.
I downgraded to 3.3.0 with the same results, then to 3.2.2 with the same results.
Running 3.2.2 and sending a series of refresh node info commands while opening/closing the doors to activate the sensor seemed to fix it (this was the first time I tried this, so I'm not sure if it would have worked with 3.3.0 or 3.4.1).

I did notice that in 3.3.0 and 3.4.1 the OZW version says 1.6.0 but in 3.2.2 it says 1.6.1133

Let me know if I can provide any other information

[mbhoek]

Chiming in to share that some of my zwave dimmers were not working anymore after upgrading to 3.4.1; although z2m picked up the mqtt message, the actual light was never switched on/off. Example log entry which was ignored:

zwave2mqtt_1  | 2020-07-18T18:59:30.968Z z2m:Mqtt Message received on zwave/f2_office/light/38/1/0/set

After downgrading to 3.4.0 and recreating the containers, the dimmers seem to be working again. However, as reported by other people, all my battery operated sensors are marked dead.

[robertsLando]

@Altycoder As you can see from your logs in the first one there are 3 nodes reporting 'ready' event and those are the one that you see as alive. The other ones are not reporting me the ready event so I don't mark them as alive.

My question is, like I said before, I haven't changed anything on both z2m and ozw-shared libs to break this. I will try to downgrade to some older ozw versions to see if the problem gets fixed

[Altycoder]

@Altycoder As you can see from your logs in the first one there are 3 nodes reporting 'ready' event and those are the one that you see as alive. The other ones are not reporting me the ready event so I don't mark them as alive.

My question is, like I said before, I haven't changed anything on both z2m and ozw-shared libs to break this. I will try to downgrade to some older ozw versions to see if the problem gets fixed

Thanks, the 3 devices you pointed out are mains powered devices, this issue seems to be related to just battery powered devices.

[robertsLando]

this issue seems to be related to just battery powered devices

Yes but there are some users having the same problems with also no-battery devices. Like I said before, if I don't receive that event I cannot identify if a device is alive or not, and it is coming from the underling lib, so again the only thing I can try to do is do downgrade to an older ozw version to see if this fixes the problem. If you are not using docker you could this your own by using a version from http://old.openzwave.com/downloads/

[Altycoder]

this issue seems to be related to just battery powered devices

Yes but there are some users having the same problems with also no-battery devices. Like I said before, if I don't receive that event I cannot identify if a device is alive or not, and it is coming from the underling lib, so again the only thing I can try to do is do downgrade to an older ozw version to see if this fixes the problem. If you are not using docker you could this your own by using a version from http://old.openzwave.com/downloads/

I've gone back to the latest version of this container now and removed and re-added my 4x battery devices as I can't afford for my home alarm to be offline. I have changed my docker compose though from pulling latest to 3.4.1 so I have more control over the version I'm pulling for the time being at least.

[robertsLando]

I've gone back to the latest version of this container now and removed and re-added my 4x battery devices

Does this operation made your battery devices to come back alive?

If so, I think that OZW has some problems when the revision of a device config file in ozw devices db is different from the one found on the cache and maybe this is what is causing those probelms. The same was happening to users when switching from ozw 1.4 to 1.6 and the only way was to remove and add all devices back again

[Altycoder]

I've gone back to the latest version of this container now and removed and re-added my 4x battery devices

Does this operation made your battery devices to come back alive?

If so, I think that OZW has some problems when the revision of a device config file in ozw devices db is different from the one found on the cache and maybe this is what is causing those probelms. The same was happening to users when switching from ozw 1.4 to 1.6 and the only way was to remove and add all devices back again

Yes all working again now, just lucky that I only had 4 battery powered devices. I'm going to be a bit more careful in the future when I recreate my container.

Have you thought about "dev" and "stable" labelled containers? Make the next version "dev" and only move it to "stable" once you're sure there are no issues?

[robertsLando]

Make the next version "dev" and only move it to "stable" once you're sure there are no issues?

With OZW is not that wasy, unfortunally it's hard to setup a test suite that checkes everything works, me and @chrisns have spoke about this with ozw author to use github actions with a custom runner that has some zwave devices and a controller that runs some checks to be sure nothing breaks but we didn't find much interest in this. The only thing I could do is to stick the ozw version to a specific one and move forward only when I'm completely sure (some manual testing or users testing a dev version)

[Altycoder]

Make the next version "dev" and only move it to "stable" once you're sure there are no issues?

With OZW is not that wasy, unfortunally it's hard to setup a test suite that checkes everything works, me and @chrisns have spoke about this with ozw author to use github actions with a custom runner that has some zwave devices and a controller that runs some checks to be sure nothing breaks but we didn't find much interest in this. The only thing I could do is to stick the ozw version to a specific one and move forward only when I'm completely sure (some manual testing or users testing a dev version)

The other way is to make your next version "dev" or "latest". Wait a few days or 1-2 weeks to see what issues crop up and then move it to "stable" once you are sure there are no major issues.

You would have to make this change clear in your readme though. This way stable is is a safe choice even if it is 1-2 versions behind latest or dev.

[Altycoder]

Make the next version "dev" and only move it to "stable" once you're sure there are no issues?

With OZW is not that wasy, unfortunally it's hard to setup a test suite that checkes everything works, me and @chrisns have spoke about this with ozw author to use github actions with a custom runner that has some zwave devices and a controller that runs some checks to be sure nothing breaks but we didn't find much interest in this. The only thing I could do is to stick the ozw version to a specific one and move forward only when I'm completely sure (some manual testing or users testing a dev version)

The other way is to make your next version "dev" or "latest". Wait a few days or 1-2 weeks to see what issues crop up and then move it to "stable" once you are sure there are no major issues.

You would have to make this change clear in your readme though. This way stable is is a safe choice even if it is 1-2 versions behind latest or dev.

PS and make a stable version now out of the last version for which there were no major issues.

[robertsLando]

@Altycoder I don't see any pro to have also a stable version tag, I think that a dev and latest is enought, the dev will always have latest versions of both ozw and z2m, the latest will only have latest changes of z2m

[Altycoder]

@Altycoder I don't see any pro to have also a stable version tag, I think that a dev and latest is enought, the dev will always have latest versions of both ozw and z2m, the latest will only have latest changes of z2m

We'll have to agree to disagree on that point then :-)

[robertsLando]

A stable could prevet bugs on latest z2m versions you mean, I think the best would be to have a group of tester users that once a new release comes up can make some testing their own and tell if something has break. That could be another solution, unfortunally I have just 2 zwave devices right now at work and no one at home to make good test my own, also the time is not that much. As an open source project it would be nice to have some users make their 'contribution' with testing at least

[Altycoder]

A stable could prevet bugs on latest z2m versions you mean, I think the best would be to have a group of tester users that once a new release comes up can make some testing their own and tell if something has break. That could be another solution, unfortunally I have just 2 zwave devices right now at work and no one at home to make good test my own, also the time is not that much. As an open source project it would be nice to have some users make their 'contribution' with testing at least

Yes some users who have the time to contribute, some users who don't use their devices to security systems for example ;-)

[robertsLando]

IMO updating z2m version when everything is working is not recommended, just if the new version adds some feature that you need, the devices database is automatically updated even on older versions. In your case I suggest to stick to a specific working version

---

Daniel

On 20 Jul 2020, at 12:07, Altycoder [e-mail] wrote:


A stable could prevet bugs on latest z2m versions you mean, I think the best would be to have a group of tester users that once a new release comes up can make some testing their own and tell if something has break. That could be another solution, unfortunally I have just 2 zwave devices right now at work and no one at home to make good test my own, also the time is not that much. As an open source project it would be nice to have some users make their 'contribution' with testing at least

Yes some users who have the time to contribute, some users who don't use their devices to security systems for example ;-)

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.

[wwebers]

Like I said before, if I don't receive that event I cannot identify if a device is alive or not, and it is coming from the underling lib

@robertsLando Do I understand you right that you assume a node as dead as long as you do not receive an explicit message from the OZW library that it's alive? Wouldn't it be better and more correct to give such node a different state, like undetermined? Some functions in Z2M seems not refuse execution because of the (possibly wrong) dead state. Maybe that would solve the problem to get those nodes back to life?

If you are not using docker you could this your own by using a version from http://old.openzwave.com/downloads/

@robertsLando That would be a good starting point for a stable docker image, wouldn't it? As @Fishwaldo said the only tested version of OZW is that one provided on their web page.

I've gone back to the latest version of this container now and removed and re-added my 4x battery devices as I can't afford for my home alarm to be offline. I have changed my docker compose though from pulling latest to 3.4.1 so I have more control over the version I'm pulling for the time being at least.

@Altycoder Interesting, I did the same (am also using docker-compose). I had to setup all my 15 devices again and am in the pretty same situation in driving a security system with those devices.

[Altycoder]

@Altycoder Interesting, I did the same (am also using docker-compose). I had to setup all my 15 devices again and am in the pretty same situation in driving a security system with those devices.

I've moved from pulling the latest tag now to pulling tag 3.4.1 and I've recreated my container based around that and deleted the latest image. This way I have more control over my container.

On the same server I also run a unifi controller and home assistant to name a couple and I've always pulled the stable images for those rather than latest as it's much safer - no need to be at the bleeding edge (even though my server runs on Arch albeit with the LTS kernel haha)

[robertsLando]

Do I understand you right that you assume a node as dead as long as you do not receive an explicit message from the OZW library that it's alive? Wouldn't it be better and more correct to give such node a different state, like undetermined? Some functions in Z2M seems not refuse execution because of the (possibly wrong) dead state. Maybe that would solve the problem to get those nodes back to life?

Usually the cycle of a node when application starts is:

1. Node Added
2. Node Available (node info received)
3. All node values are added value xxx-x-x added
4. Node ready

Then I can receive some notifications (awake, sleep, dead, alive) and I update node status based on them, I could add Unkown state but this will not change anything as the only thing that blocks functions is the inited flag of a node, I must receive node ready event to mark it as ready to receive any kind of commands (if not ready it means I haven't received all its values yet)

[robertsLando]

All those notifications/events are coming from openzwave-shared that is openzwave nodejs wrapper. I have no control of them and I'm maintaining also that repo too but there hasn't been any change in that repo (or in z2m) that could prevent some events to stop working. That is why I keep saing that must be something related to the underlying OZW lib, the problem you are facing is the same that many users had when updating from 1.4 to 1.6 version

[drasch]

i too am experiencing this issue with both 3.4.1 and 3.4.0 in the docker container.

[wwebers]

I must receive node ready event to mark it as ready to receive any kind of commands (if not ready it means I haven't received all its values yet)

Well, I'll have to accept that. Even though it's discussable. There could be many event preventing a node sending all values back. But that doesn't necessarily mean the node is dead... However, I'm not into this Zwave protocol. For me it sounds like a design decision someone made (either OZW or Z2M).

[robertsLando]

Of I haven’t received all values from the node I could errors when I receive commands, the command could throw an error. I don’t know sincerly if this is by design or not but all my devices (battery too) have always worked in this way. If Fishwaldo can tell me more about this I will be glad to change this behavior

---

Daniel

On 20 Jul 2020, at 18:18, wwebers [e-mail] wrote:


I must receive node ready event to mark it as ready to receive any kind of commands (if not ready it means I haven't received all its values yet)

Well, I'll have to accept that. Even though it's discussable. There could be many event preventing a node sending all values back. But that doesn't necessarily mean the node is dead... However, I'm not into this Zwave protocol. For me it sounds like a design decision someone made (either OZW or Z2M).

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.

[chilicheech]

Folks, so this happened to me too. It happened to all my battery powered devices and to one mains powered device. After sending a few sendNodeInformation and refreshNodeInformation and restarts of z2m everything is now back. I guess to me this wasn't a big deal because I'm used to having to do this kind of thing when upgrading my zwave software. Not saying it's how it should be, just saying this is how it's worked for me.

This is open source software built by volunteers. No one owes anyone anything. Let's be constructive and help fix the issue together.

One thing I am curious about is the version number. The OZW version number used to be 1.6.xxxx and now it's 1.6.0. So something changed there. Whether it be in the software or in how we build the docker images.

As for nodes being Dead until they're ready, I don't have an issue with it since I don't restart z2m that often. It could make sense to use Unknown until the node reports it's ready, but not have the functionality changed, and only have it set to Dead when OZW reports it as dead.

Cheers,

[robertsLando]

Thanks @chilicheech !

About the missing OZW build version, That is missing since the move to openzwave docker pre-built binaries, the reason is that the build container didn't have git and it was needed by make install to get the build hash (it's the commit).

This has been already fixed (so starting from next release it will be back.

About the "bug" with dead devices, it could be something related to mismatches between cache and devices config files, but as I said before I would need some help to debug this

About the "unknown" state, I'm +1 for that but I don't think it will change anything in anyway

[wwebers]

Thanks @chilicheech !

About the missing OZW build version, That is missing since the move to openzwave docker pre-built binaries, the reason is that the build container didn't have git and it was needed by make install to get the build hash (it's the commit).

This has been already fixed (so starting from next release it will be back.

About the "bug" with dead devices, it could be something related to mismatches between cache and devices config files, but as I said before I would need some help to debug this

About the "unknown" state, I'm +1 for that but I don't think it will change anything in anyway

Even if it may not change anything in a functional way, it would in terms of usability.

And of course: In FOSS none owes something to anyone. I fully agree to that.

[drasch]

More information:

I downgraded to 3.3.0 docker image, and did nothing else. Nodes eventually recovered.

Side note, I tried to unpair/repair one of the nodes and tried "remove failed node". So it's now Hidden. However, it's now in status Alive (or Sleep) and the status is updating, and working. I was unable to get it to remove or re-add to the network. So it's mostly working, but still marked as Hidden. EDIT: looks like after a few restarts this cleared up.

Thanks to everyone.

[robertsLando]

@chilicheech Could that status also be added instead of unknown? In fact the node has been added if the status is unknown

[chilicheech]

@robertsLando i think you're right.. unknown doesn't really work here because we know something about the node. but i feel like added might also cause confusion. i think something in the lines of we know about this node and we're working on getting details about it... something like initializing, starting, starting up, or loading.

[chrisns]

by way of emoji reaction votes:
👍 pending
👎 unknown
😄 initializing
🎉 starting up
😕 starting
❤️ added
🚀 loading
👀 waiting

reply with other suggestions

[robertsLando]

Just to inform you, thanks to @chrisns starting from next release the ozw version will be always the last one downloaded from their site, the build version also should be fixed and you should see it on control panel.

About the node status It's just a line change in the code so once we agree on the status name I will change it asap

[robertsLando]

Closing this for now, will open again if someone is expecting this issue after new release too