well that is the whole point. They have completed the interview. All green now. If i restart the network i will need to wake them up again, otherwise they will stay forever in “protocol info” state. I don’t want to climb with a ladder everytime to each device to do the wakeup procedure. Maybe i have the old versions then. It says firmware 0.5
Sounds like there’s something wrong with your zwavejs2mqtt configuration. Are you sure you have a volume mapped to the store directory?
Please confirm this.
Confirmed. i have a volume mapped to a store directory and there are files there being modified as we speak. This issue only occurs with these devices not any of the other 33 in my network, of all kinds and manufacturers. I was hoping this was an OZW limitation, it remains in zwaveJS, maybe it is the device’s limitation
Mind posting your docker run command, or compose file? I’ve had the original ZCOMBO for years and have never encountered an issue like this. The interview state is held in the cache files. If the cache file is lost, then interviews are required again. It sounds exactly like your cache file is being lost.
All the other devices on the network wakeup within a day or two and will show interview complete.
What did you mean by this? It’s not normal for any battery device to have to re-interview.
If everything is configured correctly and you see this problem, then I would submit an issue, because it’s not normal for information about battery devices to just be forgotten.
ok, see the following screenshot, so you see what i am referring to, look at the interview column. After restarting the smoke detectors remain in that “protocol info” state forever. All the other battery powered devices, wakeup eventually and turn from red to green “complete”
Here is my compose file:
version: "3.7"
services:
zwavejs2mqtt:
container_name: zwavejs2mqtt
image: zwavejs/zwavejs2mqtt:latest
restart: always
tty: true
stop_signal: SIGINT
environment:
- TZ=America/Los_Angeles
networks:
- zwave
devices:
- '/dev/serial/by-id/usb-0658_0200-if00:/dev/zwave'
volumes:
- ./store:/usr/src/app/store
ports:
- "8091:8091" # port for web interface
- "3000:3000" # port for Z-Wave JS websocket server
networks:
zwave:
volumes:
zwave-config:
name: zwave-config
The compose file looks fine. You’re not using the zwave network nor the zwave-config volume, the store is mapped to the local ./store directory instead, but that doesn’t affect anything.
After restarting the smoke detectors remain in that “protocol info” state forever. All the other battery powered devices, wakeup eventually and turn from red to green “complete”
This is completely explained by a lost or corrupt cache file, but I’m not sure how that’s happening yet. When this happens, all nodes are reset back to the ProtocolInfo interview status. Mains-powered devices will be re-interviewed immediately during startup. The battery devices will re-interview the next time they wake up, which is exactly what you describe. Devices that never wake up on their own, like the original ZCOMBO, will be stuck there until you manually wake them up.
The only way for an existing device’s interview status to go from Complete to ProtocolInfo is either a) the cache file is lost/corrupt, or b) you’ve done a re-interview on the device. Unless you’ve been doing re-interviews, then it would have to be the cache file. The devices aren’t doing anything to get in this state.
If you have a driver log file that shows the last restart, feel free to post that and maybe it will show something. If not, I would enable the debug logs for the next restart, and post them when you can. There are instructions here on how to enable debug driver logs and download them. Be aware that saving the configuration after changing logging might restart z2m, so only do it when you’re prepared to.
thanks for the explanation. So, i could run an experiment to restart the container enabling debug driver logs. In such a case will you expect the ZCOMBO devices to go to “complete” without me waking them up? or will they stay in ProtocolInfo forever?
Are they stuck in ProtocolInfo b/c of a potential cache file corruption?
The old ZCOMBO devices (fw 0.5) won’t ever go to Complete w/o you physically waking them up. So yes, they will stay in ProtocolInfo forever. These devices just don’t ever perform a Z-Wave Wake Up, which is required to finish the interview, and is what your other battery devices are doing.
My theory is that you have some issue with the cache file. Corrupt cache files are pretty rare these days though. I can’t say for certain, but I was hoping the debug logs might give a clue. If the file was corrupt, the log would say that.
ok, so with these 0.5 FW devices, what would be the expected behavior then in case of a network restart? would they still be able to send an alert in ase of an event, even though they are in ProtocolInfo state?
What is the expected behavior that is not happening b/c a potential cache file corruption?
Also this is a new zwaveJS installation, why would the cache file be corrupted impacting only these devices?
Just trying to understand, thanks
In normal conditions there’s no change to the interview status. The cache file persists the information about the node. I have restarted my network hundreds of times without any issue. If any node is stuck in ProtocolInfo, HA will not see any events. The interview must be completed (node in the Ready state) so that all the information about the node is known. HA can’t setup the entities without this information.
Also this is a new zwaveJS installation, why would the cache file be corrupted impacting only these devices?
It’s not impacting only these devices. You’ve said multiple times that all of your battery devices have this problem:
The only difference between those “other” devices and the ZCOMBO is that the other battery devices wake up on their own. I’ll repeat, it’s not normal for any battery device to go to ProtocolInfo interview status after a restart. That’s the entire point of the cache file, to preserve the information discovered during the interview. If you had a startup log I’m guessing we’d see all the devices being interviewed again.
no, all other devices eventually work and move from ProtocolInfo to complete. The only ones that don’t do that are the ZCOMBO devices.
So the question is at the end of the day, is this expected behavior? if yes, the conclusion is that ZCOMBO devices will not work if for some reason the network restart. is that correct?
Please re-read what I’ve said, those questions have been answered. No, it’s not normal behavior, and no it has nothing to do with the ZCOMBO.
there is a misunderstanding then. Above i said;
All the other battery powered devices, wakeup eventually and turn from red to green “complete”
So no, there is no issue with ANY other device.
So you are saying that after a network restart the ZCOMBO devices should appear “complete” if they were “complete” before the restart?
See here:
You’re focusing too much on this single device and missing the real problem. The root problem is that all of your battery devices are reverting to ProtocolInfo after a restart (that’s what you’ve previously said??). Your problem is not that the ZCOMBO is stuck in ProtocolInfo, that’s just a side-effect of the root problem. After a restart every device should remain Complete if it was in that status prior to the restart. Like I said, after hundreds of restarts my nodes have never reverted to ProtocolInfo, unless I manually re-interview them.
There’s not much more that can be uncovered without Debug driver logs.
the other devices are fine. I don’t have a problem with others. let’s not try to debug something else. The only question in need answered is:
-If i restart my zwave network will the ZCOMBO devices still be able to work and send notifications in case of a detected event (fire, CO2) to HA via zwaveJS WITHOUT having to wake them up? .Assuming a healthy zwaveJS server config
If NO, then that is all i need to know, these ZCOMBO devices with 0.5FW then are useless as you can’t rely on them if for some reason you zwave server restarts
If YES, then i need to go back and debug the zwaveJS installation to see why this is not the case.
As measured by ProtocolInfo or Complete status seen in zwaveJS
If your statement is that, after a restart, all the battery devices revert to ProtocolInfo, then they are not fine, and so it’s the same problem as the ZCOMBO. It’s not normal for any device to revert back to ProtocolInfo after a restart. You can’t ignore this because it then points to a problem with the entire system and not a specific device.
-If i restart my zwave network will the ZCOMBO devices still be able to work and send notifications in case of a detected event (fire, CO2) to HA via zwaveJS WITHOUT having to wake them up? .Assuming a healthy zwaveJS server config
Yes, of course. As long as nodes are in the Complete state, they will function. There’s never a need to manually wake up a device unless re-interviewing or setting a configuration parameter (and you want it set immediately).
No device will fully function in HA if the interview status is ProtocolInfo. Your other devices may transition to Complete eventually, but this could take hours or days depending on how they are configured to wake up. It’s not a problem for you that these other devices are also unusable in that time?
Right now all the ZCOMBO devices are in complete state. So you are saying if i go and reboot my network now, after the reboot they should be in complete again? all of the 0.5 FW version
That’s the normal behavior. Turn on debug driver logs if you’re going to restart.
ok, i restarted and yes, enabled debug drivers.
Everything went fine. even the ZCOMBOS remain in complete so it is all good. The network survives the restart without losing the ZCOMBO devices. So, there is NO issue here.
Well, i am sorry i created all this confusion. I think what happened was that i saw that behavior right after i migrated from OZW wher that problem existed. After migrating and first boot for zwaveJS, i think all devices reinterviewed and that is why i was confused, i did woke up the ZCOMBO devices so they moved to green/complete. It’s all good now.
Only issue now seems to be an old/unknown device that is a failed node and can’t be removed. I opened a bug in zwaveJS
thanks for everything. So after all, YES the ZCOMBOs need to be woken up but maybe only when the batteries are replaced. ZwaveJS is awesome and it is such an upgrade from OZW or the older integrations. Everyone should upgrade to ZwaveJS, it is absolutely superior in every possible way.
I am considering eliminating the docker for zwaveJS and moving to the native HA integration, now that this thing can survive restarts effortlessly, any opinions on that?
thanks
No worries, glad there wasn’t actually any problem with the cache after all.
The Z-Wave JS integration requires a zwave-js server such as zwavejs2mqtt. You would still need it, unless you are talking about moving to an Addon. If you switch to an Addon, you’ll need to rebuild the cache, which means waking up the nodes again. If you’re talking about the using the integration, just make sure the websocket server is enabled in the zwavejs2mqtt configuration and configure the integration with the hostname/IP of zwavejs2mqtt. https://zwave-js.github.io/zwavejs2mqtt/#/homeassistant/homeassistant-official