Exactly the same way as any other binding. Go to the inbox and start a scan. Without this the devices won’t join the network.
When trying to get these sensors to join, you need to keep pressing the button every 5 seconds or so as they are well known for going to sleep quite quickly. I’ve managed to get them to work ok, but I know others have had trouble - they are temperamental for sure.
Good luck…
Well, that was so obvious I didn’t think of it. Anyway, seems to be alive. I can see the temperature. Thank you.
I have debug turned on and I see some failures and retries. Do I care about ‘ENBER_DELIVERY_FAILED’? Or be happy and turn off the logging?
2018-05-06 15:07:32.138 [DEBUG] [e.ember.internal.ash.AshFrameHandler] - RX EZSP: EzspMessageSentHandler [type=EMBER_OUTGOING_DIRECT, indexOrDestination=55860, apsFrame=EmberApsFrame [profileId=0, clusterId=49, sourceEndpoint=0, destinationEndpoint=0, options=[EMBER_APS_OPTION_ENABLE_ROUTE_DISCOVERY, EMBER_APS_OPTION_ENABLE_ADDRESS_DISCOVERY, EMBER_APS_OPTION_RETRY], groupId=0, sequence=151], messageTag=206, status=EMBER_DELIVERY_FAILED, messageContents=]
2018-05-06 15:07:32.141 [DEBUG] [zigbee.dongle.ember.ZigBeeDongleEzsp] - RX: EzspMessageSentHandler [type=EMBER_OUTGOING_DIRECT, indexOrDestination=55860, apsFrame=EmberApsFrame [profileId=0, clusterId=49, sourceEndpoint=0, destinationEndpoint=0, options=[EMBER_APS_OPTION_ENABLE_ROUTE_DISCOVERY, EMBER_APS_OPTION_ENABLE_ADDRESS_DISCOVERY, EMBER_APS_OPTION_RETRY], groupId=0, sequence=151], messageTag=206, status=EMBER_DELIVERY_FAILED, messageContents=]
2018-05-06 15:07:32.144 [DEBUG] [zigbee.dongle.ember.ZigBeeDongleEzsp] - Unhandled EZSP Frame: EzspMessageSentHandler [type=EMBER_OUTGOING_DIRECT, indexOrDestination=55860, apsFrame=EmberApsFrame [profileId=0, clusterId=49, sourceEndpoint=0, destinationEndpoint=0, options=[EMBER_APS_OPTION_ENABLE_ROUTE_DISCOVERY, EMBER_APS_OPTION_ENABLE_ADDRESS_DISCOVERY, EMBER_APS_OPTION_RETRY], groupId=0, sequence=151], messageTag=206, status=EMBER_DELIVERY_FAILED, messageContents=]
2018-05-06 15:07:32.147 [DEBUG] [e.ember.internal.ash.AshFrameHandler] - --> TX ASH frame: AshFrameAck [ackNum=6, notRdy=false]
Also there a fair number of 'Unhandled EZSP" messages - same question - do I care? Or be happy?
thanks again
Nice one 
.
No - not here anyway. These sensors sleep most of the time and don’t obey the ZigBee recommendations for polling, so we get these failed delivery messages.
Nope - one day I might implement some of these, but they aren’t necessary so you can ignore it…
My success was short lived. The sensor goes offline after about an hour and it never seems to come back online. Until then it is good - I can see pressure, humidity and temperature. If I press its button it gives the longer flash which seems to indicate it is not paired to the network. I can get it to rejoin pretty easily, but then it drops off after an hour.
Is there some secret sauce that the Xiaomi gateway uses to keep them online? Or perhaps I have a defective unit. Or these are just generally unreliable.
No, they are very reliable. But I can’t answer any of your other questions because I’m using the Aqara temperature sensor with the Xiaomi Gateway … 
The problem with these devices is they are not ZigBee compliant, and they don’t tend to work reliably with standard ZigBee systems. Probably Xiaomi manage their devices differently through their gateway - who knows…
Hi Chris,
I guess all Xiaomi / Aqara devices are not 100% compatible to the ZigBee standard.
I have some window / door sensors and I have the same problem, they are offline after about 1h.
I have a Telegesis dongle, and I see a TelegesisDeviceLeftNetworkEvent coming from the dongle after about 1h after the sensors has been discovered.
As a quick hack, I disabled removal of the node when this event is received, and the sensor works well afterwards. Of course the node service discovery runs into a timeout all the time, but basically the sensor still receives updates and is working quite reliable.
I’m not that familar yet with the code, but do you see any chance of setting some devices manually to online and disable online/offline handling completely? I’d love to see that I can simply set the nodes online after pairing.
I can contribute some code, but I need some hints on how something like that can be achieved.
I’d need to think this though pretty carefully - my initial thought would be not to do this as it probably violates security. If the TC says that a device has left the network, then it probably should not be used.
Hi @chris this issue with devices going offline isn’t specific to Xiaomi sensors. I’ve got a Philips Hue Dimmer switch which also leaves the network/goes offline.
Are you sure it’s the same issue? I don’t have any information, and it’s difficult to know the reasons in any case…
There are a lot of reasons that this can happen, and most of them are not something the binding can see as they occur between the TC and the device. If you have information that helps though, please feel free to provide it and I’d be happy to take a look. Probably you would need to sniff the network though as the binding is only alerted once devices leave and join - it doesn’t see the low level communications between the device and the TC or coordinator (or routers).
Unfortunately I don’t have a sniffer so I’ve only got the library/binding logs.
Ok, but if you have anything you can provide to show the problem you’re reporting, it may still be helpful. At least we can see if there was a problem in the binding, or if the device left (or was told to leave by the TC).
Here’s a small snippet from last week where I pressed the ON button on my Hue Dimmer; it then promptly left the network.
2018-05-09 16:02:10.520 [DEBUG] [gesis.internal.TelegesisFrameHandler] - RX Telegesis Data: 52 58 3A 37 46 36 39 2C 30 31 30 34 2C 30 31 2C 30 31 2C 30 30 30 36 2C 30 33 3A 01 09 01 2C 2D 35 36 2C 46 46
2018-05-09 16:02:10.523 [DEBUG] [gesis.internal.TelegesisFrameHandler] - RX Telegesis: TelegesisReceiveMessageEvent [ieeeAddress=null, networkAddress=32617, profileId=260, destinationEp=1, sourceEp=1, clusterId=6, messageData=01 09 01, rssi=-86, lqi=255]
2018-05-09 16:02:10.525 [DEBUG] [tsystems.zigbee.ZigBeeNetworkManager] - RX APS: ZigBeeApsFrame [sourceAddress=32617/1, destinationAddress=0/1, profile=0104, cluster=6, addressMode=null, radius=0, sequence=0, payload=01 09 01]
2018-05-09 16:02:10.526 [DEBUG] [tsystems.zigbee.ZigBeeNetworkManager] - RX ZCL: ZclHeader [frameType=CLUSTER_SPECIFIC_COMMAND, manufacturerSpecific=false, direction=CLIENT_TO_SERVER, disableDefaultResponse=false, manufacturerCode=0, sequenceNumber=9, commandId=1]
2018-05-09 16:02:10.528 [DEBUG] [tsystems.zigbee.ZigBeeNetworkManager] - RX CMD: OnCommand [On/Off: 32617/1 -> 0/1, cluster=0006, TID=09]
2018-05-09 16:02:10.530 [DEBUG] [converter.ZigBeeConverterSwitchOnoff] - 0017880103E47DAF: ZigBee command receiveds OnCommand [On/Off: 32617/1 -> 0/1, cluster=0006, TID=09]
2018-05-09 16:02:10.532 [DEBUG] [gesis.internal.TelegesisFrameHandler] - RX Telegesis Data: 4E 4F 44 45 4C 45 46 54 3A 37 46 36 39 2C 30 30 31 37 38 38 30 31 30 33 45 34 37 44 41 46
2018-05-09 16:02:10.534 [DEBUG] [converter.ZigBeeBaseChannelConverter] - 0017880103E47DAF: Channel zigbee:device:04000BE3:0017880103e47daf:0017880103E47DAF_1_switch_onoff updated to ON
2018-05-09 16:02:10.536 [DEBUG] [gesis.internal.TelegesisFrameHandler] - RX Telegesis: TelegesisDeviceLeftNetworkEvent [networkAddress=32617, ieeeAddress=0017880103E47DAF]
2018-05-09 16:02:10.537 [DEBUG] [ng.zigbee.handler.ZigBeeThingHandler] - 0017880103E47DAF: Updating ZigBee channel state zigbee:device:04000BE3:0017880103e47daf:0017880103E47DAF_1_switch_onoff to ON
2018-05-09 16:02:10.617 [DEBUG] [tsystems.zigbee.ZigBeeNetworkManager] - 0017880103E47DAF: nodeStatusUpdate - node status is DEVICE_LEFT, network address is 32617.
2018-05-09 16:02:10.627 [DEBUG] [tsystems.zigbee.ZigBeeNetworkManager] - 0017880103E47DAF: Node 32617 is removed from the network
2018-05-09 16:02:10.645 [DEBUG] [nal.ZigBeeNetworkStateSerializerImpl] - Saving ZigBee network state: Start.
==> /var/log/openhab2/events.log <==
2018-05-09 16:02:10.648 [me.event.ThingUpdatedEvent] - Thing 'zigbee:device:04000BE3:0017880103e47daf' has been updated.
2018-05-09 16:02:10.654 [hingStatusInfoChangedEvent] - 'zigbee:device:04000BE3:0017880103e47daf' changed from ONLINE to OFFLINE
==> /var/log/openhab2/openhab.log <==
2018-05-09 16:02:10.662 [DEBUG] [nal.ZigBeeNetworkStateSerializerImpl] - Saving ZigBee network state: Done.
Thanks. Interesting - I’m not sure really what is happening though without a sniffer log. I doubt that it’s directly the act of sending a command that caused it to leave the network. Maybe it had already decided to leave (for some reason) and the TC just got the notification that it had left when the coordinator sent the command. I don’t know how to resolve this sort of thing without low level logs as the issue is just between the TC/Coordinator and the device 
.
As I have a spare CC2531, I can try and set it up as a sniffer and see if I can see what’s happening.
With that said, I have no idea what software or process I need to go through to get you some sniffer logs.
@danielwalters86 and @chris
Did you ever got any furter with the problem, which devices going offline?
I tend do have these problems as well, (alsom mentioned in the Zigbee binding thread).
Philips Hue Dimmer switch works for about one day. The it goes offline, and I can´t add it again, unless I remove everything, (device, binding and coordinator). Philips Hue Motion sensor can stay alive a little longer, (2-3 days untill now), and Osram Plug, somewhere in between.
I´m using a Elelabs Rpi shield ZigBee coordinator.
Today I tried to add a Xiaomi door/window sensor. The discovery found a device, but it´s unknown. I have not been able to get past this Unknown status.
The Xiaomi devices are known for this - I’ve seen other threads about this for systems like SmartThings. I don’t believe that they are fully implementing the ZigBee protocol (unless this has changed recently).
I knew the Xiaomi could be difficult. But this door/window sensor seem rather impossible.
Also, I´ve got this problem with the Hue devices. The dimmer switch stops working after one day, and today it seems like the motion sensor has stop as well, though it says it´s online.
This is the third time this happen. I havn´t tested the Osram Plug yet, today. Last night Osram plug worked.
I really could need som advice or some tools to figure out, wether it´s the Elelabs coordinator, or the binding. One thing is for sure, Zigbee is not stable enough to be used. Either it´s due to the devices not beeing fully Zigbee compatble, (whatever that means. How to tell?), or something is wrong with the binding or the coordinator. Debug logging makes no sense to me. It seems like it´s polling every 5 seconds or something. But I don´t see any obvious errors or faults, beside showing nothing, like the devices beeing offline no longer is there, and never has been. It´s a pretty strange behaviour.
The short answer is no - I haven’t tried again recently but as mentioned both the Philips Hue Dimmer and Xiaomi sensors would work for 1-2 hours before going offline.
Probably neither - directly. The coordinator is solely responsible for handling rejoins (along with any routers of course, but it’s the trust centres role to approve rejoins/joins, and this is a coordinator function). One thing you could try is to set the trust centre mode to insecure and see if that helps.