Benext door sensor from rademacher not working

[Gival]

In the Z-Wave screen; the status is not being updated; only the timestamp:

Node Id Basic Type Generic Type Product Name Location Value Last Heard Status
11 BR Routing Slave Binary Sensor BeNext Door Sensor off 00:08:38 Static (sleeping)

I don't see any other log here. I noticed that the details are not filled; while for other BeNext equipement (ie. Multi sensor, Tag Reader and energy switch) it is. For the door contact I only see:

Loaded Config Revision: 0
Config File Revision: 4
Latest Available Config File Revision: 4
Device ID:
Serial Number:
Wake-up Interval: 7200 Seconds
Library Version: Unknown
Protocol Version: Unknown
Application Version: Unknown

[Guest7493264]

For the door sensors, I observe the same "no details" and updates are missed behaviour like Gival.

[rvhu]

I see that the value is change in Zwave console every time i switch the sensor.
Sensor: On
Air Temperature:26.1C
Alarm Type: 2
Alarm Level: 255
Battery Level: 99%

after switch the sensor:
Sensor: On
Air Temperature: 26.1C
Alarm Type: 2
Alarm Level: 0
Battery Level: 99%

So Zwave is reading the correct data only Domoticz is not showing this change.

[Gival]

This issue might be the same issue:
viewtopic.php?f=6&t=25950

@kiddigital , already got time to have a look?

Thanks!

[Guest7493264]

any updates on this? I currently try to order a used aeotec controller gen5 and the benext sensor to have a separate domoticz "test" instance for diagnosis

[Gival]

I switched back to on old version by restoring a backup. I'm now back to:
Version: 4.10178
Build Hash: 13c95bf8
Compile Date: 2018-11-06 13:16:51

Everything is working again (obvisously). I hope we can find the cause so I can upgrade again to latest version.

@Catfirend The BeNext door sensor is hard to find these days since they're not produced anymore for quite some time now. I also had problems with my BeNext scene controler and some other (less important) devices. I'll try to perform a upgrade soon on a seperate SD card so I can do some tests without having to revert back afterwards.

[rrozema]

I've analysed the log; when the sensor connects to the mesh network the following lines are logged:

Code: Select all

2020-11-02 23:41:25.781  OpenZWave: Value_Added: Node: 11 (0x0b), CommandClass: SENSOR BINARY, Label: Sensor, Instance: 1, Index: 0
2020-11-02 23:41:25.782  OpenZWave: Value_Added: Node: 11 (0x0b), CommandClass: ALARM, Label: Alarm Type, Instance: 1, Index: 512
2020-11-02 23:41:25.782  OpenZWave: Value_Added: Node: 11 (0x0b), CommandClass: ALARM, Label: Alarm Level, Instance: 1, Index: 513
2020-11-02 23:41:25.783  OpenZWave: Value_Added: Node: 11 (0x0b), CommandClass: BATTERY, Label: Battery Level, Instance: 1, Index: 0
2020-11-02 23:41:25.990  OpenZWave: Value_Added: Node: 11 (0x0b), CommandClass: SENSOR MULTILEVEL, Label: Air Temperature, Instance: 1, Index: 1

But when the sensor is activated/triggered; nothing is logged. (with -loglevel 3 -verbose -debug). Allthough the last seen timestamp under the Z-Wave device screen is being updated.

Did you already try re-including the device while running 2020.2? Some devices aren't recognized the same way they were in 1.4 and need their definition updated to work correctly. Don't exclude the device, just re-include it as if it was a new device to add to your network (it will be re-assigned the same ID). Have (in another window) the log window open and see if the same list is shown that you gave above or that new/more devices are added. I am asking because I think one ore more devices are missing in that list: you described the device as having a door-sensor (= sensor binary), a temperature sensor (=sensor multilevel), plus an external contact. For that latter device I don't see an entry in your list, i.e. maybe domoticz didn't get the complete node information (NIF) yet. re-including the device gives domoticz another chance at getting the NIF completely.

[rvhu]

I have just exclude the sensor and include again. No changes.
The thinks i See are 4 devices Sensor that is always on, Alarm type that is always off, Alarm level that is always off, Air temperature that equals the room temp. if I look in zwave control panel. I see the following Sensor always on, alarm type set to 2 or 3 depending on which sensor in BENEXT is used. in my case 2 for external sensor. and Alarm level is 255 or 0 depending on if the switch is active or not.
So Zwave is giving the correct info. but this is not correct in Domoticz.

So First question why is alarm type a switch in Domoticz This should be value so you can see witch sensor is used. And the Alarm level is not changing.
or depending on the alarm type a new alarm level devices should be created.

[Guest7493264]

I've now received my test equipment (Aeotec Gen5 ZW Controller + BeNext Door Sensor). I'm trying to compile the commits one by one to hopefully finding out where the problem came in after 4.10717.

