Z-Wave issue update channels/item with Aeotec Door / Window Sensor 7

I’ve created a github issue for this here. If you are so inclined you can add your own details to that thread to help pinpoint the problem.

1 Like

I was able to include Fibaro Door Window Sensor 2 the sensor the successfully. All channels have been created but no update for battery or door sensor after a couple wakeups or test open/close. Both values were still at NULL.

I had this exact issue OH3 Aeotec Door Window Sensor and all the channels configured but reported NULL on the items. I solved it by selecting the Thing and clicking on Heal the device and then woke the sensor up with the action button… I blinked amber for a very long time and then began reporting the open and closed values.

Not sure the cause of the problem. Hope this helps until it is resolved.

ok cheers I have exactly the same problem and tried to follow your advice but sadly no luck at all. Even tried excluding it and removing from OpenHab and tried to include it again but still showing NULL on all channels. Anyone else had any luck?

Hi. Did you eventually solve this?

No. Sadly.

This is almost always incomplete initialization. What version of OH3 are you on? Do you have five lines on the UI page (only 4 means not fully initialized)?
Five Lines of configured node
Also is there an XML for the node in var/lib/openhab/zwave? (userdata/zwave?)

1 Like

Hi

OpenHab3. Ok there were 4 lines (there was an XML file there) so I excluded the sensor again and re-added it. This time when it scanned the Z wave network it was showing up as a different node? which is odd as there are now two showing with different nodes but pointing to the same sensor?? I hadn’t noticed that before. This time instead of choosing the previous node number I chose the new node so ive added this new one and now it shows 5 lines. A new XML is created.

OK Success!!! When I popped back the cover on the sensor and moved the magnet to it the sensor then woke up and now it shows OPEN and CLOSED - not NULL!!

Woo hoo!!

Thanks for your help and suggestions.

Glad it is working :grinning:

For future reference, repeated awakes will fully configure the node (eventually). No reason to exclude. Battery devices can get hung up and only process one command per each awake (out of the 50-60 required for full configuration), so it can be super tedious. Further, some device manuals provide the incorrect information on how to awake. (i.e. Inclusion may require 3 presses, but awake only one). Therefore without the Zwave binding in Debug you can’t tell if you are really waking the device, adding to the frustration.

As to two nodes, there might be some cleanup required. Excluding should have the UI page for that node as OFFLINE with a note “Node Excluded from controller”, if yes simply delete that page. It should have also removed the XML for that node. If no, as a battery node it is not involved with routing packets, so should be benign, but should eventually be removed with the Silabs PC controller.
Z-Wave Zombies.pdf (571.9 KB)

It is normal that an inclusion, after an exclusion, the next higher node number will be used

This. Thank you very much for the pointer. I had the same issue, it took doing 3 or 4 device heals and multiple awakes of the device up manually (single press on the tiny! switch) plus moving another Z-Wave switch nearby for better reception, in order to get the device fully working. (Ultimately I have a range extender waiting to be deployed which could have helped.)

I wonder if it’s possible if the GUI could identify cases where the initialization has not completed like this and give a better warning. Could be straightforward, but a PR for this is probably beyond my capabilities. Just mentioning it if somebody sees this who might find it quick/easy.

Thanks again.
-nik

@nikconwell- The developer merged a PR of mine to improve the initial discovery problems with battery devices in OH3.3 (around June 2022), so it should be much rarer (and based on forum traffic does seem to be less frequent) that a battery device is not initialized on the first try (or at most 2-3 wakes). One element of that PR was to log an INFO that the battery timer had expired, and the device was not fully initialized, however that was reverted back to the DEBUG level by the developer after a couple of months. The PR included an advanced parameter to increase the maximum battery awake time from 10 seconds (default) up to 20 seconds. If less time was needed the device would go to sleep earlier. The idea with the INFO was that it was a hint the maximum should be raised. However, there were complaints because the maximum was being reached in some systems frequently during a battery device “Heal” and was viewed as spam. Heals on larger networks generally take longer than the initial inclusion.

tl:dr- IMO there will be no INFO (or WARN) message, just keep an eye on the four/five lines on the UI or an xml in the USERDATA/zwave folder.

fyi-Device “Heals” are ignored on a non-fully configured device. The only helpful thing to do is wake the device every 10-20 seconds.

1 Like