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.
1 Like
How do I set the trust center mode to insecure? (and what is the trust center?)
Hmmm - I thought I’d checked, but I looked at the wrong coordinator. I’ll need to add this as an option for Ember as it’s only available in the Telegesis at the moment. Sorry - I’ll try and add this in the coming days if I can.
The Trust Centre is a function of the coordinator - it is responsible to allowing devices to join the network or not. It handles all the security, key distribution etc…
No problem.
Ahh I see. I thought it was something inside OpenHab.
This might have solved my issue with the square Xiaomi sensor dropping off the network, and it has 100% fixed the Osram/CentraLite switch cover. What are the security implications though? Can anyone just add things to my mesh without me initiating pairing? And if so, does that actually pose any security issues since I have no intention of adding unknown devices to my Things?
As a quick hack, I disabled removal of the node when this event is received, and the sensor works well afterwards.
How did you do that? Do you still use that solution, or have you found something better? I’m trying to get the Aqara temperature sensor working with a Telegesis stick right now without much luck so far, so I would appreciate any help.
Hi,
Join with ZigBee Ember Coordinator EM357 in logs and device_left in logs.
another logs:
[DEBUG] [internal.ZigBeeNodeServiceDiscoverer] - 00158D0002273DBD: Node SVC Discovery ManagementRoutingRequest returned CommandResult [ERROR (UNKNOWN,0xFF), ManagementRoutingResponse [46444/0 → 0/0, cluster=8032, TID=NULL, status=NOT_SUPPORTED, routingTableEntries=null, startIndex=null, routingTableList=]]
[DEBUG] [zigbee.transaction.ZigBeeTransaction] - Transaction complete: ReadAttributesCommand [Pressure measurement: 0/0 → 46444/1, cluster=0403, TID=78, identifiers=[16]]
[DEBUG] [.zsmartsystems.zigbee.zcl.ZclCluster] - 46444/1: Error reading attribute 16 in cluster 1027 - UNSUPPORTED_ATTRIBUTE
[DEBUG] [e.ember.internal.ash.AshFrameHandler] - → TX ASH frame: AshFrameAck [ackNum=2, notRdy=false]
[DEBUG] [e.ember.internal.ash.AshFrameHandler] - ← RX ASH frame: AshFrameData [frmNum=2, ackNum=5, reTx=false, data=79 90 FF 00 80 42 6C B5]
[DEBUG] [e.ember.internal.ash.AshFrameHandler] - RX EZSP: EzspIncomingRouteErrorHandler [status=EMBER_MAC_INDIRECT_TIMEOUT, target=46444]
[DEBUG] [zigbee.dongle.ember.ZigBeeDongleEzsp] - RX: EzspIncomingRouteErrorHandler [status=EMBER_MAC_INDIRECT_TIMEOUT, target=46444]
[DEBUG] [zigbee.dongle.ember.ZigBeeDongleEzsp] - Unhandled EZSP Frame: EzspIncomingRouteErrorHandler [status=EMBER_MAC_INDIRECT_TIMEOUT, target=46444]
[DEBUG] [e.ember.internal.ash.AshFrameHandler] - → TX ASH frame: AshFrameAck [ackNum=3, notRdy=false]
[DEBUG] [e.ember.internal.ash.AshFrameHandler] - ← RX ASH frame: AshFrameData [frmNum=3, ackNum=5, reTx=false, data=79 90 FF 00 80 42 6C B5]
[DEBUG] [e.ember.internal.ash.AshFrameHandler] - RX EZSP: EzspIncomingRouteErrorHandler [status=EMBER_MAC_INDIRECT_TIMEOUT, target=46444]
[DEBUG] [zigbee.dongle.ember.ZigBeeDongleEzsp] - RX: EzspIncomingRouteErrorHandler [status=EMBER_MAC_INDIRECT_TIMEOUT, target=46444]
[DEBUG] [zigbee.dongle.ember.ZigBeeDongleEzsp] - Unhandled EZSP Frame: EzspIncomingRouteErrorHandler [status=EMBER_MAC_INDIRECT_TIMEOUT, target=46444]
[DEBUG] [e.ember.internal.ash.AshFrameHandler] - → TX ASH frame: AshFrameAck [ackNum=4, notRdy=false]
[DEBUG] [zigbee.transaction.ZigBeeTransaction] - Transaction timeout: BindRequest [0/0 → 46444/0, cluster=0021, TID=79, srcAddress=00158D0002273DBD, srcEndpoint=1, bindCluster=1026, dstAddrMode=3, dstAddress=000D6F000E73123C, dstEndpoint=1]
[DEBUG] [converter.ZigBeeConverterTemperature] - 00158D0002273DBD: Failed to bind temperature measurement cluster
[DEBUG] [.zsmartsystems.zigbee.zcl.ZclCluster] - readSync request: ZclAttribute [cluster=TEMPERATURE_MEASUREMENT, id=0, name=MeasuredValue, dataType=SIGNED_16_BIT_INTEGER, lastValue=2823, lastReportTime=Wed Nov 28 14:03:12 CET 2018]
[DEBUG] [tsystems.zigbee.ZigBeeNetworkManager] - TX CMD: ReadAttributesCommand [Temperature measurement: 0/0 → 46444/1, cluster=0402, TID=7A, identifiers=[0]]
[DEBUG] [tsystems.zigbee.ZigBeeNetworkManager] - TX ZCL: ZclHeader [frameType=ENTIRE_PROFILE_COMMAND, manufacturerSpecific=false, direction=CLIENT_TO_SERVER, disableDefaultResponse=false, manufacturerCode=0, sequenceNumber=122, commandId=0]
[DEBUG] [tsystems.zigbee.ZigBeeNetworkManager] - TX APS: ZigBeeApsFrame [sourceAddress=0/1, destinationAddress=46444/1, profile=0104, cluster=1026, addressMode=DEVICE, radius=31, apsSecurity=false, apsCounter=122, payload=00 7A 00 00 00]
[DEBUG] [zigbee.dongle.ember.ZigBeeDongleEzsp] - EzspSendUnicastRequest [type=EMBER_OUTGOING_DIRECT, indexOrDestination=46444, apsFrame=EmberApsFrame [profileId=260, clusterId=1026, sourceEndpoint=1, destinationEndpoint=1, options=[EMBER_APS_OPTION_RETRY, EMBER_APS_OPTION_ENABLE_ROUTE_DISCOVERY, EMBER_APS_OPTION_ENABLE_ADDRESS_DISCOVERY], groupId=0, sequence=122], messageTag=122, messageContents=00 7A 00 00 00]
[DEBUG] [e.ember.internal.ash.AshFrameHandler] - → TX ASH frame: AshFrameAck [ackNum=7, notRdy=false]
[DEBUG] [e.ember.internal.ash.AshFrameHandler] - ← RX ASH frame: AshFrameData [frmNum=7, ackNum=2, reTx=false, data=7E 90 FF 00 80 42 6C B5]
[DEBUG] [e.ember.internal.ash.AshFrameHandler] - RX EZSP: EzspIncomingRouteErrorHandler [status=EMBER_MAC_INDIRECT_TIMEOUT, target=46444]
[DEBUG] [zigbee.dongle.ember.ZigBeeDongleEzsp] - RX: EzspIncomingRouteErrorHandler [status=EMBER_MAC_INDIRECT_TIMEOUT, target=46444]
[DEBUG] [zigbee.dongle.ember.ZigBeeDongleEzsp] - Unhandled EZSP Frame: EzspIncomingRouteErrorHandler [status=EMBER_MAC_INDIRECT_TIMEOUT, target=46444]
[DEBUG] [e.ember.internal.ash.AshFrameHandler] - → TX ASH frame: AshFrameAck [ackNum=0, notRdy=false]
[DEBUG] [e.ember.internal.ash.AshFrameHandler] - ← RX ASH frame: AshFrameData [frmNum=0, ackNum=2, reTx=false, data=7E 90 FF 00 80 42 6C B5]
[DEBUG] [e.ember.internal.ash.AshFrameHandler] - RX EZSP: EzspIncomingRouteErrorHandler [status=EMBER_MAC_INDIRECT_TIMEOUT, target=46444]
[DEBUG] [zigbee.dongle.ember.ZigBeeDongleEzsp] - RX: EzspIncomingRouteErrorHandler [status=EMBER_MAC_INDIRECT_TIMEOUT, target=46444]
[DEBUG] [zigbee.dongle.ember.ZigBeeDongleEzsp] - Unhandled EZSP Frame: EzspIncomingRouteErrorHandler [status=EMBER_MAC_INDIRECT_TIMEOUT, target=46444]
[DEBUG] [e.ember.internal.ash.AshFrameHandler] - → TX ASH frame: AshFrameAck [ackNum=1, notRdy=false]
[DEBUG] [zigbee.transaction.ZigBeeTransaction] - Transaction timeout: ManagementBindRequest [0/0 → 46444/0, cluster=0033, TID=7E, startIndex=0]
[DEBUG] [ng.zigbee.handler.ZigBeeThingHandler] - 00158D0002273DBD: Error getting binding table
[DEBUG] [ng.zigbee.handler.ZigBeeThingHandler] - 00158D0002273DBD: Polling initialised at 7322179ms
[DEBUG] [ng.zigbee.handler.ZigBeeThingHandler] - 00158D0002273DBD: Done initialising ZigBee Thing handler
[DEBUG] [nal.ZigBeeNetworkStateSerializerImpl] - Saving ZigBee network state: Start.
[DEBUG] [nal.ZigBeeNetworkStateSerializerImpl] - Saving ZigBee network state: Done.
device_join.log (68.2 KB)
device_left.log (12.7 KB)
Have you guys tried Xiaomi Mija sensors or does it work only for Aqara sensors?