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

Setup, Configuration and Use Beginners
,
1
  • Platform information:
    • Hardware: Intel NUC
    • OS: openSUSE 15.2
    • Java Runtime Environment: zulu11.43.55-ca-jdk11.0.9.1-linux.x86_64
    • openHAB version: openHAB 3.1.0 - Build #2165
    • Z-Wave Controller: Aeotec Z-Stick Gen5 (ZW90)
    • Z-Wave Device: Aeotec Door/Window Sensor 7 (ZWA008)

Dear Community,
i was able to include the device successfully. Name of the device is show correct so far as i can understand it. I created items for door/window and battery information. These information are not updated on device change. Door/window is still null and battery stay at 0%. I tried to disable and enable the device a couple of times without success.

When i do a debug i see information/traffic send from the node when i wake the device up. When i try to simulate a door open or close the red light is blinking but i do not see any information in the debug log. All my other Z-Wave devices are running without any issues.

I tried to wakeup the device a couple of times to finish maybe the integration.

device info

  • zwave_class_basic BASIC_TYPE_ROUTING_SLAVE
  • zwave_class_generic GENERIC_TYPE_SENSOR_NOTIFICATION
  • zwave_frequent false
  • zwave_neighbours
  • zwave_lastwakeup 2021-01-30T16:51:10Z
  • modelId ZWA008
  • zwave_version 0.0
  • zwave_listening false
  • manufacturerId 0371
  • manufacturerRef 0002:0007,0102:0007,0202:0007
  • dbReference 1065
  • zwave_deviceid 7
  • zwave_nodeid 29
  • vendor Aeotec Limited
  • defaultAssociations 1
  • zwave_routing true
  • zwave_beaming true
  • zwave_secure false
  • commandClass:COMMAND_CLASS_SECURITY setVersion=2
  • zwave_class_specific SPECIFIC_TYPE_NOTIFICATION_SENSOR
  • zwave_manufacturer 881
  • zwave_devicetype 2

Log (one example of my tests)
openhab> log:set debug org.openhab.binding.zwave
2021-01-31 07:06:44.841 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage 0 out at start. Holdoff false.
2021-01-31 07:06:45.410 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 29: Handler disposed. Unregistering listener.
2021-01-31 07:06:45.436 [DEBUG] [l.initialization.ZWaveNodeSerializer] - NODE 29: Serialise aborted as static stages not complete
2021-01-31 07:06:46.044 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - Initializing ZWave thing handler zwave:device:7e50ff6d06:node29.
2021-01-31 07:06:46.045 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 29: Controller status changed to ONLINE.
2021-01-31 07:06:46.046 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 29: Controller is ONLINE. Starting device initialisation.
2021-01-31 07:06:46.047 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 29: Updating node properties.
2021-01-31 07:06:46.047 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 29: Updating node properties. MAN=2147483647
2021-01-31 07:06:46.048 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 29: Properties synchronised
2021-01-31 07:06:46.048 [DEBUG] [ve.internal.protocol.ZWaveController] - Event listener added.
2021-01-31 07:06:46.049 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 29: Initialising Thing Node…
2021-01-31 07:06:46.049 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 29: Initialising cmd channel zwave:device:7e50ff6d06:node29:sensor_binary for OnOffType
2021-01-31 07:06:46.049 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 29: Initialising state channel zwave:device:7e50ff6d06:node29:sensor_binary for OnOffType
2021-01-31 07:06:46.050 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 29: Initialising cmd channel zwave:device:7e50ff6d06:node29:scene_number for DecimalType
2021-01-31 07:06:46.050 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 29: Initialising state channel zwave:device:7e50ff6d06:node29:scene_number for DecimalType
2021-01-31 07:06:46.051 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 29: Initialising cmd channel zwave:device:7e50ff6d06:node29:sensor_door for OpenClosedType
2021-01-31 07:06:46.051 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 29: Initialising state channel zwave:device:7e50ff6d06:node29:sensor_door for OpenClosedType
2021-01-31 07:06:46.051 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 29: Initialising cmd channel zwave:device:7e50ff6d06:node29:alarm_burglar for OnOffType
2021-01-31 07:06:46.052 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 29: Initialising state channel zwave:device:7e50ff6d06:node29:alarm_burglar for OnOffType
2021-01-31 07:06:46.052 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 29: Initialising cmd channel zwave:device:7e50ff6d06:node29:battery-level for PercentType
2021-01-31 07:06:46.053 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 29: Initialising state channel zwave:device:7e50ff6d06:node29:battery-level for PercentType
2021-01-31 07:06:46.053 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 29: Polling initialised at 1800 seconds - start in 757800 milliseconds.
2021-01-31 07:06:46.053 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 29: Device initialisation complete.
2021-01-31 07:07:26.027 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 0C 00 04 00 14 06 31 05 03 0A 00 00 D8
2021-01-31 07:07:26.027 [DEBUG] [nal.protocol.ZWaveTransactionManager] - processReceiveMessage input 0<>128 : Message: class=ApplicationCommandHandler[4], type=Request[0], dest=20, callback=0, payload=00 14 06 31 05 03 0A 00 00
2021-01-31 07:07:26.027 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Received msg (0): Message: class=ApplicationCommandHandler[4], type=Request[0], dest=20, callback=0, payload=00 14 06 31 05 03 0A 00 00
2021-01-31 07:07:26.028 [DEBUG] [nal.protocol.ZWaveTransactionManager] - lastTransaction null

