Zigbee binding

chris · December 21, 2018, 10:09pm

Sorry - I missed that…

I can’t really explain it - by which I mean I can’t see where the change was made. However, the attribute was changed at some point from “Total Active Power” to “Active Power”.

2.3 -:

2018-12-20 18:43:53.147 [DEBUG] [tsystems.zigbee.ZigBeeNetworkManager] - RX CMD: ReadAttributesResponse [Electrical Measurement: 57472/1 -> 0/1, cluster=0B04, TID=D1, records=[ReadAttributeStatusRecord [attributeDataType=SIGNED_16_BIT_INTEGER, attributeIdentifier=1291, status=SUCCESS, attributeValue=19]]]

public static final int ATTR_ACTIVEPOWER = 0x050B;

2.4 -:

2018-12-18 08:00:34.326 [DEBUG] [tsystems.zigbee.ZigBeeNetworkManager] - RX CMD: ReadAttributesResponse [Electrical Measurement: 3969/1 -> 0/1, cluster=0B04, TID=F5, records=[ReadAttributeStatusRecord [attributeDataType=null, attributeIdentifier=772, status=UNSUPPORTED_ATTRIBUTE, attributeValue=null]]]

public static final int ATTR_TOTALACTIVEPOWER = 0x0304;

I can’t find anywhere that this was changed, but clearly something did somewhere. With the previous version - was that the 2.3 release or something else?

chris · December 21, 2018, 10:51pm

I’m a bit confused by these logs… The link appears to be the same as the one from 2.3 - have the two been overwritten or something?

WeRo · December 21, 2018, 11:23pm

Still need some help:
I uninstalled the ZigBee Binding.
I deleted all ZigBee items in the jsondb files.
I installed new bindings by zzManualInstall.sh.
I added the dongle and the power outlets as new items.
In Paper UI everything is shown as up and running but the switches still don’t work!!
=> Error 0xffff setting server binding (see OpenHAB-Log)

These jar files are part of the addons folder:
com.zsmartsystems.zigbee-1.1.6.jar
com.zsmartsystems.zigbee.dongle.telegesis-1.1.7.jar
org.openhab.binding.zigbee-2.5.0-SNAPSHOT.jar
org.openhab.binding.zigbee.telegesis-2.5.0-SNAPSHOT.jar

Openhab-Log (after restart of openhab):

2018-12-21 23:49:16.525 [INFO ] [bee.discovery.ZigBeeDiscoveryService] - 84182600000EE4C8: Starting ZigBee device discovery
2018-12-21 23:49:16.529 [INFO ] [bee.discovery.ZigBeeDiscoveryService] - 7CB03EAA00AD4F4A: Starting ZigBee device discovery
2018-12-21 23:49:16.529 [INFO ] [bee.discovery.ZigBeeDiscoveryService] - 7CB03EAA00ACED53: Starting ZigBee device discovery
2018-12-21 23:49:16.530 [INFO ] [bee.discovery.ZigBeeDiscoveryService] - 7CB03EAA00AD0AC2: Starting ZigBee device discovery
2018-12-21 23:49:24.560 [INFO ] [bee.discovery.ZigBeeDiscoveryService] - 7CB03EAA00AD0AC2: Starting ZigBee device discovery
2018-12-21 23:49:25.271 [INFO ] [bee.discovery.ZigBeeDiscoveryService] - 84182600000EE4C8: Starting ZigBee device discovery
2018-12-21 23:49:27.055 [INFO ] [bee.discovery.ZigBeeDiscoveryService] - 7CB03EAA00ACED53: Starting ZigBee device discovery
2018-12-21 23:49:27.593 [INFO ] [bee.discovery.ZigBeeDiscoveryService] - 7CB03EAA00AD4F4A: Starting ZigBee device discovery
2018-12-21 23:49:46.630 [ERROR] [converter.ZigBeeConverterSwitchOnoff] - 84182600000EE4C8: Error 0xffff setting server binding
2018-12-21 23:49:46.880 [ERROR] [converter.ZigBeeConverterSwitchOnoff] - 7CB03EAA00ACED53: Error 0xffff setting server binding
2018-12-21 23:49:47.132 [ERROR] [converter.ZigBeeConverterSwitchOnoff] - 7CB03EAA00AD0AC2: Error 0xffff setting server binding
2018-12-21 23:49:51.369 [ERROR] [converter.ZigBeeConverterSwitchOnoff] - 7CB03EAA00AD4F4A: Error 0xffff setting server binding