Those commits do NOT work using OZW "read-only" current master (newer than git checkout v1.6 because of https://github.com/OpenZWave/open-zwave/issues/1483)
- 10859 d1fceae42 20190606 Updated OZW configuration files
- 10842 40a39f636 20190529 Updated OZW library, partly implemented use of Index instead of labels

Code: Select all

2020-12-22 17:21:49.334 Always, OpenZwave Version 1.6-1570-ga9d57fcc Starting Up
2020-12-22 17:21:49.339 Always, Using Language Localization
2020-12-22 17:21:49.340  Error: OpenZWave: Exception. Type: 1, Msg: Cannot Create SensorMultiLevelCCTypes Class! - Missing/Invalid Config File?, File: /root/build/open-zwave-read-only/cpp/src/SensorMultiLevelCCTypes.cpp (Line 244)

Those commits work using OZW "read-only" current master (newer than git checkout v1.6 because of https://github.com/OpenZWave/open-zwave/issues/1483)


Those commits work using OZW "read-only" 1.4-dirty+g449f89f:
- 10734 3ac5b237d 20190512 Updating history
- 10717 b38b49e52 20190509 Bumping version number

[Guest7493264]

Ok, with openzwave master, compiling from "11561 d2abbdde6 20191209 MQTT added original hardware id in public topic" was the next that worked without the above error message "Cannot Create SensorMultiLevelCCTypes Class!".

I then got the problem we are talking about here (regarding 2020.x+) reproduced at commit "11561 d2abbdde6". It no longer detects the on/off window contact in domoticz devices which was what worked last at "10734 3ac5b237d 20190512 Updating history".

Screenshots:
- https://imgur.com/a/piWf6DD

Earlier commits that reproduce the problem:
- 11250 bc2f645bf 20190901 Buienradar added configuration options for timeframe/threshold
- 11083 406281844 20190811 OZWm, Updated configuration files Updated translations

Earlier commits that use OZW 1.6+ and do NOT have any problem with the BeNext door sensor:
- 10999 95649f7d8 20190714 Reverting OZW patch

[Guest7493264]

To sum up: The problem must have been introduced between Domoticz v4.10999 (WORKING) and v4.11083 (NOT WORKING).

=======

With:
- 11021 68a9e5085 20190721 Updates OZW configuration files
I'm getting:

Code: Select all

2020-12-22 18:29:55.651  Status: OpenZWave: Awake Nodes queried
2020-12-22 18:30:34.639  Error: OpenZWave: Type_NodeEvent, NodeID not found internally!. HomeID: 4179090621, NodeID: 3 (0x03)

Solution:
- mv domoticz.db domoticz.db.old
--> WORKING.

=======

Does WORK:
- 11024 407d06c28 20190722 OZW, better battery updates for devices
- 11027 10bc0c87a 20190724 Adjusted nodeID case
- 11029 cdc33c102 20190725 OZW, added temporarily debug info before GetValueLabel
- 11031 ad1a5b2ac 20190726 OZW Debug Value, removed Unit, added source Line
- 11033 8faa48dc9 20190727 Bugfix: Resolved problem with HTTP Protocol Listen broken by previous fix.

Does NOT work:
- 11034 68ee7a9b1 20190727 OZW, better battery support

So the problem lies between v4.11033 (WORKING) and v4.11034 (NOT WORKING).

[Guest7493264]

I've spotted the problem root cause:
It's commit https://github.com/domoticz/domoticz/commit/68ee7a9b1 - labelled as "4.11034 68ee7a9b1 20190727 OZW, better battery support".

This is causing the BeNext sensor to no longer update its values in Domoticz. When running with 4.11033, the following line shows up in the log and the sensor is correctly updated in Domoticz:

> 2020-12-22 18:51:51.326 (zw) Light/Switch (Sensor)

With 4.11034, this line no longer appears when the sensor transmits a new state.

Reported as GitHub issue: https://github.com/domoticz/domoticz/issues/4532
"Dirty fix": https://github.com/domoticz/domoticz/co ... :fixBeNext
Alternate "dirty fix": https://github.com/domoticz/domoticz/pull/4533/files

[kiddigital]

@Catfriend1 , thank you for your extensive research and debugging efforts that you have put into figuring this out.

I saw that your proposed fix has already been picked up and implemented into the Beta

Let us know if this Beta really solved your issue for good. And I see that others report also that some of their Z-Wave devices are providing better results as well. Great bonus...

[Guest7493264]

@kiddigital

Thanks for your reply. At the moment, I'm running v2020+"patch" and my Z-Wave network works fine (including the BeNext sensors). I'm now heading to BETA 12758.

[Guest7493264]

Now on self compiled linux BETA 12758, everything is still running good.

[Gival]

For me the BeNext sensors are also working again. Thanks for the fix!