Zwavejs2mqtt: [question] Lost connection with battery powered devices after docker restart

Created on 12 Feb 2021  路  18Comments  路  Source: zwave-js/zwavejs2mqtt

I am running zwavejs2mqtt on docker (running on Ubuntu) everytime the docker restarts I lose the connection to all battery powered sensors and I need to re-join them to the network - is there a way to avoid this?

question

Most helpful comment

On the latest release, everything is scanned immediately from the cache, So currently my issue is solved!
And I don't have to wait anymore for the scan to complete.

All 18 comments

Hi, have you given them time to reappear in the network? Also depending on the battery devices. If they are "sleeping" device they can be interviewed only when they are awake and the interview might not end in one wake up period. The frequency of waking up might be configurable on the device so you can make them wake up more often or give them more time to finish the interview.
Also you can share some longs to show if there are errors in communication or simply the interview process is taking too long.

I was seeing this behavior as well but after waiting for a bit (10-20 minutes), the devices appeared normally. I am running zwavejs2mqtt 1.1.1 and zwavejs 6.2

I am using mostly Fibaro motion sensors and a few Sensitive strips door sensors, it doesn't take 10-20 minutes it takes several hours and some just stay undetected, I looked at the configuration options but didn't find something that seems to me relevant to the wake up interval.
Are you familiar with these modules? Can you point me in the right direction for optimal configuration options for these modules?

Same behavior - just got all of my devices to show up after a week and decided to try a reboot of the docker image, but now all of the battery powered devices that wake once a day are missing (Aeotec Dry Contact, Ecolink PIR Motion Sensors, Aeotec Minimote). Should the default behavior be to cache the device info after discovered?

Edit: Most devices came back after 30 minutes

Usually you have to wait even some hours before them come back

Please be aware that "waking up" isn't always the same as triggering a device.
A motion sensor, for example, will not wake up when it detects motion. You'll have to check the manual, though ususally a "re-associate" action (i.e. press button 3 times) will awaken the device.

@zeddski - this is not very practical I have about 20 motion sensors in different locations in my house - I cannot run around resetting them every time a docker restarts (which happens on power outages or code updates).
The sensative strips modules are great for window\door state detection but they have no buttons so you have to pass a magnet on them to wake up - I can't even start to describe how many hours I spent rubbing these sensors with magnets trying to guess when they are expected to work :-(
I used to run the integrated home-assistant z-wave module and the states of all the modules were kept in the entities file so whenever the network started it took forever to start it but at least I didn't have to waken up anything- the data was still there.
When I restart zwavejs2mqtt - the list of nodes shows me all the nodes but without the data it should have already known about them (which is everything).
I noticed the data is saved into json files - I wonder why the zwavejs2mqtt doesn't try to read the relevant modules from the files.

I moved from Home Assistant's integrated Z-Wave to this and none of my battery operated devices have shown up even after 2 weeks. Just last night I excluded and secure included one of the door sensors and still nothing came in. I'm very disappointed this is the path Home Assistant has chosen to go because this is a move backwards because like @unehab said Home Assistant would not lose the manufacturer information on a reboot. A lot of that data will never change, and the nodes close to it won't change often enough to warrant a re-interview on reboot. If you need that, flag that node as requiring an interview but have the data cached so it's not useless until some point way down the line where the Docker finally has all the information it needs.

I have the same issue..
After docker restart, some of my battery powered still not available. Shouldn't this being loaded from the cache??

After docker restart, some of my battery powered still not available. Shouldn't this being loaded from the cache??

With version 6.4.0 of zwavejs this should be fixed. Could you try touse dev tag if you are using docker?

@robertsLando I'm running Docker on unRAID and I switched to the dev tag. After 11 minutes the web UI is still spinning and saying Loading. Looking at the logs, it's interviewing everything and hit it's max failed interviews on the battery operated nodes. It's doing partial interviews on the nodes it can reach. It will log a lot of lines, then stay idle for a while, then log several more. I'm not sure what it's doing in the idle time when it's not logging, but I've let it run for 14 minutes and it's not yet gone past the Loading screen in the UI. Home Assistant did see the battery operated Z-Wave devices much quicker in the dev version than the latest. I also noticed the dev version started quicker than the latest version.

@robertsLando I haven't tagged the dev branch but I have version 6.4.0 running now at my setup for the last 4 hours and still most of my battery powered sensors are undetected.
I reduced their wakeup interval to 15m (instead of 2h) but it doesn't seem to be very helpful 馃槥

@AlCalzone ?

Good thing I have this reply saved:
Please make a zwave-js log, loglevel debug or silly and attach it here as a file. Make sure to mention which Node IDs are affected.

If nothing else is going wrong, battery-powered nodes should be immediately available for use after a reboot if they have been interviewed prior. They will still be queried for updated values, but that happens in the background.

running 6.4.0 and still experiencing the behavior in question

Please make a zwave-js log, loglevel debug or silly and attach it here as a file.

On the latest release, everything is scanned immediately from the cache, So currently my issue is solved!
And I don't have to wait anymore for the scan to complete.

Closing for now so

Was this page helpful?
0 / 5 - 0 ratings