Event-Log (after restart of openhab)

2018-12-21 23:49:25.366 [me.event.ThingUpdatedEvent] - Thing ‘zigbee:device:000001A5:84182600000ee4c8’ has been updated.
2018-12-21 23:49:25.577 [me.event.ThingUpdatedEvent] - Thing ‘zigbee:device:000001A5:7cb03eaa00ad0ac2’ has been updated.
2018-12-21 23:49:26.899 [me.event.ThingUpdatedEvent] - Thing ‘zigbee:device:000001A5:7cb03eaa00aced53’ has been updated.
2018-12-21 23:49:34.888 [me.event.ThingUpdatedEvent] - Thing ‘zigbee:device:000001A5:7cb03eaa00ad4f4a’ has been updated.
2018-12-21 23:49:47.581 [hingStatusInfoChangedEvent] - ‘zigbee:device:000001A5:84182600000ee4c8’ changed from UNKNOWN to ONLINE
2018-12-21 23:49:47.700 [me.event.ThingUpdatedEvent] - Thing ‘zigbee:device:000001A5:84182600000ee4c8’ has been updated.
2018-12-21 23:49:48.070 [hingStatusInfoChangedEvent] - ‘zigbee:device:000001A5:7cb03eaa00aced53’ changed from UNKNOWN to ONLINE
2018-12-21 23:49:48.308 [me.event.ThingUpdatedEvent] - Thing ‘zigbee:device:000001A5:7cb03eaa00aced53’ has been updated.
2018-12-21 23:49:48.330 [hingStatusInfoChangedEvent] - ‘zigbee:device:000001A5:7cb03eaa00ad0ac2’ changed from UNKNOWN to ONLINE
2018-12-21 23:49:48.483 [me.event.ThingUpdatedEvent] - Thing ‘zigbee:device:000001A5:7cb03eaa00ad0ac2’ has been updated.
2018-12-21 23:49:51.995 [hingStatusInfoChangedEvent] - ‘zigbee:device:000001A5:7cb03eaa00ad4f4a’ changed from UNKNOWN to ONLINE

Fredrik_Andersson · December 22, 2018, 7:44am

Hey guys. I have read most of this thread, and that made me buy a compatible usb stick. (EZBUSBA, Elelabs based on EM358 SiLabs chip) I’m having some issues with my Xiaomi sensors. Seems like my Aqara sensors (lumi.weather) are dropping of the network after an hour or so. I saw this was mentioned briefly here but I didnt find/understand a solution for this? I didnt get a battery value either, is this a work in progress?
Just tell me if I can do something to help, im not having any sniffers or something but im running openhab 2.4 (stable) in docker on a rpi3.

EDIT: Uploaded a log from openhab.log with debug info. Paring , some button presses with aqara button. Then after a few minutes something happens. The log reads “device left” i saw. It’s the only device paried with my stick.

