Zigbee binding

Kim_Andersen · April 6, 2020, 11:57am

Indeed it did confuse me… Since I´m just a simple user of Zigbee, every part I see which can be an reason for a device not working, will somehow be mixed together…
In short - When I saw the device didn´t have a occupancy channel, and the powersource was obivously wrong. I assumed something general have gone wrong, even though those two matter doesnt really belong together.

I agree, if there is a general problem with devices not reporting the correct information, and this information really isnt important… It´s better to remove the reporting. The user should know, wether a device is mains power or battery powered… If not, then the user got other serious problems

Kim_Andersen · April 6, 2020, 11:59am

Hopefully not 230volt AC

AFromD · April 15, 2020, 9:17am

The thing with the Tradfri sensor is that it doesn’t really want to work with a routed network. It works like a remote, you bind it to a lamp and it will issue a switch command according to occupancy. It doesn’t let the network know what it is doing. What would be needed is some kind of emulated lamp within the binding that it could address.

Kim_Andersen · April 15, 2020, 9:53am

Okay… So when it´s listed in the docs as working, how is it then suppose to work?

AFromD · April 15, 2020, 10:20am

Ask Chris why he listed it

JackBrad · April 23, 2020, 12:09pm

Hi All,

Has anyone been able to get this Xiamo switch working (Aqara Wireless Mini Switch WXKG11LM - https://www.aqara.com/en/smart_wireless_mini_switch.html).

I can connect the device but is showing the following below and doesnt create a channel.

OFFLINE - HANDLER_INITIALIZING_ERROR No supported clusters found

I am using the TI CC2531EMK USB Stick

Thank you - This issue is occuring on two different Xiamo switches

mrfrh · April 23, 2020, 5:36pm

I can confirm that WXKG11LM works with the following combinations:

Zigbee Binding, CC2531 and Openhab 2.5.0 M3.
Zigbee Binding, BitronVideo Dongle and Openhab 2.5.0 M2

Unfortunately, I don’t know whether it works with the current release 2.5.4.

chris · April 23, 2020, 5:55pm

There should be no difference so it should be fine.

JackBrad · April 23, 2020, 6:13pm

Thank you @mrfrh, good to know that it can work.

I will keep at it

Kim_Andersen · April 29, 2020, 3:01pm

Had a coupple of hours to kill today. So I sat down and upgraded my openhab “test” setup from 2.5.3 to 2.5.4.
This setup is very simple. Its a Odroid C2 running Ubuntu and openhab, with Zigbee and Velbus bindings activated. Thats it.

Zigbee devices are:
Philips Hue motion sensor
Philips Hue Switch
Xiaomi Mija Motion sensor
Trust Motion sensor.
Osram plug outlet.
Traadfri motion sensor (not running as it has been confirmed it doest work with the binding).

I previously gave up on Zigbee a few times. But I decided to test Zigbee binding each time I have upgraded this openhab system. Just to see if there will be any differences.

Previous symptoms has been:
Most devices stopped working after a few hours or within a coupple of days all by themselves. Those devices who may still be running maybe for a few days, the first restart of openhab will kill them for sure. Thats the most typical scenarie.
Notice - I do NOT do any changes to this system. When all things/devices are up running, I just leave it running by itself.

Today I wanted to try something new. After successfull upgrade of openhab and system files to openhab 2.5.4 I started to clean up the system.
First I deleted all Zigbee devices, and reset them as well (all except the Hue motion sensor were offline anyway).
Then I edited the setup of my EMBER coordinator to use channel 15 - Thats the new part.
Then I started adding the Zigbee devices one by one again, except the Osram Plug. Reason is, this Osram plug had previously been the first device to stop responding most of the time. This time I wanted to see what happened, if I dont add it.

After adding all the devices successfully, they all seemed to work and responded fine. Thats not abnormal.
After quite a few minutes where I made sure all devices were running and responding, it was time to do the fatal “restart openhab test”.

Status result after restart:
Philips Hue motion sensor:
It came online fine, but does not respond at all. After ½ hour beeing online, it changed to offline
Philips Hue Switch:
It came online, respond fine
Xiaomi Mija motion sensor:
It came online, respond fine
Trust motion sensor:
It finally came online after quite a few minutes. At first it didnt respond, but after a few more minutes it started responding. At the time writing, it´s still responding.

Its a surprise to see the Philips Hue motion sensor failed. Normally this device is the only one which continues to work when the others fails/have turned offline…

Lets see how long it last for the other devices this time. I do not hold my breath to be honest! What I see this time I have seen many times before (except for the Hue motion sensor failing). My bet is they will all stop working within the next 1-2 days. If not, I´ll redo the fatal “restart openhab test” to see who will survive. Stay tuned!

portboy · April 29, 2020, 8:19pm

My zigbee coordinator loose the connection to my thing after restart of OH or just restart the binding.

I’m using OH 2.5.2
My thing is a Danalock V3
It is the only thing in my zigbee network. I am testing if it is more stable as zigbee2mqtt.

Ok, I can connect the Danalock very easy.
However, during the first connection I can see this error in the Karaf Console.

[ERROR] [2531.network.packet.ZToolPacketStream] - Packet parsing failed due to exception.
com.zsmartsystems.zigbee.dongle.cc2531.network.packet.ZToolParseException: Packet checksum failed
        at com.zsmartsystems.zigbee.dongle.cc2531.network.packet.ZToolPacketStream.parsePacket(ZToolPacketStream.java:141) [bundleFile:?]
        at com.zsmartsystems.zigbee.dongle.cc2531.network.packet.ZToolPacketParser.run(ZToolPacketParser.java:107) [bundleFile:?]
        at java.lang.Thread.run(Thread.java:748) [?:1.8.0_232]

However, the thing/Danalock works as expected.
But If I do a restart of OH or just the binding, the thing go lost (gone).
In the Karaf I see the following details during a restart of the binding zigbee ( bundle:restart org.openhab.binding.zigbee):

21:55:44.738 [INFO ] [ome.event.ThingStatusInfoChangedEvent] - 'zigbee:device:stick1:xxxxxxxxxxxxx' changed from ONLINE to UNINITIALIZED
21:55:44.743 [INFO ] [ome.event.ThingStatusInfoChangedEvent] - 'zigbee:device:stick1:xxxxxxxxxxxxx' changed from UNINITIALIZED to UNINITIALIZED (HANDLER_MISSING_ERROR)
21:55:44.762 [INFO ] [ome.event.ThingStatusInfoChangedEvent] - 'zigbee:coordinator_cc2531:stick1' changed from ONLINE to UNINITIALIZED
21:55:49.766 [WARN ] [.core.thing.internal.ThingManagerImpl] - Disposing handler for thing 'zigbee:coordinator_cc2531:stick1' takes more than 5000ms.
21:55:49.770 [INFO ] [ome.event.ThingStatusInfoChangedEvent] - 'zigbee:coordinator_cc2531:stick1' changed from UNINITIALIZED to UNINITIALIZED (HANDLER_MISSING_ERROR)
21:55:49.798 [INFO ] [ome.event.ThingStatusInfoChangedEvent] - 'zigbee:device:stick1:xxxxxxxxxxxxx' changed from UNINITIALIZED (HANDLER_MISSING_ERROR) to UNINITIALIZED                                                                   (BRIDGE_UNINITIALIZED)
21:55:49.821 [INFO ] [ome.event.ThingStatusInfoChangedEvent] - 'zigbee:coordinator_cc2531:stick1' changed from UNINITIALIZED (HANDLER_MISSING_ERROR) to INITIALIZING
21:55:49.824 [INFO ] [ome.event.ThingStatusInfoChangedEvent] - 'zigbee:coordinator_cc2531:stick1' changed from INITIALIZING to UNKNOWN
21:55:49.827 [INFO ] [ome.event.ThingStatusInfoChangedEvent] - 'zigbee:device:stick1:xxxxxxxxxxxxx' changed from UNINITIALIZED (BRIDGE_UNINITIALIZED) to INITIALIZING
21:55:49.831 [INFO ] [ome.event.ThingStatusInfoChangedEvent] - 'zigbee:device:stick1:xxxxxxxxxxxxx' changed from INITIALIZING to UNKNOWN
21:55:49.836 [INFO ] [smarthome.event.ThingUpdatedEvent    ] - Thing 'zigbee:coordinator_cc2531:stick1' has been updated.
21:55:49.836 [INFO ] [smarthome.event.ThingUpdatedEvent    ] - Thing 'zigbee:coordinator_cc2531:stick1' has been updated.
21:55:49.838 [INFO ] [smarthome.event.ThingUpdatedEvent    ] - Thing 'zigbee:coordinator_cc2531:stick1' has been updated.
21:55:49.839 [INFO ] [smarthome.event.ThingUpdatedEvent    ] - Thing 'zigbee:coordinator_cc2531:stick1' has been updated.
21:55:49.839 [INFO ] [smarthome.event.ThingUpdatedEvent    ] - Thing 'zigbee:coordinator_cc2531:stick1' has been updated.
21:55:52.046 [INFO ] [smarthome.event.ThingUpdatedEvent    ] - Thing 'zigbee:coordinator_cc2531:stick1' has been updated.
21:55:56.924 [INFO ] [smarthome.event.ThingUpdatedEvent    ] - Thing 'zigbee:coordinator_cc2531:stick1' has been updated.
21:55:56.927 [INFO ] [smarthome.event.ThingUpdatedEvent    ] - Thing 'zigbee:coordinator_cc2531:stick1' has been updated.
21:55:56.927 [INFO ] [ome.event.ThingStatusInfoChangedEvent] - 'zigbee:coordinator_cc2531:stick1' changed from UNKNOWN to ONLINE
21:55:56.939 [INFO ] [ome.event.ThingStatusInfoChangedEvent] - 'zigbee:device:stick1:xxxxxxxxxxxxx' changed from UNKNOWN to OFFLINE (GONE): Node is not found on network

Has anyone a hint what I can do to resolve this issue?

Kim_Andersen · May 1, 2020, 9:35am

Just a short status on the above “new experiment”… after 2 days running.

Things are still running, Trust sensor, (big surprise), Lumi Sensor and Hue Switch. System has not been restarted yet.
The Philips Hue motion sensor never came back online again, so I´ll remove it in a few minutes and add it again… If it comes online and stays online for more than 1 hour. I´ll do a new restart of openhab later today. Then we´ll see what will happen from there.

Stay tuned!

EDIT yet another day - The Philips Hue motion sensor continued to work after beeing added yesterday. I didnt restart the system yesterday as written above, but I did it just a few minutes ago insted.
Result - All devices came online fine and responding fine as well… That very unusual, but also very good news.
I´ll leave it running for now to see if they continue. If they all runs fine tomorrow, I will probably try add the Osram outlet plug, just to see if that will do any changes.

ndasyras · May 2, 2020, 4:53pm

Hi,
It seems that there are two kinds of Zigbee Aqara Wireless Mini Switches, both labeled on the box as WXKG11LM. The ones that are discovered as lumi.sensor_switch.aq2 , I can confirm that work fine with release 2.4 and 2.5.4 . The ones discovered as lumi.remote.b1acn01 did not work in release 2.4 and in release 2.5.4 have the behavior that @JackBrad reports.
@mrfrh Could you please check which kind are the ones working for you and post an update?

mrfrh · May 2, 2020, 5:21pm

The one that I have working is a “lumi.sensor_switch.aq2”. I bought it around ~09/2019.

NilsOF · May 3, 2020, 6:02am

My Aqara button:

OFFLINE - HANDLER_INITIALIZING_ERROR No supported clusters found
modelId | lumi.remote.b1acn01

My thinking is not to buy any more Aqara/Lumi stuff until they put zigbee logos on the boxes.

JackBrad · May 4, 2020, 11:55pm

Hi All,

There are two versions of the Xiaomi Switch - WXKG11LM, having looked at the github binding, only the 2016 version appears to be supported (link at the end).

@chris could you please add the 2018 model. My github/coding skills are lacking so i wouldnt know where to begin. I would be happy to compensate you with a beer!

WXKG11LM

2016 - lumi.sensor_switch.aq2

2018 - lumi.remote.b1acn01

Button events for the 2016 version “lumi.sensor_switch.aq2”

Event Action

1002 single short press

1004 double short press

1005 triple short press

1006 quad short press

Button events for the 2018 version “lumi.remote.b1acn01”

Event Action

1002 single press

1004 double press

1001 hold

1003 hold release

Zigbee binding supported items (org.openhab.binding.zigbee/src/main/resources/discovery.txt)

philips_sml001,vendor=Philips,modelId=SML001

philips_rwl021,vendor=Philips,modelId=RWL021

smartthings_motionv4,vendor=SmartThings,modelId=motionv4

bitron-video-902010-23,vendor=Bitron Home,modelId=902010/23

bitron-video-av2010-34,vendor=Bitron Video,modelId=AV2010/34

xiaomi_lumisensorht,modelId=lumi.sensor_ht

xiaomi_lumisensor-motion,modelId=lumi.sensor_motion

xiaomi_lumiremoteb286acn01,modelId=lumi.remote.b286acn01

xiaomi_lumisensor86sw2,modelId=lumi.sensor_86sw2

xiaomi_lumisensor-switchaq2,modelId=lumi.sensor_switch.aq2

xiaomi_lumisensorwaterleak,modelId=lumi.sensor_wleak.aq1

innr-rc-110,vendor=innr,modelId=RC 110

osram-switch-4x-eu,vendor=OSRAM,modelId=Switch 4x EU-LIGHTIFY

Thank you

chris · May 5, 2020, 8:14am

I’m not sure what these events are? Presumably there is an attribute associated with them? If I look at the old switch, there is also no handling of these events, so my guess is that they are using something standard and the binding is detecting them.

Do you have a log showing these events being received - or further documentation on what the definition of these events are?

Benjy · May 5, 2020, 11:35am

On a related note (would you prefer new threads for slightly differing issues?)

I had a Lumi Aqara wallswitch remote (WXKG02LM) which I decided to give a go today, it’s on the list of supported items but this might be the same remote named for a different version:

xiaomi_lumiremoteb286acn01,modelId=lumi.remote.b286acn01

I paired it sucessfully after a large number of attempts, and got the correct channels come through:

However only the Range check channel works (tap either button 5 times). It comes up on ClusterID 0:

TelegesisRouteRecordMessageEvent [hops=2, remoteAddress=00158D00040B101C, networkRoute=[42987, 40362, 27506]]
TelegesisReceiveMessageEvent [ieeeAddress=null, networkAddress=42987, profileId=260, destinationEp=1, sourceEp=1, clusterId=0, messageData=18 38 0A 05 00 42 15 6C 75 6D 69 2E 72 65 6D 6F 74 65 2E 62 32 38 36 61 63 6E 30 31, rssi=-69, lqi=255]

The other two come up on ClusterID 18, which I suspect is non standard:

Action	DestinationEP	SourceEP	ClusterID	MessageData
Left Single Press	1	1	18	18 3A 0A 55 00 21 01 00
Left Double Press	1	1	18	18 3B 0A 55 00 21 02 00
Left Long Press	1	1	18	18 3C 0A 55 00 21 00 00
Right Single Press	1	2	18	18 3D 0A 55 00 21 01 00
Right Double Press	1	2	18	18 3E 0A 55 00 21 02 00
Right Long Press	1	2	18	18 3F 0A 55 00 21 00 00

That second byte in the message data seems to be a counter shared between all buttons i.e. the next command would be 0x40 etc.

@chris, do you know if this is different to other devices of the same type? How best to proceed (if possible/plausible) to support it?

chris · May 5, 2020, 11:53am

Unfortunately you’re looking across multiple layers here. The log would have broken them out better.

I’m not familiar with any of these devices, but from a quick look at the definition it is correct as per the bindings definition. Can you provide a log please?

Benjy · May 5, 2020, 12:07pm

Thanks Chris,

This a debug log (org.openhab.binding.zigbee and com.zsmartsystems.zigbee) capturing the button presses left single press, left double press and left long press, followed by the same for right, and then both buttons at the same time (sourceEP becomes 3, but there is no channel for this yet).

openhab-zigbee.log (16.1 KB)

Event	Action
1002	single short press
1004	double short press
1005	triple short press
1006	quad short press