I have set up my AEOTEC hub, all seems fine. I added a ZCOMBO, again, it looks fine. I do see the properties (which came in after numerous “wake up’s”. However, none of the channels ever show a value and the log is indicating that it won’t poll until initialization completes. (exact message: Polling deferred until initialisation complete)
I have repeatedly 'wakened" the device up, have tried reboot, even tried a complete power down/back up. No error is showing up in the logs (besides the one noted).
Sometimes the initialization gets stuck, actually not stuck, but only processes one configuration message per wake-up. Since some devices require 50 steps this can take a lot of wakeups. I wrote this for a PR (that could address the issue (just look at the kick queue discussion)), One and DONE log details.pdf (933.6 KB)
but bottom line for now is to keep waking. Forget the reboot and other things, it will only slow down the process. If you post the debug log and use the zwave debug viewer you can see if this is the problem or you have something else going on. You will know when you are done when you have 5 lines on the UI page or an xml file dated after the controller.
Thanks so much! I have not noted anything in the debug log. I will continue to wake it up. It did take many wake up’s before the properties showed up. Sounds like I am just being impatient.
The log should show something, like “node is Awake”, “node is asleep” if nothing else. But give it more tries. The “awake duration” is typically 5 seconds, so you can try the device wake protocol fairly quickly again (and again). It is understandably frustrating.
only two messages I see are “Polling” followed by the Polling deferred message. Never says Awake or Asleep. Could that be a clue? The status on the Thing is Online.
These are the properties on the Zcombo: (excuse the formatting…just copying from the screen)
zwave_class_basic
BASIC_TYPE_ROUTING_SLAVE
zwave_class_generic
GENERIC_TYPE_SENSOR_NOTIFICATION
zwave_frequent
false
zwave_lastwakeup
2022-02-11T18:36:51Z
zwave_neighbours
modelId
ZCOMBO-G
zwave_listening
false
zwave_version
0.0
manufacturerId
0138
manufacturerRef
0001:0003
dbReference
1295
zwave_deviceid
3
zwave_nodeid
3
defaultAssociations
1
vendor
BRK Brands, Inc.
zwave_routing
true
zwave_beaming
true
zwave_secure
false
zwave_class_specific
SPECIFIC_TYPE_NOTIFICATION_SENSOR
zwave_devicetype
1
zwave_manufacturer
312
It says that the button pushing you are doing is not waking the device. The device needs to be awake to get configuration messages. I do not have the device, but sometimes the instructions say press 3 times, but just one press will wake the device. What is concerning is this;
That was 12 days ago
Bob
edit: one other thing to try would be to remove the battery, wait a few seconds and put the battery back. Sometimes that will get an “awake”.
Thank you so much! I never saw that wake up time/date in the properties…looked right past it. I now know to look more closely. I will try pulling the batteries and trying for a wake up that way. A bit later since the alarm drives my little dog crazy and I want to see if I can prep a ‘don’t worry about the sound’ solution for the little fellow. {yes, I know…}
Real prograss! The lastwakeup value has now changed and the status is now: Node initialising: VERSION
The log still contains the same ‘polling deferred’ message but at least we have a change.
PS. My dog is going nuts with all the beeps but goodies seem to be keeping him from a coronary event.
after many wake-ups. I finally got it to show both ONLINE and the polling runs. However, the battery level doesn’t update. It almost looks like the queue is growing, not executing…
NODE 3: Polling…
2022-02-23 09:01:47.031 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 3: Polling zwave:device:8fac58dd03:node3:alarm_system
2022-02-23 09:01:47.031 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 3: Polling zwave:device:8fac58dd03:node3:alarm_co
2022-02-23 09:01:47.032 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 3: Polling zwave:device:8fac58dd03:node3:alarm_smoke
2022-02-23 09:01:47.032 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 3: Polling zwave:device:8fac58dd03:node3:battery-level
2022-02-23 09:01:47.033 [DEBUG] [rnal.converter.ZWaveBatteryConverter] - NODE 3: Generating poll message for COMMAND_CLASS_BATTERY endpoint 0
2022-02-23 09:01:47.033 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 3: SECURITY not supported
2022-02-23 09:01:47.034 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 3: Command Class COMMAND_CLASS_BATTERY is NOT required to be secured
2022-02-23 09:01:47.035 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 3: Bump transaction 89 priority from Get to Immediate
2022-02-23 09:01:47.035 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 3: Adding to device queue
2022-02-23 09:01:47.036 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 3: Transaction already in queue - removed original
2022-02-23 09:01:47.036 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 3: Added 89 to queue - size 1
2022-02-23 09:01:47.037 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage 0 out at start. Holdoff false.
