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

Is this the Aeotec Door/Window Sensor 7? Is it battery powered? I’m guessing because Justin was saying this is an issue with battery powered devices it is but anyhow… I know some of the Aeotec devices can be battery or can plug in and if you intialize it on power and then switch to battery it isn’t good.

I’m guessing keep trying. I’ve had battery powered nodes that had to be woken up so many times I was sure something else was wrong.
Your screen shot under ‘Information’ next to ‘Thing Type’ it says ‘Unkown Device’. That to me means it is not initialized yet

@JustinG that is some good diagnostics, I think you may be on to something
Unfortunately, I think Chris is busy moving or something… maybe Bruce knows

Chris will be moving Internationally (UK - New Zealand) and has just found out he needs to rush and pack before shipping rates rise drastically. I would guess he is extremely busy with that right now.

OK, that is not right
Do other devices create an XML files, this isn’t a permissions thing right?

Good heavens. Best of luck to him on that. There are few things in life I despise more than moving.

1 Like

This is not a permissions issue. I’ve double and triple checked that (especially since I moved from a native install to docker with my upgrade to OH3).

Mains powered devices that I’ve added (both a few weeks ago and just yesterday) all properly created xml files.

ok, I didn’t think so but wanted to check

if this is a regression in OH3, me thinks we may need to file an issue on github. Do you have an account?
I’m off to read the other thread you posted here

oh and @DrMett sorry and did not mean to hijack your thread, we have moved that discussion over to that thread

file permission is not the issue - i’m actually moving z-wave devices from my old network to my new one. On the same day i was able to successfully add two Fibaro devices.

The sensor is battery powered and not using any power supply.

which are battery or mains powered?

Both devices were not battery powered and the last battery powered device from Fibaro have been setup this month. I think tomorrow a new Fibaro door/window sensor will be delivered and i’ll check it.

The installation is a new openhab 3 one with no migration from 2.x.

1 Like

OK well maybe keep an eye on Justin’s other thread

we may be on to a regression in OH3 with battery operated devices

good! hopefully narrow it down some more
keep us posted

Hello,
I appear to be encountering a similar / the same issue:

I have just installed an Aeotec Z-Stick Gen5+ connecting to a Door/Window 7 (as node 3).
Openhab 3.0.0

The device appears to have registered correctly. However, only reads nulls for all parameters. I have tried setting the Group fields 1 to 4 to Controller, then taking the sensor over off to force regular updates. Still no luck.

Thanks in advance for any assistance.

The log entries are:

2021-01-31 19:30:53.959 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 3: Configuration update received
2021-01-31 19:30:53.975 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 3: Configuration update ignored config_10_2 to 0 (BigDecimal)
2021-01-31 19:30:53.975 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 3: Configuration update set group_4 to [controller] (ArrayList)
2021-01-31 19:30:53.975 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 3: Association 4 consolidated to [controller]
2021-01-31 19:30:53.975 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 3: Unknown association group 4
2021-01-31 19:30:53.975 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 3: Configuration update set wakeup_interval to 0.0 (BigDecimal)
2021-01-31 19:30:53.990 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 3: Set wakeup interval to ‘0’
2021-01-31 19:30:53.990 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 3: Configuration update set group_1 to [controller] (ArrayList)
2021-01-31 19:30:53.990 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 3: Association 1 consolidated to [controller]
2021-01-31 19:30:53.990 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 3: Unknown association group 1
2021-01-31 19:30:53.990 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 3: Configuration update set group_3 to [controller] (ArrayList)
2021-01-31 19:30:53.990 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 3: Association 3 consolidated to [controller]
2021-01-31 19:30:53.990 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 3: Unknown association group 3
2021-01-31 19:30:53.990 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 3: Configuration update set group_2 to [controller] (ArrayList)
2021-01-31 19:30:53.990 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 3: Association 2 consolidated to [controller]
2021-01-31 19:30:53.990 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 3: Unknown association group 2
2021-01-31 19:30:54.006 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 3: Configuration update ignored config_1_1 to -3 (BigDecimal)
2021-01-31 19:30:54.006 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 3: Configuration update ignored config_2_1 to 0 (BigDecimal)
2021-01-31 19:30:54.006 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 3: Configuration update ignored config_7_1 to 255 (BigDecimal)
2021-01-31 19:30:54.006 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 3: Configuration update set wakeup_node to 0.0 (BigDecimal)
2021-01-31 19:30:54.006 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 3: Set wakeup node to ‘0’
2021-01-31 19:30:54.006 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 3: Configuration update ignored config_8_1 to 0 (BigDecimal)
2021-01-31 19:30:54.006 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 3: Configuration update ignored config_9_2 to 0 (BigDecimal)
2021-01-31 19:30:54.006 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 3: Configuration update ignored config_11_2 to 0 (BigDecimal)
2021-01-31 19:30:54.006 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 3: Configuration update ignored config_12_1 to 1 (BigDecimal)
2021-01-31 19:30:54.006 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 3: Configuration update ignored config_3_1 to 7 (BigDecimal)
2021-01-31 19:30:54.022 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 3: Configuration update ignored config_4_1 to 0 (BigDecimal)
2021-01-31 19:30:54.022 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 3: Configuration update ignored config_13_1 to 0 (BigDecimal)
2021-01-31 19:30:54.022 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 3: Configuration update ignored config_5_1 to 0 (BigDecimal)
2021-01-31 19:30:54.022 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 3: Configuration update ignored config_14_1 to 1 (BigDecimal)
2021-01-31 19:30:54.022 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 3: Configuration update ignored node_id to 3 (BigDecimal)
2021-01-31 19:30:54.022 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 3: Configuration update ignored config_6_1 to 2 (BigDecimal)
2021-01-31 19:30:54.022 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 3: Configuration update ignored config_15_1 to 50 (BigDecimal)
2021-01-31 19:30:54.053 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 3: Error getting wakeupCommandClass
2021-01-31 19:41:38.948 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 3: Polling…
2021-01-31 19:41:38.948 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 3: Polling deferred until initialisation complete
2021-01-31 19:44:17.309 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 2: Polling…
2021-01-31 19:44:17.309 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 2: Polling deferred until initialisation complete
2021-01-31 20:11:38.954 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 3: Polling…
2021-01-31 20:11:38.954 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 3: Polling deferred until initialisation complete
2021-01-31 20:14:17.485 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 2: Polling…
2021-01-31 20:14:17.485 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 2: Polling deferred until initialisation complete

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