I should add that as best as I can tell, the binding is correctly reporting what the device reports. This comes from the power descriptor - some devices don’t correctly report this descriptor, and some devices I’ve seen don’t report it at all. Maybe if the device doesn’t report the PD then the binding may incorrectly report this - I’d need to check. In any case, the only way to know is to get the debug log during the initialisation.
I’ve looked through the library as well, and if the device doesn’t provide a power descriptor, then the binding should not show these power properties. This all looks fine to me - if you can provide the log I will look further, but my guess is that the device is not properly reporting the power descriptor information.
Note that apart from putting it in the properties this isn’t actually used by the binding or the ZigBee libraries, so it doesn’t matter. If it upsets people I can remove this property?
Sorry, I thought the log I posted on GH was a debug log, but it’s been a while since I posted it…
I just took a look at another battery powered device and there it’s reported correctly. So I think the code is fine. I’d say leave as is, it doesn’t hurt and looks to be correct after all.
It is, but it doesn’t have the initialisation phase in it.
Ok, thanks. It’s also ok here and I suspect that this is “just” poor implementation by some devices.
I guess the question is if it confuses people. We’ve had an extended disucssion about it here and given the number of emails people clearly think there is a problem so I’m tempted to just remove this and avoid the uncertainty that it seems to cause.
It was not due to this upsetting me. It was part of my “investigation” when I tried to add the Tradfri motion sensor. I dont mind non-important misinformations from a device, as long as I know what the truth is., which in this case is quite obvious… It´s a battery device, therefore it cant be main powered 
Ok, maybe “upsets” was the wrong word - possibly “confuses” is a better word to use…
At the end of the day, it’s not really relevant. I’ve tried to provide the information that the devices provide so people have visibility. However sometimes that can just cause confusion - like here where it seems devices don’t provide this information correctly and it might just be easier for everyone not to provide this?
1 Like
haha yeah it’s funny what devices report
power_source: mains on a remote 
but i don’t mind. maybe add an info text stating that this information is provided by devices “as-is” and is often wrong
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 
1 Like
Hopefully not 230volt AC
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.
Okay… So when it´s listed in the docs as working, how is it then suppose to work? 
Ask Chris why he listed it
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
HardwareVersion | 2
modelId | lumi.remote.b1acn01
vendor | LUMI
zigbee_applicationVersion | 2
zigbee_datecode | 20180525
zigbee_device_initialised | true
zigbee_logicaltype | END_DEVICE
zigbee_manufacturercode | 0x1037
zigbee_networkaddress | 23122
zigbee_powerlevel | FULL
zigbee_powermode | RECEIVER_ON_IDLE
zigbee_powersource | DISPOSABLE_BATTERY
zigbee_powersources | [DISPOSABLE_BATTERY]
zigbee_stkversion | 2
zigbee_zclversion | 1
I am using the TI CC2531EMK USB Stick
Thank you - This issue is occuring on two different Xiamo switches
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.
There should be no difference so it should be fine.
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!
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?
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.
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?
1 Like