ZHA aqara mini switch versions

Configuration Zigbee
1

I have just set up ZHA using a sonoff zigbee three dongle. I have an aqara mini switch that pairs and works for a period of time then appears to be nonfunctional.

Looking around there seems to be several versions of the switch. I thought I had the older version because of the method of function which I could swear was one click, two clicks, and long press (lumi.remote.b1acn01). ZHA seems to identify it as one of the newer versions lumi.sensor_switch.aq2 which has up to 5 clicks which doesn’t seem right.

Just wondering if this could possibly be the reason for the eventual nonfuntionality of the switch. I looked around but it doesn’t seem easy to alter the signature and quirks( if I am on the right track even) to see if this hypothesis is correct.
Can anybody give me any direction on how to fix this combination of ZHA and the Aqara mini switch

2

It probably eitther needs a ZHA Device Handler (a.k.a. a quirk) if lacking quirk, if so post a new device request as an issue or if it already has quirk then could still be that the quirk need bug fix if so report it as a bug to the same here GitHub repository here → https://github.com/zigpy/zha-device-handlers/issues

The reason why ZHA Device Handlers (a.k.a. a quirks) are sometimes needed i explained in the ZHA docs here → https://www.home-assistant.io/integrations/zha#zha-exception-and-deviation-handling

and read:

https://www.home-assistant.io/integrations/zha#knowing-which-devices-are-supported

Summery in relevant technical layman’s terms;

Most Zigbee devices with Chinese brands are either made by Tuya or Aqara/Xiaomi and both of those manufacturers are infamous for making device firmware for those products that do not strictly follow Zigbee specification standards, in fact, deviating from standard attributes and values (as well as standard Zigbee clusters) will break practically all Zigbee solutions until they implement custom workarounds for each and every individual device that does not follow the standards of the set specifications, and manufacturers keep releasing new devices so to developers of any third-party Zigbee solutions that did not make that non-standard device it is like a never-ending game of playing catch-up in order to implement a new custom workaround for each new such device that is found in the wild.

To make things a little bit easier such workarounds for individual devices in different Zigbee solutions are implemented in the same way so much can be reused via shared device handlers that deal with conversions of non-standard quirks and deviations from the official specification standards set by the Zigbee Alliance.

Therefore each brand new device needs parsing and translation to convert the messages so are presented as virtual device representations that actually do follow the Zigbee specification standards. That is when someone needs to write a custom “quirk” (sometimes also referred to as a “converter”).

Device handlers/converters parse and translate/convert any non-standard Zigbee attribute(s) and value(s) or other deviating quirks into standard Zigbee attribute(s) and value(s) which then the ZHA integration can understand.

PS: Unlike some proprietary Zigbee solutions such as for example Tuya or Aqara/Xiaomi own Zigbee gateways the ZHA integration implementation and its zigpy dependency has been designed to follow the official Zigbee specification standard and therefore all devices that actually do follow the Zigbee specification standard should just work out-of-the-box without the need of any custom device handlers.

3

Thanks but unless Aqara/Xiaomi have actually pushed a new firmware to my very old device than this information seems superfluous.

I have read some of the links you have provided already while trying to figure this problem out but I could not glean at least at my technical level of understanding of how I could dictate a zigbee signature to ZHA(and therefor maybe fix the problem?)
I have had this button for probably 5 years or more and believe it was one of the older iterations. I am pretty sure that it can only recognize one clicks or two clicks and a long press.

Weirdly it seems to be recognized as new device and the blueprint that works with it https://community.home-assistant.io/t/zha-xiaomi-aqara-wireless-mini-switch-wxkg11lm-lumi-sensor-switch-aq2/261520 by @carlosmesquita which I think is for a newer button? and goes up to 5 clicks

I agree though aqara / xiaomi make it difficult with their many versions and alterations of the standard.
Thanks for answering but your answer seems somewhat generalized

4

If you are using a Blueprints then the Blueprint probably needs to be updated as ZHA slightly changed how it presents some devices that do not follow Zigbee standard and as such are require quirks, see ex:

and see examples of issues in Blueprints caused by these changes:

5

Hello @dasbooter ,

Can you explain further when you mean that the switch “works for a period of time then appears to be nonfunctional”?
Are you using any Blueprint? Have you checked the zha_events coming through to check? Did you check the switch state on the ZHA integration?

Best regards

6

So the switch that is detected by zha is the one that is compatible with a blueprint that I believe you authored. There are a few blueprints that are compatible with the different revisions of the switch as is my understanding.
After immediate pair the button works with your blueprint but after some time it fails to work (say overnight).
I have monitored the events page using zha_events but it shows similar behaviour. After pair clicking the button shows events but after some time I get no response.

The thing which is I think odd is my button is pretty old and I think it’s the version that does one click, two click and long press not the one that u designed the blueprint for.