11:38:20.654	50010	
RX -- DeviceAnnounce nwkAddrOfInterest=50010 ieeeAddr=00158D0001A66806 RFD ADDRESS
11:38:20.685	50010	
RX 00 ReportAttributesCommand cluster=BASIC
11:38:20.870	50010	
RX 01 ReportAttributesCommand cluster=BASIC
11:38:21.000	50010	
TX B0 NodeDescriptorRequest
11:38:21.700	50010	
RX -- NodeDescriptorResponse status=SUCCESS
11:38:21.709	50010	
TX B3 NodeDescriptorRequest
11:38:22.036	50010	
TX B5 ActiveEndpointsRequest
11:38:23.316	50010	
RX 02 ReportAttributesCommand cluster=BASIC
11:38:23.626	50010	
RX -- NodeDescriptorResponse status=SUCCESS
11:38:23.644	50010	
TX B6 ActiveEndpointsRequest
11:38:23.837	50010	
RX -- ActiveEndpointsResponse status=SUCCESS activeEpList=[1]
11:38:23.856	50010	
TX B7 SimpleDescriptorRequest endpoint=1
11:38:23.859	50010	
TX B8 SimpleDescriptorRequest endpoint=1
11:38:25.820	50010	
RX 00 ReportAttributesCommand cluster=BASIC
11:38:29.532	50010	
RX 01 ReportAttributesCommand cluster=BASIC
11:38:29.835	50010	
RX -- SimpleDescriptorResponse status=SUCCESS endpoint=1 profileId=HOME AUTOMATION deviceId=24321 inputClusterList=[BASIC, 65535,ON_OFF] outputClusterList=[BASIC,GROUPS, 65535]]
11:38:29.882	50010	
TX B9 ManagementLqiRequest startIndex=0
11:38:29.904	50010	
TX BA ManagementLqiRequest startIndex=0
11:38:33.373	50010	
RX 02 ReportAttributesCommand cluster=BASIC
11:38:33.685	50010	
RX -- ManagementLqiResponse status=SUCCESS neighborTableEntries=5 startIndex=0
11:38:33.696	50010	
TX BB ManagementLqiRequest startIndex=1
11:38:33.699	50010	
TX BC ManagementLqiRequest startIndex=1
11:38:35.972	50010	
RX 03 ReportAttributesCommand cluster=BASIC
11:38:36.270	50010	
RX -- ManagementLqiResponse status=SUCCESS neighborTableEntries=5 startIndex=1
11:38:36.300	50010	
TX BD PowerDescriptorRequest
11:38:36.304	50010	
TX BE PowerDescriptorRequest
11:38:38.536	50010	
RX 04 ReportAttributesCommand cluster=BASIC
11:38:38.849	50010	
RX -- PowerDescriptorResponse status=SUCCESS
11:38:38.866	50010	
TX BF ManagementRoutingRequest startIndex=0
11:38:38.869	50010	
TX C0 ManagementRoutingRequest startIndex=0
11:38:40.341	50010	
RX 05 ReportAttributesCommand cluster=BASIC
11:38:40.645	50010	
RX -- ManagementRoutingResponse status=NOT_SUPPORTED
11:38:40.739	50010	
TX C1 ReadAttributesCommand cluster=BASIC identifiers=[4]
11:38:42.087	50010	
RX 06 ReportAttributesCommand cluster=BASIC
11:38:42.407	50010	
RX C1 ReadAttributesResponse cluster=BASIC
11:38:42.417	50010	
TX C2 ReadAttributesCommand cluster=BASIC identifiers=[3]
11:38:43.905	50010	
RX 07 ReportAttributesCommand cluster=BASIC
11:38:44.200	50010	
RX C2 ReadAttributesResponse cluster=BASIC
11:38:44.206	50010	
TX C3 ReadAttributesCommand cluster=BASIC identifiers=[2]
11:38:45.358	50010	
RX 08 ReportAttributesCommand cluster=BASIC
11:38:45.674	50010	
RX C3 ReadAttributesResponse cluster=BASIC
11:38:45.684	50010	
TX C4 ReadAttributesCommand cluster=BASIC identifiers=[0]
11:38:47.158	50010	
RX 09 ReportAttributesCommand cluster=BASIC
11:38:47.468	50010	
RX C4 ReadAttributesResponse cluster=BASIC
11:38:47.477	50010	
TX C5 ReadAttributesCommand cluster=BASIC identifiers=[6]
11:38:49.109	50010	
RX 0A ReportAttributesCommand cluster=BASIC
11:38:49.420	50010	
RX C5 ReadAttributesResponse cluster=BASIC
11:39:44.751	50010	
TX C7 BindRequest bindCluster=6 srcAddress=00158D0001A66806 srcEndpoint=1 dstAddress=000D6F0012EA8781 dstEndpoint=1
11:39:44.918	50010	
TX C8 IeeeAddressRequest nwkAddrOfInterest=50010 requestType=1 startIndex=0
11:39:47.084	50010	
RX -- BindResponse status=SUCCESS
11:39:52.751	50010	
TIMEOUT C7 BindRequest bindCluster=6 srcAddress=00158D0001A66806 srcEndpoint=1 dstAddress=000D6F0012EA8781 dstEndpoint=1
11:39:52.759	50010	
TX C9 ReadAttributesCommand cluster=ON_OFF identifiers=[0]
11:39:52.919	50010	
TIMEOUT C8 IeeeAddressRequest nwkAddrOfInterest=50010 requestType=1 startIndex=0
11:39:54.423	50010	
TX CA IeeeAddressRequest nwkAddrOfInterest=50010 requestType=1 startIndex=0
11:40:00.760	50010	
TIMEOUT C9 ReadAttributesCommand cluster=ON_OFF identifiers=[0]
11:40:00.771	50010	
TX CB ManagementBindRequest startIndex=0
11:40:02.423	50010	
TIMEOUT CA IeeeAddressRequest nwkAddrOfInterest=50010 requestType=1 startIndex=0
11:40:03.929	50010	
TX CC IeeeAddressRequest nwkAddrOfInterest=50010 requestType=1 startIndex=0
11:40:08.770	50010	
TIMEOUT CB ManagementBindRequest startIndex=0
11:40:11.929	50010	
TIMEOUT CC IeeeAddressRequest nwkAddrOfInterest=50010 requestType=1 startIndex=0
11:40:13.434	50010	
TX CD IeeeAddressRequest nwkAddrOfInterest=50010 requestType=1 startIndex=0
11:40:20.373	50010	
RX 0B ReportAttributesCommand cluster=ON_OFF
11:40:20.386		
STATE UPDATE zigbee:device:789dda81:00158d0001a66806:00158D0001A66806_1_switch ON
11:40:20.386		
STATE UPDATE zigbee:device:789dda81:00158d0001a66806:00158D0001A66806_1_switch ON
11:40:21.435	50010	
TIMEOUT CD IeeeAddressRequest nwkAddrOfInterest=50010 requestType=1 startIndex=0
11:40:27.443	50010	
RX 0C ReportAttributesCommand cluster=ON_OFF
11:40:27.453		
STATE UPDATE zigbee:device:789dda81:00158d0001a66806:00158D0001A66806_1_switch ON
11:40:27.453		
STATE UPDATE zigbee:device:789dda81:00158d0001a66806:00158D0001A66806_1_switch ON
11:40:32.393	50010	
RX 0D ReportAttributesCommand cluster=ON_OFF
11:40:32.405		
STATE UPDATE zigbee:device:789dda81:00158d0001a66806:00158D0001A66806_1_switch ON
11:40:32.406		
STATE UPDATE zigbee:device:789dda81:00158d0001a66806:00158D0001A66806_1_switch ON
11:40:34.345	50010	
RX 0E ReportAttributesCommand cluster=ON_OFF
11:40:34.355		
STATE UPDATE zigbee:device:789dda81:00158d0001a66806:00158D0001A66806_1_switch ON
11:40:34.358		
STATE UPDATE zigbee:device:789dda81:00158d0001a66806:00158D0001A66806_1_switch ON
11:40:40.932	50010	
TX CE ReadAttributesCommand cluster=ON_OFF identifiers=[0]
11:40:47.262	50010	
RX 0F ReportAttributesCommand cluster=ON_OFF
11:40:47.282		
STATE UPDATE zigbee:device:789dda81:00158d0001a66806:00158D0001A66806_1_switch ON
11:40:47.287		
STATE UPDATE zigbee:device:789dda81:00158d0001a66806:00158D0001A66806_1_switch ON
11:40:48.932	50010	
TIMEOUT CE ReadAttributesCommand cluster=ON_OFF identifiers=[0]
11:40:50.578	50010	
RX CE ReadAttributesResponse cluster=ON_OFF
11:41:08.388	50010	
RX 10 ReportAttributesCommand cluster=BASIC
11:41:17.440	50010	
RX 11 ReportAttributesCommand cluster=BASIC
11:41:28.400	50010	
RX 12 ReportAttributesCommand cluster=ON_OFF
11:41:28.409		
STATE UPDATE zigbee:device:789dda81:00158d0001a66806:00158D0001A66806_1_switch ON
11:41:28.409		
STATE UPDATE zigbee:device:789dda81:00158d0001a66806:00158D0001A66806_1_switch ON
11:41:43.945	50010	
TX CF ReadAttributesCommand cluster=ON_OFF identifiers=[0]
11:41:51.946	50010	
TIMEOUT CF ReadAttributesCommand cluster=ON_OFF identifiers=[0]
11:42:46.963	50010	
TX D0 ReadAttributesCommand cluster=ON_OFF identifiers=[0]
11:42:54.963	50010	
TIMEOUT D0 ReadAttributesCommand cluster=ON_OFF identifiers=[0]
11:43:20.862	50010	
TX D1 ManagementLqiRequest startIndex=0
11:43:28.862	50010	
TIMEOUT D1 ManagementLqiRequest startIndex=0
11:43:31.024	50010	
TX D5 ManagementLqiRequest startIndex=0
11:43:39.024	50010	
TIMEOUT D5 ManagementLqiRequest startIndex=0
11:43:43.335	50010	
TX D6 ManagementLqiRequest startIndex=0
11:43:49.978	50010	
TX D7 ReadAttributesCommand cluster=ON_OFF identifiers=[0]
11:43:51.336	50010	
TIMEOUT D6 ManagementLqiRequest startIndex=0
11:43:53.502	50010	
TX D8 ManagementLqiRequest startIndex=0
11:43:57.978	50010	
TIMEOUT D7 ReadAttributesCommand cluster=ON_OFF identifiers=[0]
11:44:01.503	50010	
TIMEOUT D8 ManagementLqiRequest startIndex=0
11:44:10.106	50010	
TX D9 ManagementLqiRequest startIndex=0
11:44:18.106	50010	
TIMEOUT D9 ManagementLqiRequest startIndex=0
11:44:28.849	50010	
TX DA ManagementLqiRequest startIndex=0
11:44:36.849	50010	
TIMEOUT DA ManagementLqiRequest startIndex=0
11:44:51.885	50010	
TX DB ManagementLqiRequest startIndex=0
11:44:52.990	50010	
TX DC ReadAttributesCommand cluster=ON_OFF identifiers=[0]
11:44:59.885	50010	
TIMEOUT DB ManagementLqiRequest startIndex=0
11:45:00.991	50010	
TIMEOUT DC ReadAttributesCommand cluster=ON_OFF identifiers=[0]
11:45:17.069	50010	
TX DD ManagementLqiRequest startIndex=0
11:45:25.069	50010	
TIMEOUT DD ManagementLqiRequest startIndex=0
11:45:42.380	50010	
TX DE ManagementLqiRequest startIndex=0
11:45:50.381	50010	
TIMEOUT DE ManagementLqiRequest startIndex=0
11:45:56.006	50010	
TX DF ReadAttributesCommand cluster=ON_OFF identifiers=[0]
11:46:04.006	50010	
TIMEOUT DF ReadAttributesCommand cluster=ON_OFF identifiers=[0]
11:46:11.852	50010	
TX E0 ManagementLqiRequest startIndex=0
11:46:19.852	50010	
TIMEOUT E0 ManagementLqiRequest startIndex=0
11:46:39.179	50010	
TX E1 ManagementLqiRequest startIndex=0
11:46:47.179	50010	
TIMEOUT E1 ManagementLqiRequest startIndex=0
11:46:59.017	50010	
TX E2 ReadAttributesCommand cluster=ON_OFF identifiers=[0]
11:47:07.017	50010	
TIMEOUT E2 ReadAttributesCommand cluster=ON_OFF identifiers=[0]
11:47:12.945	50010	
TX E3 ManagementLqiRequest startIndex=0
11:47:20.946	50010	
TIMEOUT E3 ManagementLqiRequest startIndex=0
11:47:46.710	50010	
TX E4 ManagementLqiRequest startIndex=0
11:47:54.711	50010	
TIMEOUT E4 ManagementLqiRequest startIndex=0
11:48:02.038	50010	
TX E5 ReadAttributesCommand cluster=ON_OFF identifiers=[0]
11:48:10.038	50010	
TIMEOUT E5 ReadAttributesCommand cluster=ON_OFF identifiers=[0]
11:48:22.743	50010	
TX E9 ManagementLqiRequest startIndex=0
11:48:30.743	50010	
TIMEOUT E9 ManagementLqiRequest startIndex=0
11:48:32.907	50010	
TX EA ManagementLqiRequest startIndex=0
11:48:40.908	50010	
TIMEOUT EA ManagementLqiRequest startIndex=0
11:48:45.216	50010	
TX EB ManagementLqiRequest startIndex=0
11:48:53.216	50010	
TIMEOUT EB ManagementLqiRequest startIndex=0
11:48:55.373	50010	
TX EC ManagementLqiRequest startIndex=0
11:49:03.373	50010	
TIMEOUT EC ManagementLqiRequest startIndex=0
11:49:05.051	50010	
TX ED ReadAttributesCommand cluster=ON_OFF identifiers=[0]
11:49:07.678	50010	
TX EE ManagementLqiRequest startIndex=0
11:49:13.052	50010	
TIMEOUT ED ReadAttributesCommand cluster=ON_OFF identifiers=[0]
11:49:15.679	50010	
TIMEOUT EE ManagementLqiRequest startIndex=0
11:49:19.990	50010	
TX EF ManagementLqiRequest startIndex=0
11:49:27.991	50010	
TIMEOUT EF ManagementLqiRequest startIndex=0
11:49:43.025	50010	
TX F0 ManagementLqiRequest startIndex=0
11:49:51.025	50010	
TIMEOUT F0 ManagementLqiRequest startIndex=0
11:50:06.060	50010	
TX F1 ManagementLqiRequest startIndex=0
11:50:08.077	50010	
TX F2 ReadAttributesCommand cluster=ON_OFF identifiers=[0]
11:50:14.060	50010	
TIMEOUT F1 ManagementLqiRequest startIndex=0
11:50:16.078	50010	
TIMEOUT F2 ReadAttributesCommand cluster=ON_OFF identifiers=[0]
11:50:24.809	50010	
TX F3 ManagementLqiRequest startIndex=0
11:50:32.809	50010	
TIMEOUT F3 ManagementLqiRequest startIndex=0