After that i used the magnet to open/close but there are no more logs.
I found a couple of other topics but there it looks like that the device was unknown which in this topic here is not the case.

Does anyone know if there is a general issue with that device or maybe i’m doing something wrong.

Thanks in adance

1 Like
2

I am curious, when you look at the device properties, do you see a value set for the lifeline association group?

image
image745×285 8.32 KB

3

No - Lifeline and group 1-4 are all empty = nothing is configured

image
image749×330 9.54 KB

For a test i set the lifeline to Controller (as in your screenshot) and after that i simulate a door open/close and wakeup. No update in the logs which are still set to debug.

It looks like after a restart from openhab.service the setting is lost. I dont know if this is normal or not.

Edith says:
even if i set all groups and lifeline to Controller nothing will be updated.

4

No that is not normal. The lifeline setting should be populated and except under extraordinary circumstances it should be set to the controller node. You should also be able to modify this value in a properly communicating device.

However, as I began to document here but have since discovered is a problem that goes beyond just aeotec devices, I have seen this behavior on every battery operated device I have tried to include using OH3. Most battery devices that were previously included and migrated over from OH 2.5 have a lifeline value and work flawlessly. Any battery device I have included using OH3 has no value for lifeline and no way to set it which means the controller does not receive it’s updates.

@chris Any idea what’s going on here? What else do you need to see to help sniff out this issue?

5

Thanks for your information @JustinG and when i read about your problem it sounds the same.

6

That database item has not been updated since OH 2.5.0 It clearly shows Group 1 as Lifeline.
Try deleting (NOT exclude from the network) & rediscovering / re-adding the Thing

image
image782×381 8.39 KB

7

This is more serious than just that. In fact, as I have discovered with both the aeotec nanomote and just yesterday with the Zooz outdoor sensor. If you remove the item and rediscover the controller/OH3 can never properly re-identify that node without actually excluding and reincluding. Doesn’t matter how many times you wake it up, doesn’t matter what the controller is doing, actively scanning or not.

Edit: as with the nanomote, it turns out no xml file was created for the Zooz outdoor sensor despite initial adding of the item being complete and all properties but the lifeline being set to the correct default value.

Edit 2: I added 7 zwave devices to my setup yesterday. 6 mains powered and the one Zooz outdoor sensor. All 6 mains powered devices added perfectly including properly creating xml files. This problem only occurs with battery devices on OH3.

1 Like
8

I removed all items and deleted the device and also renamed the xml file in /var/lib/openhab/zwave.
After that i did a restart and try to implement the device again. Now i’m not able to get the device running as even after a couple wakeups nothing is happen.

/var/lib/openhab/zwave -> no node29 xml file

image
image764×765 21.6 KB

9

Yes, we’re clearing seeing exactly the same behavior in several different devices.

I have just tried to run through this from scratch and remembered this time to set the log to debug. I excluded one of my nanomotes, factory reset it, and re-included it.

Here is a link to the log file. I had it on debug during the include. I then turned off debug and checked what was going on after the initial include (it is now NODE 46). When I saw that the device didn’t appear to be quite fully initialized, I started debug up again and rewoke the device several times. Now it is stuck in this same state again. At 11:44:02 in the log it claims that NODE 46 add status is done. But maybe someone else who understands these things better can take a look and see what I don’t.

10

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

11

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.

12

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

13

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

1 Like
14

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.

15

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

16

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.

17

which are battery or mains powered?

18

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
19

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

20

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