ZCOMBO and sleep timeout

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!

@chris Any insight here?

(I have openHAB 3.1.0, current main branch build of the zwave binding.)

1 Like

@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?

Thanks

Yes, it’s a tiny change, please see this PR.

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.

Probably more than you wanted to know :wink:
Bob