chris · December 22, 2018, 11:25am

If I remember correctly, there were reports that the Aquaria devices may become disconnected, and they don’t like routers (I recall reading this on the ST forum). It’s probably pretty hard to tell without a sniffer log, but if you provide the debug log I will take a look to see if there is anything notable logged.

wborn · December 22, 2018, 12:00pm

I had the same issue with the Plugwise Binding and it turned out to be due to the deprecation of the ExtendedDiscoveryService. As a result during background discovery it starts querying all (offline) devices. Disabling background discovery could be a workaround for now.

Maybe you’ve missed my comment on ESH #6216 @chris?

The following bindings may now have these issues: Air Visual Node, Amazon Echo Control, EnOcean, MiHome, LIRC, Plugwise, RFXCom, SomfyTahoma, Zoneminder, ZigBee, Z-Wave

Fredrik_Andersson · December 22, 2018, 2:58pm

Here’s a log file shared with onedrive. I have made comments in a few places. Just search for ```
and you will find it. But basically I pair the device, it works, then the binding starts to poll it and does some kind of neighbor check. It dosent respond (cause it’s a battery device). It still works though. But when i press the small button on the Aqara switch 2, the device leave the network immediately. And the binding still try to poll it.

https://1drv.ms/t/s!AijwO0Pec8KrgvtGT8fG5oU5C8a4yQ

WeRo · December 22, 2018, 3:09pm

Update regarding my problem.
I manually went thru all steps of Scotts script.
ZSS is 1.1.7
Snapshot is 2.5.0
All Items deleted in jsondb
All items added by Paper UI
All channels in my items file updated
There are no error messages anymore in openhab.log
event.log looks fine too

BUT changing the switch by Control in Paper UI or by the App still nothing happens.
Now I’m completely helpless.

Any hint is appriciated!!

UPDATE: I had to reset and synchronize the devices newly - now everything works fine!!

jfrank1845 · December 22, 2018, 4:01pm

Hey Chris - sorry for the confusion - I did ‘reclycle’ my logs file share and reposted different files for other logs. You are correct that the version I loaded up on a side system was 2.3 and the power readings were working there. I too am a bit confused as to where the label changed between active power and total active power… I’ve tried various versions to catch the spot but still haven’t gotten it totally locked in. I’m going to guess that you should at least be able to get this cleared up fairly easily in an upcoming release? I do also know the ‘switch’ channel starting being dectected as a dimmer in recent versions yet when I installed 2.3 it is still showing as a dimmer so perhaps an ota update or something?

Thanks so much and hope you have a wonderful holiday!

chris · December 22, 2018, 9:33pm

There’s not really much to go on in the log unfortunately.

ZigBee battery devices the comply with the standard should respond - they are required to poll once every 7.5 seconds, and their parent is required to queue frames for this period as well…

Devices leaving, and rejoining, is not uncomon. This is under the control of the coordinator - sometimes the coordinator may ask a device to leave and rejoin again and it’s possible that the Xiaomi devices don’t do this properly. It’s impossible to tell without seeing a sniffer log.

Sorry - not so helpful I’m afraid.

chris · December 22, 2018, 9:37pm

What device is this for? The binding will typically not provide a switch channel if there is a dimmer channel - if this is what you’re seeing, then this is normal.

Can you provide the network XML file for your network (it’s in the userdata folder).

Thanks - you too

Fredrik_Andersson · December 23, 2018, 8:51am

Thanks for your answer. Im trying to understand the log. It seems like the binding request a neighbor update to my end device (28379) lumi.weather. Im a noob in this but it seems from the log that the sensors answers with “relaylist” (isnt that neighbors?) but the binding seems to ignore that. Below is a small cut out from the log where the neighbor update is sent, and from what i can see the device responds. Im also posting a log with a longer time perspective incl the first one.

00158D000247ECE1 = lumi.weather (28379)
0017880102043D5B = gateway? (9C1E)(39966)
000D6F0012EA8781 = phillips hue light (works)
000B57FFFE8F3219 = ikea tradfri dimmer

2018-12-23 09:07:28.765 [DEBUG] [iscovery.ZigBeeNodeServiceDiscoverer] - 00158D000247ECE1: Node SVC Discovery: Update mesh
2018-12-23 09:07:28.768 [DEBUG] [iscovery.ZigBeeNodeServiceDiscoverer] - 00158D000247ECE1: Node SVC Discovery: scheduled [NEIGHBORS]
2018-12-23 09:07:29.735 [DEBUG] [iscovery.ZigBeeNodeServiceDiscoverer] - 00158D000247ECE1: Node SVC Discovery: running
2018-12-23 09:07:29.738 [DEBUG] [tsystems.zigbee.ZigBeeNetworkManager] - TX CMD: ManagementLqiRequest [0/0 -> 28379/0, cluster=0031, TID=DC, startIndex=0]
2018-12-23 09:07:29.741 [DEBUG] [tsystems.zigbee.ZigBeeNetworkManager] - TX APS: ZigBeeApsFrame [sourceAddress=0/0, destinationAddress=28379/0, profile=0000, cluster=49, addressMode=DEVICE, radius=31, apsSecurity=false, apsCounter=220, payload=00 00]
2018-12-23 09:07:29.744 [DEBUG] [zigbee.dongle.ember.ZigBeeDongleEzsp] - EzspSendUnicastRequest [type=EMBER_OUTGOING_DIRECT, indexOrDestination=28379, apsFrame=EmberApsFrame [profileId=0, clusterId=49, sourceEndpoint=0, destinationEndpoint=0, options=[EMBER_APS_OPTION_ENABLE_ADDRESS_DISCOVERY, EMBER_APS_OPTION_ENABLE_ROUTE_DISCOVERY, EMBER_APS_OPTION_RETRY], groupId=0, sequence=220], messageTag=220, messageContents=00 00]
2018-12-23 09:07:30.778 [DEBUG] [zigbee.dongle.ember.ZigBeeDongleEzsp] - RX: EzspSendUnicastResponse [status=EMBER_SUCCESS, sequence=151]
2018-12-23 09:07:30.782 [DEBUG] [zigbee.dongle.ember.ZigBeeDongleEzsp] - Unhandled EZSP Frame: EzspSendUnicastResponse [status=EMBER_SUCCESS, sequence=151]
2018-12-23 09:07:30.786 [DEBUG] [zigbee.dongle.ember.ZigBeeDongleEzsp] - RX: EzspIncomingRouteRecordHandler [source=28379, sourceEui=00158D000247ECE1, lastHopLqi=246, lastHopRssi=-84, relayList=9C1E]
2018-12-23 09:07:30.790 [DEBUG] [zigbee.dongle.ember.ZigBeeDongleEzsp] - Unhandled EZSP Frame: EzspIncomingRouteRecordHandler [source=28379, sourceEui=00158D000247ECE1, lastHopLqi=246, lastHopRssi=-84, relayList=9C1E]
2018-12-23 09:07:37.743 [DEBUG] [iscovery.ZigBeeNodeServiceDiscoverer] - 00158D000247ECE1: Node SVC Discovery: ManagementLqiRequest response CommandResult [TIMEOUT]
2018-12-23 09:07:37.746 [DEBUG] [iscovery.ZigBeeNodeServiceDiscoverer] - 00158D000247ECE1: Node SVC Discovery: request NEIGHBORS failed. Retry 1, wait 2154ms before retry.
2018-12-23 09:07:39.903 [DEBUG] [iscovery.ZigBeeNodeServiceDiscoverer] - 00158D000247ECE1: Node SVC Discovery: running

https://1drv.ms/t/s!AijwO0Pec8KrgvtHvM0lT9vEmtFjAQ <- log file
EDIT: The short log was wrong device.

curlyel · December 23, 2018, 9:17am

Just to let you know: I have two of them currently and they remain connected once properly included.
BUT, probably…

… just because they have direct reach to the coordinator (CC2531 in my case) without the need of routing.

I’ve noticed, that they could be silent for a very long time as long as the measurements (temp/hum/pressure) are not change.

chris · December 23, 2018, 9:20am

I do not see any response. I think you are looking at the EzspIncomingRouteRecordHandler message? This is not a response from the device - it’s a message from the coordinator.

chris · December 23, 2018, 9:21am

Yes - I think this might be an important point - it looks likely that @Fredrik_Andersson sensors are connected via another router and this is likely why they periodically drop out. I suspect that the router is aging them out, and they then do not support the ZigBee rejoin.

Fredrik_Andersson · December 23, 2018, 9:53am

Okey sorry guys thats the coordinator answer. Im in the learning of understanding Zigbee traffic, can you recommend a good sniffer? Is it CC2531?
In my first test I didnt have any other devices than the aqara device. So it should be no routing. But it depends. I had reseted the controller in the thing. Does that exclude all devices and start over? Or does it still hold the devices?
The device works for now. But the neighbor discover fails 13 times then starts over. Is that normal?

2018-12-23 10:51:30.778 [DEBUG] [iscovery.ZigBeeNodeServiceDiscoverer] - 00158D000247ECE1: Node SVC Discovery: ManagementLqiRequest response CommandResult [TIMEOUT]
2018-12-23 10:51:30.784 [DEBUG] [iscovery.ZigBeeNodeServiceDiscoverer] - 00158D000247ECE1: Node SVC Discovery: request NEIGHBORS failed after 13 attempts.
2018-12-23 10:51:30.791 [DEBUG] [iscovery.ZigBeeNodeServiceDiscoverer] - 00158D000247ECE1: Node SVC Discovery: running
2018-12-23 10:51:30.798 [DEBUG] [iscovery.ZigBeeNodeServiceDiscoverer] - 00158D000247ECE1: Node SVC Discovery: complete
2018-12-23 10:51:30.805 [DEBUG] [tsystems.zigbee.ZigBeeNetworkManager] - 00158D000247ECE1: Node 28379 update
2018-12-23 10:51:30.814 [DEBUG] [ng.zigbee.handler.ZigBeeThingHandler] - 00158D000247ECE1: Node updated - ZigBeeNode [IEEE=00158D000247ECE1, NWK=6EDB, Type=END_DEVICE]

chris · December 23, 2018, 10:00am

Maybe, but the coordinator will also age out devices - it’s a requirement of ZigBee 3 now, and even older implementations normally had this… I’m not sure if there are any settings to control this, but the aging will force the device to rejoin, and it seems these devices won’t do that.

I use the CEL stick. I’ve never managed to get the CC2531 to work here (as a sniffer that is). The problem with the CEL stick is they need firmware to be programmed - I did offer a while back to program some if people were interested.

ZigBee coordinators do not hold a list of devices that are connected to the network, however if you reset the coordinator, then it will stop any devices using the network as the security configuration will change. You will then need to reconnect all devices.

The device is not responding, so yes, it is normal that the discovery will fail.

curlyel · December 23, 2018, 10:16am

Mine CC2531 came with the sniffer firmware programmed. I had to flash the zstack firmware instead to make use of it for the Zigbee binding.

Before re-flashing the dongles, I’ve tried the the sniffer Application from Texas Instruments. It worked so far as I’ve been able to see some zigbee packets recorded/decoded…

chris · December 23, 2018, 10:18am

Yes, so did my sniffer, but I couldn’t get the software to work properly on my Mac. Admittedly I didn’t try super hard as I have lots of other sniffers, but it wasn’t super simple.

The Silabs/CEL works well and is better built, but costs a bit more than the cheap China TI clones.

Fredrik_Andersson · December 23, 2018, 10:26am

Where could I get a stick like that? Im very interested in zigbee traffic, many new smart product in sweden use zigbee. I have some power measures from schneider electic (Wiser) which I would like to sniff.
If I have a sniffer is it possible for me to help with the progress of xiaomi aqara sensors? I would like to learn.