Aeotec Door/Window Sensor 7 - Binary Input channel stops updating

Hi all

I’m really struggling with two Aeotec Door/Window Sensor 7 (ZWA008) and it’s binary input.
I’m on OH3.1 and using some other devices of Fibaro and Cyrus successfully.

What works:

  • Successfully included
  • Able to configure device
  • Binary Sensor working (for some time)

Problem:
The Device sudden stops working, perhaps after one day. I do not receive anymore status updates on the binary input channel. However I can see the device reacts to status changes of the binary input (red light), therefore I think the device tries to send the new state.

What I did:
I already reincluded the devices, (the second device is now orphaned and I’m not able to remove it from controller to reinclude :-(, but first I want to get running the other one)
After reinclude the first device the status reflected again for a short time.
It seems it is not time related, than state change related. I think after a few state changes (maybe between 2 and 4) it stops working.

I was able to collect a zwave Debug log. I’m not very familiar with this, but I saw that the status is updated twice and at one point the state change is not “ON” or “OFF” but “Open” or “Close”. Is it possible that this causes the issue? Where is this come from?

Sometimes device wake up (single and tripple click) brings the device back to work until it fails again.

Log Explanation
The first state change on 13:53:12 worked, but afterwards it stopped working (13:53:14 + 13:53:45).

Aeotec Binary Input.txt (21.3 KB)

Nobody who can give a tip or understand whats the problem here?
Is there someone who is using the binary input too?

I saw another post with maybe a similar situation, where @chris was able to resolve it by updating a database definition. Maybe its a similar issue here.
[SOLVED] Aeotec water sensor DSB45, binary “channel” - Add-ons / Bindings - openHAB Community

My only suggestion is to be sure the device is fully included. On the UI page for the thing, are there 5 lines at the bottom including “reinitialize device” ? Also is there an xml in user data/zwave with the node? If not it is not fully configured and will behave badly.

I only mention this because the post you referenced seemed to be that issue, not a database issue, at least as far as I read.

The “reinitialize device” button was there. I always wake up battery devices until this button appears.
But after some time or maybe after the first “false” report, the button disappears (as it is now)
The XML is also created.

The post i meantioned will continue after the first “solution”, where another solution (database) is provided…

If the button that disappears is the “reinitialize device” button that should only happen on a OH restart or a “heal” so that seems odd to me, but I don’t know what else it could mean.

I have sometimes had quirky performance of a binary channel and maybe a database fix of some sort would help (beyond me at this point). Can you use the alarm channel, It looks like it keeps working (from your log).

Bob

I noticed that all of my battery devices don’t have the “reinitialize device” button anymore. But I’m sure they have after inclusion.
However, reviewing the log again I noticed that not a wrong value comes back (ON/OFF or OPEN/CLOSED) but that the “sensor_door” channel is also updated if the binary input (should) update. Therefore as a workaround I use the state of channel “sensor_door” for my script.

Thank you for your inputs.

If someone is able to find the problem on the binary channel, just let me know :slight_smile:

Glad you are up and running with a working channel.

I did have a thought while running errands. Motion detectors (for example) once triggered will have a delay until OFF. The behavior in the log snippet could indicate that the binary, once triggered (or untriggered), may stay in that condition, despite other changes. The idea might be to turn on a light when the door opens, but not turn it off right away after the door closes. Usually there is a parameter that can set that time. Don’t know if this is applicable and since you are ok, it is moot anyway.

Bob