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?
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?
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
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?
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
yeah i have zwavejs2mqtt server and the integration. But i run HA core, so i don’t want to move to hassio and the add on. I’ll stay where i am at, as it will give me separate full control of the zwave network
This topic is a bit old but unfortunately I’m having trouble adding First Alert Z-Wave Smoke / CO Combo Alarm’s Gen 2.
I have a Aeotec Z-Wave Gen5 Stick and running Zwavejs2MQTT as a docker container.
Already running six zwave devices. But I can’t figure out how to include these First Alert devices.
I have taken these steps:
zwavejs2mqtt in the controlpanel is choose under actions → Manage Nodes → inclusion → Default
then the inclusion starts for 30sec…
First Alert device: Slide battery door open → Press and hold the test button → while holding the test button i close battery drawer → then i release the button. the device beeps
result: Nothing!
Also when i try to include the device with just the Aeotec Z-Wave Gen5 Stick (push the physical button) it doesnt work
I have the same setup and the same problem. Did you ever figure it out? I started a fresh thread over here but have zero replies: First Alert Zcombo Wont Discover
Interesting… I’ll go check my hardware but I’m in the California and I’ve bought everything locally here in the US. I’m pretty sure I have the plain Gen5 Z-stick 810667023034 (that’s the US frequencies) and I bought my First Alert devices from Costco.com and those are most definitely US editions.
I’m having a bit of a hard time getting simple RF frequency information, meaning pure MHz ranges (as opposed to “US freq” or “EU freq” which can be easily misquoted). I’m just trying to be ultra careful to check that my hardware should be compatible.
It is a a bit of a pain if you have the regular Z-wave versions and not the Z-wave Plus ones. If that is the case here is what I had to do with all of mine, but it has ultimately worked every time. I also found opening a Debug window on another device while going through the process is helpful. First Alert Smoke Detector and Carbon Monoxide Alarm Setup - #42 by inkblotadmirer