Zigbee binding

Tags: #<Tag:0x00007f434a4b8108> #<Tag:0x00007f434aacba68>

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.


1 Like

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

1 Like

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

1 Like

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

  • 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

1 Like

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

1 Like

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:

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:

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:

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

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

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.


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

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!

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.

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