I believe after the button becomes unresponsive to clicks it does display temperature? And battery but I will have to check tomorrow at I’m at work

7

Is it set to legacy mode?

Perhaps it is just falling off the network?

There is info on both issues here Xiaomi WXKG11LM control via MQTT | Zigbee2MQTT (I know this is for z2m, but the information is universal)

8

I did hit that page when I was looking but didn’t read too far as it’s for zigbee2mqtt. Can I disable legacy mode in ZHA. I’m at work but I’ll look into this more when I can.

Your right of course it could be just falling off the network. I’ve changed the battery and left it next to the coordinator to try and troubleshoot that.

9

I have some aqara motion, i use outdoor (I know they are indoor devices, however they are small and cheap). I have seen strange behavior when it gets cold outside, like minus degrees. When that happen I replace the battery, even if the battery shows 90%. It always solves the problem.

You device is old, maybe it just need juice😁

10

Right after pairing the button, if you try to triple or quadruple press it, does it send those events via zha_events? If it does, it is actually the version that my Blueprint supports; if it doesn’t, it probably is the older version, and something is fishy either with its firmware, or with the quircks. It might be so old that pretty much no one uses it and it was “forgotten”.

11

I was able to quickly check today but back to work. The button was still responsive. I’ll check the multiple clicks when I can. What should I see exactly in events with multiple clicks. I looked quickly and the events looked the same?

12

Try pressing the button 3 times, 4 times, 5 times, and check if the events sent are “triple press” and “quadruple press”, something like that! :slight_smile:

13

Sure I meant in what would I see that was different in terms of zha_event listener for the different clicks.

In any case I have re-paired the device after establishing under the blueprint commands for multiple clicks. Ok on initial pair the blueprint works to open a set of blinds I have with a single click one time only. After that the the blueprint doesnt respond to any sort of click. I can still still see events on the services page but I cannot differentiate any difference in the clicks only that they cause and event. For testing purposes I tried an initial pair and then tried 4 clicks and nothing happens but there continues to be output to events under zha_event.

I could post those results if somebody can tell me if I have to redact any of that info for security purposes

EDIT: on reread of your post should I see some distinguishing feature under events because all I see is "event_type": "zha_event",

14

Just take out the device_ieee and unique_ids.

Here are the output from the events, when pressing 1 time:

{
    "event_type": "zha_event",
    "data": {
        "device_ieee": "XX",
        "unique_id": "XX",
        "device_id": "XX",
        "endpoint_id": 1,
        "cluster_id": 6,
        "command": "attribute_updated",
        "args": {
            "attribute_id": 0,
            "attribute_name": "on_off",
            "value": 1
        }
    }
}

2 times:

{
    "event_type": "zha_event",
    "data": {
        "device_ieee": "XX",
        "unique_id": "XX",
        "device_id": "XX",
        "endpoint_id": 1,
        "cluster_id": 6,
        "command": "attribute_updated",
        "args": {
            "attribute_id": 32768,
            "attribute_name": "Unknown",
            "value": 2
        }
    }
}

3 times:

{
    "event_type": "zha_event",
    "data": {
        "device_ieee": "XX",
        "unique_id": "XX",
        "device_id": "XX",
        "endpoint_id": 1,
        "cluster_id": 6,
        "command": "attribute_updated",
        "args": {
            "attribute_id": 32768,
            "attribute_name": "Unknown",
            "value": 3
        }
    }
}

And finally 4 times:

{
    "event_type": "zha_event",
    "data": {
        "device_ieee": "XX",
        "unique_id": "XX",
        "device_id": "XX",
        "endpoint_id": 1,
        "cluster_id": 6,
        "command": "attribute_updated",
        "args": {
            "attribute_id": 32768,
            "attribute_name": "Unknown",
            "value": 4
        }
    }
}

As you can see, the value tag is changing and corresponds to the number of presses.

If you need anything else just tell me. If you don’t want to share some information here, send me a DM and we can talk somewhere else :slight_smile:

15

Thanks for the example and thanks so much for your help. I will check the value tag when I get a chance. Trying to sort this out on my days off.

I attempted to write an automation (haven’t worked with events before) using zha_event and event data device_ieee: which will trigger an automation but also triggered the automation in the middle of the night without a button press which I can only think was the button checking in on the zigbee network.

I cant see the results on the event listeners page b/c I don’t have access to the button right now but I was pouring over the results of the different button clicks,previously, and believe they were identical no matter what the press but will confirm when I get access to the button. I will post the results when I can get at the button with the appropriate info removed. Better to keep it public to help someone else.I have disabled the automation so no more middle of the night occurences lol

16

I guess the resolution here is no resolution. I have migrated to zigbee2mqtt and personally I’m getting better results that way. I purchased 2 tradfri 5 button remotes which seem to work well so far.

17

Well… if it works, stick to it hehe
I also use a LOT of those Tradfri 5 button remotes, they are awesome!