Like many people, I had trouble getting the First Alert ZCOMBO smoke/CO alarm to initialize and be recognized properly by the ZWave binding. The initialization would not progress beyond the MANUFACTURER state, despite waking the device up dozens of times.
Here is a typical log when waking the device up (by sliding out the battery slot, removing and reinserting a battery, and closing the battery slot while holding the button down).
2021-09-11 20:17:26.215 [DEBUG] [essage.ApplicationUpdateMessageClass] - NODE 24: Application update request. Node information received. Transaction null
2021-09-11 20:17:26.217 [DEBUG] [essage.ApplicationUpdateMessageClass] - NODE 24: Application update - no transaction.
2021-09-11 20:17:26.468 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 24: Is awake with 1 messages in the queue
2021-09-11 20:17:26.469 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 24: COMMAND_CLASS_WAKE_UP not found - setting AWAKE
2021-09-11 20:17:26.471 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 24: Start sleep timer at 5000ms
2021-09-11 20:17:26.471 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 24: Got an event from Z-Wave network: ZWaveNodeStatusEvent
2021-09-11 20:17:26.475 [DEBUG] [ve.internal.protocol.ZWaveController] - NODE 24: Node Status event - Node is AWAKE
2021-09-11 20:17:28.972 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 24: WakeupTimerTask 1 Messages waiting, state MANUFACTURER
2021-09-11 20:17:31.471 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 24: WakeupTimerTask 1 Messages waiting, state MANUFACTURER
2021-09-11 20:17:31.472 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 24: No more messages, go back to sleep
Suspecting that the device just needs more time to do the transactions, I increased the sleep timer in the binding from 5000 to 30000 ms and recompiled it. After loading the updated binding, the device initialized completely on the first or second wakeup!
This appears to just be a problem with the zwave binding, rather than the device. I am not sure if increasing the timeout has any other detrimental effects, but it seems to have fixed this issue!
@marcusb I’ve got the same issue with the ZCombo device.
Increasing the sleep timer has been discussed at length with @chris but he is reluctant to do it. In fact there was a pull request by @apella12 for an elegant solution with a variable timer but it was not accepted.
Could you share details of your binding modification so I could attempt to modify my z-wave binding?
I don’t understand the protocol well enough to have an opinion about the suitability of these PRs - all I can say is that this patch fixes my issue with the smoke alarm.
First @brianlay thanks for the compliment. I only have rudimentary java skills but have found using VSC to edit the zwave binding alerts me to my mistakes and googling java errors helps me to understand why.
AFAIK you will have to recompile the code after making any change. I used these instructions as a guideline (note: OH3 uses Java 11) but ended up finding a way to install maven on my windows machine as I also only have only rudimentary linux skills.
Having played with battery devices for a year, simply changing the timer to 30 seconds could have battery implications. The “if initialization is complete” will also be “false” on a restart or if a network heal is queued. Mitigating this somewhat is that by Silabs standards a battery device will go to sleep on its own in 10 seconds without a controller message. On my system a battery node needs 2 seconds for an OH restart and (for most devices) the “heal” needs 8 - 15 seconds (for one-time), so the device will be using the battery for 10 extra seconds per event.
The problem with battery devices is if they do not complete (or get far enough along in the process) when first-time inclusion is started, they tend to get stuck. The log snippet above shows this. The sleep timer is started, there is a message in the queue, but nothing happens for 5 seconds. If the log was extended you would see that the “go back to sleep” message triggers 1 configuration message before going back to sleep. Since there can be 50+ configuration messages (depending on the device) this is a slow painful process. I have not figured out why this happens, and I don’t believe changing the time to 30 seconds will help it. As a side note, the zwave binding “heal” has no problem picking up where it left off, so even with the 5 second time, in two to three “wakes” the heal is completed.
The solution is to initialize the device on the first try. Initialization of my devices actually is done in 5-6 seconds. What you say? The main culprit is identified in another PR. At the end of the initial discovery (during the SCAN phase) the “ADD Node Stop” message is called twice. By Silabs specs the first time requires a response, but the second time doesn’t, so the second message is issued without a callback number. However, elsewhere in the zwave binding the “ADD node stop” message is set to require a response, so the second message is doomed to fail. It takes 5 seconds for the second message to fail and that eats up 4 seconds of the initial wake time, leaving only 1 second. That’s not enough time to get very far and that leads to a log file like above. I mention this because if you change the sleep timer, exclude the node and start from the beginning. Also IMHO 30 seconds is way too long. Change the “ADD Node stop” and go (at most) to 10 seconds.
Recently (OH 3.3M6) some battery device enhancements were merged that could help you. You can set more time for initialization (under controller UI-advanced). It is also in the latest zwave snapshot if you want to go that route.
20 is max and should be plenty. I would need to see a debug file of an “awake”. I’m suspecting it is not sending “awake” but a NIF. What does the manual say for “awake”? Sometimes when it says three presses, only one is needed. Maybe just remove the battery, wait a bit and reinstall. The last option would be to exclude and try from the beginning with one device.
Bob
Edit: heal does not work at this point, so do not try that.
Edit2: Since we are several hours apart, what I’m looking for is something like this from the first post, the key being “awake”
I unplugged my zwave stick and plugged it into my windows laptop and fired up the siLabs z-wave controller
I removed 3 bogus nodes, including 2 for the smoke detector
I put the stick back into my OH server
I factory reset the smoke detector
I deleted the smoke detector thing
I put the smoke detector into inclusion
I did an OH zwave scan
The detector was discovered
I linked it to the existing items
I did a “wake up” on the detector
The items are no longer null
I saw a bunch of “node 16” messages that indicated that everything is hunky dory
WHAT A MASSIVE PITA. I was just about ready to return all 9 detectors to Costco (I’m sooooo glad I bought them there)
SOOOO…
after I get all of the detectors installed, do I set the controller setting for awake duration back to 10?
No amount of “waking” showed ANY activity in the zwave debug log.
I got my zwave debug logging going to it’s own file as it extremely noisy
(I should do the same for zigbee)
Interesting. I did glance through the device manual in the DB and could only find the remove/reinstall the batteries to get an “awake”. The reason I was emphazing that is the enhancements (timer cap) are for an “awake” or first-time initialization (that includes an “awake”). Anyway you must have gotten there or it would not be working.
Not necessary. The timer is a maximum or cap. If the messages that need to be handled between the binding and the devices during an “awake mode” are finished in less time, the node will be sent back to sleep. No “awake mode” battery time is wasted. If you are network healing, I would tend to leave at 20 for the time being. During my testing of the PR I had it at 19. If you do decide to lower, there is new INFO level message that tells you when the time limit was reached, but there was more messages that needed to be done. These can’t be avoided from time to time, but if there are a lot of them, raise the maximum awake period higher.
For the sake of science it would be interesting for me to see a Debug level log file of an initialization of one of these devices (from scratch). I’m curious how long it is really taking. No need if you don’t want to bother.
