Zigbee binding

Tags: #<Tag:0x00007f0145796f10> #<Tag:0x00007f0145796da8>

(Chris Jackson) #1667

Can you describe your problem - does anything work at all, or is it just that the switches don’t work?

This error is logged during the shutdown of the binding - it has already been fixed, but I’m not sure it should matter given it’s during the shutdown. You could try updating the libraries to 1.1.7 using @5ivers update script as it should stop this error.

(Valentin Longchamp) #1668

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 !

(Chris Jackson) #1669

You should update to the latest ZSS libraries (1.1.7) using @5ivers script and it will resolve this.

(Valentin Longchamp) #1670

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 │     │ org.openhab.binding.zigbee
275 │ Active   │  80 │ 1.1.7                  │ com.zsmartsystems.zigbee.dongle.cc2531
276 │ Active   │  80 │     │ org.openhab.binding.zigbee.xbee
277 │ Active   │  80 │ 1.1.7                  │ com.zsmartsystems.zigbee.dongle.xbee
278 │ Active   │  80 │     │ 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 │     │ org.openhab.binding.zigbee.ember
282 │ Active   │  80 │     │ org.openhab.binding.zigbee.telegesis

(Chris Jackson) #1671

I’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).

(Valentin Longchamp) #1672

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

(Scott Rushworth) #1673

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.


(Chris Jackson) #1674

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 :slight_smile: .

(Scott Rushworth) #1675

I knew you were familiar with it. I was just being silly! :slight_smile:

(Jared Frank) #1676

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?

(stephan) #1677

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):

  • using ubuntu server 18.04 requires the installation of curl before using the script
  • the actual version of ${ZSMARTSYSTEMS_VERSION} is 1.1.7
  • after updating with the script I had to remove the old zigbee binding (installed through PaperUI) manually with karaf (list |grep -i zig; bundle:uninstall xxx;). before I had similar problems like jfrank1845 described…
  • I had to add transport serial manually (feature:install openhab-transport-serial;)
  • to start transport serial again after a restart I had to add it to addons.cfg (see manual install addons OH) which was never necessary before

Now everything works fine again. Hope that might help others

Zigbee and Z-Wave manual install script
(Chris Jackson) #1678

There are two things I can say here…

  1. 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).

  2. 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 :slight_smile: Thanks).

(Jared Frank) #1679

Ah yes. I probably have about 25 Zigbee devices at current :slight_smile: . 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! :smiley:

(Welf Rogalski) #1680

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 :slight_smile:

(Chris Jackson) #1681

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 Jackson) #1682

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?

(Welf Rogalski) #1683

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:

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) #1684

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
STATE UPDATE zigbee:device:789dda81:00158d0001a66806:00158D0001A66806_1_switch ON
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
STATE UPDATE zigbee:device:789dda81:00158d0001a66806:00158D0001A66806_1_switch ON
STATE UPDATE zigbee:device:789dda81:00158d0001a66806:00158D0001A66806_1_switch ON
11:40:32.393	50010	
RX 0D ReportAttributesCommand cluster=ON_OFF
STATE UPDATE zigbee:device:789dda81:00158d0001a66806:00158D0001A66806_1_switch ON
STATE UPDATE zigbee:device:789dda81:00158d0001a66806:00158D0001A66806_1_switch ON
11:40:34.345	50010	
RX 0E ReportAttributesCommand cluster=ON_OFF
STATE UPDATE zigbee:device:789dda81:00158d0001a66806:00158D0001A66806_1_switch ON
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
STATE UPDATE zigbee:device:789dda81:00158d0001a66806:00158D0001A66806_1_switch ON
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
STATE UPDATE zigbee:device:789dda81:00158d0001a66806:00158D0001A66806_1_switch ON
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 Jackson) #1685

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.

(Wouter Born) #1686

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. :frowning: 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

Snapshot 2.5.0 runs Very Slow