I have the exact same problem with my xbee coordinator. It had been running perfectly fine on the M7 test release and I thought it would be fine to update to the 2.4 official release.
Since then I have the exact same problem as you have @stephanSH, the XBee Coordinator stays as Unknown. That’s very strange that this has changed between these 2 (quite similar - I haven’t checked the code though) versions !
You should update to the latest ZSS libraries (1.1.7) using @5ivers script and it will resolve this.
Thanks for the fast answer @chris. Quick question though: the script somehow tries to install the ZSS libraries for a 2.5.0 snapshot. I am however still running 2.4.0 but I guess it shouldn’t be a problem.
openhab> list -s | grep zig
273 │ Active │ 80 │ 1.1.7 │ com.zsmartsystems.zigbee.dongle.telegesis
274 │ Active │ 80 │ 2.5.0.201812170851 │ org.openhab.binding.zigbee
275 │ Active │ 80 │ 1.1.7 │ com.zsmartsystems.zigbee.dongle.cc2531
276 │ Active │ 80 │ 2.5.0.201812170851 │ org.openhab.binding.zigbee.xbee
277 │ Active │ 80 │ 1.1.7 │ com.zsmartsystems.zigbee.dongle.xbee
278 │ Active │ 80 │ 2.5.0.201812170851 │ org.openhab.binding.zigbee.cc2531
279 │ Active │ 80 │ 1.1.7 │ com.zsmartsystems.zigbee
280 │ Active │ 80 │ 1.1.7 │ com.zsmartsystems.zigbee.dongle.ember
281 │ Active │ 80 │ 2.5.0.201812170851 │ org.openhab.binding.zigbee.ember
282 │ Active │ 80 │ 2.5.0.201812170851 │ org.openhab.binding.zigbee.telegesisI’m not familiar with Scotts script - I thought it should allow you to use 2.4 with 1.1.7. I can confirm that the versions are compatible, so if the script allows it, then it should work (@5iver might comment here).
Yes, I can confirm it does, with the above list of packages it’s OK and indeed 1.1.7 did fix my coordinator.
Thanks @chris
The manual install script will install the current snapshot build with the libraries used in the snapshot or the current development versions. There is no option to use stable release binding with development libraries.
That wasn’t a negative (sorry). I just tend to manually compile and install things here, but the script is super useful which is why I keep recommending it 
.
I knew you were familiar with it. I was just being silly!
I just updated oh 2.4 to the 1.1.7 libraries and 30 minutes after reboot my zigbee traffic is still out of control … it constantly has double digit queue numbers. Towards the end it finally started catching up but then started going crazy again with no actions on my part. I’ve noticed that the last few library versions have seemed to do this… Everything will be responsive for me until all of a sudden it all goes haywire again and commands take forever to go out due to the queue being so hi. Any ideas? I recently deleted all of my things and re-added them… should i have completely removed the zigbee database files as well?
Hi Valentin,
sorry but as always chris was faster to answer…
He also helped me a lot by recommending the script from 5iver.
some comments about the changes (I didn’t know that before):
Now everything works fine again. Hope that might help others
There are two things I can say here…
There is a known issue with reasonably large networks that I’m hopeful will be resolved with a new (so called) transaction manager which will try and better manage the queues. At the moment, there is no management - different tasks can just send stuff when they like, and it will get queued at the lowest level. It doesn’t respect requirements on communicating with battery devices, and it can cause big issues. Your network is reasonably large from memory. This is something I’m currently working on and I hope in the coming days to have the first part of this ready (this doesn’t really manage the queue, but it will use the responses from the dongle to allow messages to be timed out quicker which will still help quite a bit I think).
I noticed the other day (I think when reviewing one of your logs) that some messages were being queued twice. This may well be something that was added recently as the libraries were restructured slightly to make it more configurable for different applications, and the discovery mechanism (which is where I saw the duplication) was moved around. I plan to look at this over the next few days as well.
(I’ve not downloaded your log yet, but if possible, can you keep the size to 10MB please - above that my ageing Mac has trouble processing the logs through my web based log viewer and your previous log was 16MB and it took a small age to load! I’m hoping Santa may bring me a new Mac Thanks).
Ah yes. I probably have about 25 Zigbee devices at current 
. Regarding the logs (and I apologize because I’m sure it’s probably somewhere up here already but I tried and failed …) does anyone on this thread have any idea of how I can set openHAB up to log Zigbee to its own file / set the rollover file size to be the smaller size you requested? I never really got the separated file logging to work yet and I’d love to just leave this in debug all the time.
By the way - were you able to see anything about that active power channel from the logs of my fresh 2.3 install where it somehow works? I’ve got a separate install that I can do whatever with to help assist in that resolution.
Thank you! 
I need a little more help. I made a copy of the shell script
zzManualInstaller.sh at /etc/openhab2/addons
But it seems not to be found:
[18:03:48] openhabian@xxxx : ~ $ sudo bash /usr/share/openhab2/addons/zzManualInstaller.sh
[sudo] Passwort für openhabian:
This script must be copied to the $OPENHAB_HOME/addons directory before running it
[18:04:04] openhabian@xxxx : ~ $
PROBLEM SOLVED: hat to change user rights by chmod
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?
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?
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
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
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.
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
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.