Aqara button not working anymore after OH3 upgrade

Setup, Configuration and Use Migration
,
1

Hi,

After upgrading to OH3, I had some trouble getting my Zigbee devices working again. (Turned out to be a combination of factors, fixed it.) Everything is working again, apart from my Aqara remote, which is a double button. It is properly discovered, including the two channels for the buttons. However, the rules I defined are not triggered any more. I double checked the channel ID’s in the rules definition, and those are unchanged.

I enabled debug logging. Whenever I press one of the buttons, I get this in the log:

2021-01-01 12:13:44.521 [DEBUG] [zigbee.dongle.ember.ZigBeeDongleEzsp] - RX EZSP: EzspIncomingRouteRecordHandler [networkId=0, source=7AD8, sourceEui=00158D00031387A0, lastHopLqi=255, lastHopRssi=-69, relayList=5492]

2021-01-01 12:13:44.578 [DEBUG] [zigbee.dongle.ember.ZigBeeDongleEzsp] - RX EZSP: EzspIncomingMessageHandler [networkId=0, type=EMBER_INCOMING_UNICAST, apsFrame=EmberApsFrame [profileId=0104, clusterId=0012, sourceEndpoint=1, destinationEndpoint=1, options=[EMBER_APS_OPTION_ENABLE_ROUTE_DISCOVERY], groupId=0, sequence=A5], lastHopLqi=255, lastHopRssi=-67, sender=7AD8, bindingIndex=255, addressIndex=255, messageContents=18 31 0A 55 00 21 01 00]

2021-01-01 12:13:44.582 [DEBUG] [tsystems.zigbee.ZigBeeNetworkManager] - RX APS: ZigBeeApsFrame [sourceAddress=7AD8/1, destinationAddress=0000/1, profile=0104, cluster=0012, addressMode=DEVICE, radius=0, apsSecurity=false, ackRequest=false, apsCounter=A5, rssi=-67, lqi=FF, payload=18 31 0A 55 00 21 01 00]

2021-01-01 12:13:44.585 [DEBUG] [tsystems.zigbee.ZigBeeNetworkManager] - RX ZCL: ZclHeader [frameType=ENTIRE_PROFILE_COMMAND, manufacturerSpecific=false, direction=SERVER_TO_CLIENT, disableDefaultResponse=true, manufacturerCode=0, sequenceNumber=49, commandId=10]

2021-01-01 12:13:44.588 [DEBUG] [tsystems.zigbee.ZigBeeNetworkManager] - Unsupported local client cluster 0012

2021-01-01 12:13:44.591 [DEBUG] [tsystems.zigbee.ZigBeeNetworkManager] - Incoming message from node 7AD8 did not translate to command

I assume the “did not translate to command” is the cause of the rules not being triggered. Hence my question: how come the incoming message is not translated to a command? And what can I do to improve this situation?

Any help would be appreciated!

Best regards,
Bart

2

I also see this error in the log a couple of times:

2021-01-04 14:24:02.900 [ERROR] [nverter.ZigBeeConverterGenericButton] - 00158D00031387A0: Error 0xffff setting server binding for cluster 18
2021-01-04 14:24:12.330 [ERROR] [nverter.ZigBeeConverterGenericButton] - 00158D00031387A0: Error 0xffff setting server binding for cluster 0

@chris Can you look into this, please? I’ve checked that the button is correctly recognized as a Xiaomi Wall Switch (lumi.remote.b286acn01). It is offline most of the time, but occasionally I see it online. I guess this is normal for a battery-operated switch.

3

This error means there was an error setting the bind command with the device. So it’s an error with communicating with the device - maybe it’s asleep?

4

It should not be, I just pressed the buttons. What about this message:

5

That simply means that this message is not processed by the binding - ie it doesn’t link with any channel.

6

But it should. I checked the cluster, 12, and that’s the one it expects. I checked the payload and that also seems allright, as far as I can see. (I don’t know what the format should be, but it has the value 85 in it, which should be the right value, according to this XML.)

7

I don’t believe that any of the converters use cluster 18 do they? Also, this hasn’t changed in the last 12 months - these checks were added late 2019 when we put a system through ZigBee certification, and these checks were required then to pass the tests. It has not changed in OH3 as stated.

8

Cluster 18 is mentioned in the error message I shared later, but the log snippet in the original message shows that a message is received from the right node, in cluster 12, that is not translated into a command.

9

And are these used in a converter?

Please also don’t get mixed up with number formats (ie 18 = 0012)

10

What do you mean by a converter?

Sorry, I wasn’t aware that 0012 was to be interpreted as hex. I’d expect a 0x prefix then.

11

Well, the binding uses converters to convert incoming data to channels. If there’s no converter, then it’s not going to work.

12

I don’t tend to use this within the libraries - everything gets extended and many lines are already very long already. The 4 character notation is quite common.

13

Okay. How come there is no converter then? Can I add one manually? Remember: this switch used to work fine before I upgraded to OH3…

14

I don’t know. I am actually not sure what you are doing here?

What has changed? What version were you using before? The binding hasn’t changed from 2.5.11 to 3.0, so the upgrade should not have made any difference.

Sorry - I’m quite busy at the moment so if you can provide further information on your problem I will take a look tomorrow or Wednesday hopefully.

15

I totally understand that! I really appreciate any help, Chris!

So, I upgraded to OH3 and had some trouble, I think you remember my other post from a few days ago. So I had to rebuild the ZigBee network. All devices came back flawlessly, but this Xiaomi wall switch didn’t work anymore.

I’ll try to give as much information as possible. Let me know if you need something specific that is missing.

  • I upgraded from openHAB 2.5M1 to 3.0
  • I have an Ember EM35x controller
  • I have a couple of rules that are to be triggered by this button. This used to work fine before the upgrade.
  • This evening I removed and re-added the switch a couple of times. The log below is from the discovery of the device, and at the end of the log, you see a couple of button presses.

xiaomi.log (93.9 KB)
Note that this is not a complete log, there were other things in the log that I don’t wish to share on a public forum. I filtered the log as follows:

grep "00158D00031387A0\|B56C" /var/log/openhab/openhab.log

Some additional info from the console:

openhab> zigbee nodes
Total known nodes in network: 8
Network  Addr  IEEE Address      Logical Type  State      EP   Profile                    Device Type                Manufacturer     Model
      0  0000  000D6F000C8691BA  COORDINATOR   UNKNOWN
  17792  4580  00158D0003F4382F  END_DEVICE    ONLINE      1  ZIGBEE_HOME_AUTOMATION     OCCUPANCY_SENSOR           LUMI             lumi.sensor_motion.aq2
  20762  511A  D0CF5EFFFE260C16  ROUTER        ONLINE      1  ZIGBEE_LIGHT_LINK          POINT_OF_SALE              IKEA of Sweden   TRADFRI bulb E27 WS opal 980lm
  21650  5492  000D6FFFFE03C639  ROUTER        ONLINE      1  ZIGBEE_HOME_AUTOMATION     COLOR_TEMPERATURE_LIGHT    IKEA of Sweden   TRADFRI bulb E27 WS opal 1000lm
                                                         242  A1E0                       ZGP_PROXY_BASIC
  42350  A56E  000D6FFFFEE843C4  ROUTER        ONLINE      1  ZIGBEE_LIGHT_LINK          ON_OFF_LIGHT               IKEA of Sweden   TRADFRI bulb E27 W opal 1000lm
  46444  B56C  00158D00031387A0  END_DEVICE    ONLINE      1  ZIGBEE_HOME_AUTOMATION     5F01                       LUMI             lumi.remote.b286acn01
                                                           2  ZIGBEE_HOME_AUTOMATION     5F02
                                                           3  ZIGBEE_HOME_AUTOMATION     5F03
  53960  D2C8  000D6FFFFEE80288  ROUTER        ONLINE      1  ZIGBEE_LIGHT_LINK          ON_OFF_LIGHT               IKEA of Sweden   TRADFRI bulb E27 W opal 1000lm
  56292  DBE4  90FD9FFFFED1AD53  ROUTER        ONLINE      1  ZIGBEE_LIGHT_LINK          POINT_OF_SALE              IKEA of Sweden   TRADFRI bulb E27 WS opal 980lm

openhab> zigbee node 46444
IEEE Address     : 00158D00031387A0
Network Address  : 46444
Node Descriptor  : NodeDescriptor [apsFlags=0, bufferSize=127, complexDescriptorAvailable=false, manufacturerCode=1037, logicalType=END_DEVICE, serverCapabilities=[], incomingTransferSize=100, outgoingTransferSize=100, userDescriptorAvailable=false, frequencyBands=[FREQ_2400_MHZ], macCapabilities=[REDUCED_FUNCTION_DEVICE], extendedEndpointListAvailable=false, extendedSimpleDescriptorListAvailable=false, stackCompliance=0]
Power Descriptor : PowerDescriptor [currentPowerMode=RECEIVER_ON_IDLE, availablePowerSources=[DISPOSABLE_BATTERY], currentPowerSource=DISPOSABLE_BATTERY, powerLevel=FULL]
Associations     : []
Endpoints        :
            1    : Profile     0104 ZIGBEE_HOME_AUTOMATION
                 : Device Type 5F01 null
                   -> BASIC
                   -> IDENTIFY
                   -> MULTISTATE_INPUT_BASIC
                   -> OTA_UPGRADE
                   -> 0xFFFF
                   <- BASIC
                   <- IDENTIFY
                   <- GROUPS
                   <- SCENES
                   <- MULTISTATE_INPUT_BASIC
                   <- OTA_UPGRADE
                   <- 0xFFFF
            2    : Profile     0104 ZIGBEE_HOME_AUTOMATION
                 : Device Type 5F02 null
                   -> IDENTIFY
                   -> MULTISTATE_INPUT_BASIC
                   <- IDENTIFY
                   <- GROUPS
                   <- SCENES
                   <- MULTISTATE_INPUT_BASIC
            3    : Profile     0104 ZIGBEE_HOME_AUTOMATION
                 : Device Type 5F03 null
                   -> IDENTIFY
                   -> ANALOG_INPUT_BASIC
                   <- IDENTIFY
                   <- GROUPS
                   <- SCENES
                   <- ANALOG_INPUT_BASIC
Neighbors:
Routes:

openhab> zigbee bindtable 46444
Binding table read error: FAILURE

(This command takes a couple of seconds to complete.)

16

So this might be a key point. 2.5M1 is very old - possibly (probably) from before the zigbee certification was done and therefore it allowed some commands through that we had to block in order to get it past certification. These clusters will likely need to be opened up again as it seems there is no converter that natively supports the command being sent.

Please can you raise an issue on github and I will take a look a how to do that.

17

Sure! Done!

18

Hi @chris, are there any updates on this issue yet?

19

Sorry - things have been quite busy this way recently. Don’t ever consider moving house! :slight_smile:

Generally I’m happy with the approach - I just wanted to have a think about the structure. I’ll try and take a look during the week.

20

Ah, I didn’t know you were moving houses. That can be pretty intense, I know from personal experience. Good luck with moving. I won’t bother you then. Let me know if I can help with some testing and/or documenting.