zigpy / zha-device-handlers

ZHA device handlers bridge the functionality gap created when manufacturers deviate from the ZCL specification, handling deviations and exceptions by parsing custom messages to and from Zigbee devices.
Apache License 2.0
684 stars 636 forks source link

[Device Support Request] Aqara E1 Wireless Mini Switch WXKG20LM (lumi.remote.acn007) #1939

Open tutivog opened 1 year ago

tutivog commented 1 year ago

Is your feature request related to a problem? Please describe. I recently bought this Mini Switch by Aqara, which supports Zigbee 3.0 protocol. It seems that there are several versions of the mini switch that are out in the market. There is a relatively older model (WXKG11LM) which functions well with ZHA. However, this newer model won't work natively with ZHA. Current Problems:

  1. The device can successfully join the ZHA network, and was recognized as lumi.remote.acn007 with a unique IEEE number.
  2. However, the device would go offine within few minutes after pairing. It has two entities: Battery and Identity, which seems to correspond with a pressed event. But both entities are "unavailalble" after pairing, even before the device is shown to be offline.
  3. When I press the switch, there is no zha_event detected by the home assistant server. This stays the same before and after the device becomes "offline"
  4. Tried rejoin the device several times, and also tried solutions such as keep the device awake during the joining process by pressing the switch every few seconds. But the aforementioned problems persist.

Describe the solution you'd like I wish to have a working ZHA quirk which would allow the device to function correctly with ZHA:

  1. The device could successfully communicate with HA, showing its battery and identify entities.
  2. HA could record the pressed event fired by the device (single press, double press, long press)

According to this support page (https://zigbee.blakadder.com/Aqara_WXKG20LM.html), this device could work under ZIGBEE2MQTT, but I only have one zigbee coordinator and most of my zigbee devices had already been managed by the ZHA, I wish a fix could be used on the ZHA.

Device signature ```yaml { "node_descriptor": "NodeDescriptor(logical_type=, complex_descriptor_available=0, user_descriptor_available=0, reserved=0, aps_flags=0, frequency_band=, mac_capability_flags=, manufacturer_code=4447, maximum_buffer_size=66, maximum_incoming_transfer_size=66, server_mask=10752, maximum_outgoing_transfer_size=66, descriptor_capability_field=, *allocate_address=True, *is_alternate_pan_coordinator=False, *is_coordinator=False, *is_end_device=True, *is_full_function_device=False, *is_mains_powered=False, *is_receiver_on_when_idle=False, *is_router=False, *is_security_capable=False)", "endpoints": { "1": { "profile_id": 260, "device_type": "0x0000", "in_clusters": [ "0x0000", "0x0001", "0x0003", "0x0012", "0xfcc0" ], "out_clusters": [ "0x0003", "0x0006", "0x0019" ] } }, "manufacturer": "LUMI", "model": "lumi.remote.acn007", "class": "zigpy.device.Device" } ```
Diagnostic information ```yaml { "home_assistant": { "installation_type": "Home Assistant OS", "version": "2022.11.2", "dev": false, "hassio": true, "virtualenv": false, "python_version": "3.10.7", "docker": true, "arch": "aarch64", "timezone": "Asia/Shanghai", "os_name": "Linux", "os_version": "5.15.61-v8", "supervisor": "2022.10.2", "host_os": "Home Assistant OS 9.3", "docker_version": "20.10.18", "chassis": "embedded", "run_as_root": true }, "custom_components": { "xiaomi_miio_airconditioningcompanionmcn02": { "version": "0.1.7", "requirements": [ "construct==2.9.45", "python-miio>0.5.3" ] }, "miio_yeelink": { "version": "0.1.12", "requirements": [ "construct==2.10.56", "python-miio>=0.5.6" ] }, "ble_monitor": { "version": "10.5.3", "requirements": [ "pycryptodomex>=3.14.1", "janus>=1.0.0", "aioblescan>=0.2.13", "btsocket>=0.2.0", "pyric>=0.1.6.3" ] }, "midea_ac_lan": { "version": "v0.3.16-Beta7", "requirements": [] }, "colorfulclouds": { "version": "1.2.5", "requirements": [] }, "gjdw": { "version": "0.1", "requirements": [] }, "hacs": { "version": "1.28.3", "requirements": [ "aiogithubapi>=22.2.4" ] } }, "integration_manifest": { "domain": "zha", "name": "Zigbee Home Automation", "config_flow": true, "documentation": "https://www.home-assistant.io/integrations/zha", "requirements": [ "bellows==0.34.2", "pyserial==3.5", "pyserial-asyncio==0.6", "zha-quirks==0.0.85", "zigpy-deconz==0.19.0", "zigpy==0.51.5", "zigpy-xbee==0.16.2", "zigpy-zigate==0.10.3", "zigpy-znp==0.9.1" ], "usb": [ { "vid": "10C4", "pid": "EA60", "description": "*2652*", "known_devices": [ "slae.sh cc2652rb stick" ] }, { "vid": "1A86", "pid": "55D4", "description": "*sonoff*plus*", "known_devices": [ "sonoff zigbee dongle plus v2" ] }, { "vid": "10C4", "pid": "EA60", "description": "*sonoff*plus*", "known_devices": [ "sonoff zigbee dongle plus" ] }, { "vid": "10C4", "pid": "EA60", "description": "*tubeszb*", "known_devices": [ "TubesZB Coordinator" ] }, { "vid": "1A86", "pid": "7523", "description": "*tubeszb*", "known_devices": [ "TubesZB Coordinator" ] }, { "vid": "1A86", "pid": "7523", "description": "*zigstar*", "known_devices": [ "ZigStar Coordinators" ] }, { "vid": "1CF1", "pid": "0030", "description": "*conbee*", "known_devices": [ "Conbee II" ] }, { "vid": "10C4", "pid": "8A2A", "description": "*zigbee*", "known_devices": [ "Nortek HUSBZB-1" ] }, { "vid": "0403", "pid": "6015", "description": "*zigate*", "known_devices": [ "ZiGate+" ] }, { "vid": "10C4", "pid": "EA60", "description": "*zigate*", "known_devices": [ "ZiGate" ] }, { "vid": "10C4", "pid": "8B34", "description": "*bv 2010/10*", "known_devices": [ "Bitron Video AV2010/10" ] } ], "codeowners": [ "@dmulcahey", "@adminiuga", "@puddly" ], "zeroconf": [ { "type": "_esphomelib._tcp.local.", "name": "tube*" }, { "type": "_zigate-zigbee-gateway._tcp.local.", "name": "*zigate*" }, { "type": "_zigstar_gw._tcp.local.", "name": "*zigstar*" } ], "dependencies": [ "file_upload" ], "after_dependencies": [ "onboarding", "usb", "zeroconf" ], "iot_class": "local_polling", "loggers": [ "aiosqlite", "bellows", "crccheck", "pure_pcapy3", "zhaquirks", "zigpy", "zigpy_deconz", "zigpy_xbee", "zigpy_zigate", "zigpy_znp" ], "is_built_in": true }, "data": { "ieee": "**REDACTED**", "nwk": 44177, "manufacturer": "LUMI", "model": "lumi.remote.acn007", "name": "LUMI lumi.remote.acn007", "quirk_applied": false, "quirk_class": "zigpy.device.Device", "manufacturer_code": 4447, "power_source": "Battery or Unknown", "lqi": null, "rssi": null, "last_seen": "2022-11-17T13:47:34", "available": false, "device_type": "EndDevice", "signature": { "node_descriptor": "NodeDescriptor(logical_type=, complex_descriptor_available=0, user_descriptor_available=0, reserved=0, aps_flags=0, frequency_band=, mac_capability_flags=, manufacturer_code=4447, maximum_buffer_size=66, maximum_incoming_transfer_size=66, server_mask=10752, maximum_outgoing_transfer_size=66, descriptor_capability_field=, *allocate_address=True, *is_alternate_pan_coordinator=False, *is_coordinator=False, *is_end_device=True, *is_full_function_device=False, *is_mains_powered=False, *is_receiver_on_when_idle=False, *is_router=False, *is_security_capable=False)", "endpoints": { "1": { "profile_id": 260, "device_type": "0x0000", "in_clusters": [ "0x0000", "0x0001", "0x0003", "0x0012", "0xfcc0" ], "out_clusters": [ "0x0003", "0x0006", "0x0019" ] } } }, "active_coordinator": false, "entities": [ { "entity_id": "button.lumi_lumi_remote_acn007_identify", "name": "LUMI lumi.remote.acn007" }, { "entity_id": "sensor.lumi_lumi_remote_acn007_battery", "name": "LUMI lumi.remote.acn007" } ], "neighbors": [], "endpoint_names": [ { "name": "ON_OFF_SWITCH" } ], "user_given_name": null, "device_reg_id": "0713ea463da4613a1bfb4a3c598ae380", "area_id": "dining_room", "cluster_details": { "1": { "device_type": { "name": "ON_OFF_SWITCH", "id": 0 }, "profile_id": 260, "in_clusters": { "0x0000": { "endpoint_attribute": "basic", "attributes": { "0x0004": { "attribute_name": "manufacturer", "value": "LUMI" }, "0x0005": { "attribute_name": "model", "value": "lumi.remote.acn007" } }, "unsupported_attributes": {} }, "0x0001": { "endpoint_attribute": "power", "attributes": { "0x0020": { "attribute_name": "battery_voltage", "value": 28 } }, "unsupported_attributes": { "0x0021": { "attribute_name": "battery_percentage_remaining" }, "0x0033": { "attribute_name": "battery_quantity" }, "0x0031": { "attribute_name": "battery_size" } } }, "0x0003": { "endpoint_attribute": "identify", "attributes": {}, "unsupported_attributes": {} }, "0x0012": { "endpoint_attribute": "multistate_input", "attributes": {}, "unsupported_attributes": {} }, "0xfcc0": { "endpoint_attribute": "manufacturer_specific", "attributes": {}, "unsupported_attributes": {} } }, "out_clusters": { "0x0003": { "endpoint_attribute": "identify", "attributes": {}, "unsupported_attributes": {} }, "0x0006": { "endpoint_attribute": "on_off", "attributes": {}, "unsupported_attributes": {} }, "0x0019": { "endpoint_attribute": "ota", "attributes": {}, "unsupported_attributes": {} } } } } } } ```
Additional logs ``` Paste any additional debug logs here. Don't remove the extra line breaks outside the ``` marks. ```

Additional context Add any other context or screenshots about the feature request here.

javicalle commented 1 year ago

Can you try to add the device to the RemoteE1SingleRocker1 quirk?:

tutivog commented 1 year ago

Can you try to add the device to the RemoteE1SingleRocker1 quirk?:

First of all, thank you so much for taking a look into this issue. Tried this quirk, and here were the results:

1st attempt: I put the quirk without any changes. The quirk seems to be active, as there is pycache file generated after server reboot. I rejoined the device, nothing changed.

2nd attempt: I compared the clusters data of the lumi.remote.acn003 in remote_e1.py with those data of my device (acn007) and found them to be the same. So I changed line 60 of remote_e1.py to "lumi.remote.acn007" in order to have the quirk to successfully bind to my device. After restarting home assistant server, I rejoined the device. Some of the status of the device now seems to be correctly read by the ZHA handler: image

However, the most important function is still not working. When I pressed the button, there is no response at all in the logbook. I also tried to listen to "zha_event" in the developer tools. Still there is no "pressed" event detected by the server.

javicalle commented 1 year ago

I'm not sure if this device will send the zha_event, I'll check later. Have you tried to create an automatization through the automatization wizard? If not working, debug logs from the device operation will be needed to see what can be happening.

tutivog commented 1 year ago

I'm not sure if this device will send the zha_event, I'll check later. Have you tried to create an automatization through the automatization wizard? If not working, debug logs from the device operation will be needed to see what can be happening.

I don't think I could. In the automatization page I could indeed use certain triggers from the device ("left button pressed" for example). However it would do nothing. I believe it's still one of the original problem with the device going offline after joining the ZHA network. It's been three days since I joined the device. And I can see that the battery status of the device was only updated three days ago (when it was first joined).

javicalle commented 1 year ago

Which coordinator do you have? It seems that there are some issues with some of the new devices: https://github.com/zigpy/zha-device-handlers/issues/1897#issuecomment-1304886271

tutivog commented 1 year ago

Which coordinator do you have? It seems that there are some issues with some of the new devices: #1897 (comment)

I use sonoff dongle-P as coordinator.

javicalle commented 1 year ago

Don't seems to be a coordinator firmware problem.

It's been three days since I joined the device. And I can see that the battery status of the device was only updated three days ago (when it was first joined).

That seems a pairing issue. Are you pressing the button every second while pairing your device to keep it awake?

tutivog commented 1 year ago

. Are you pressing the button every second while pairing your device to keep it awake?

Yes I am. Tried to repair the device again but the issues remain.

javicalle commented 1 year ago

I'm out of ideas. @TheJulianJES sorry for ping you directly but any thoughts on this issue?

TheJulianJES commented 1 year ago

So I changed line 60 of remote_e1.py to "lumi.remote.acn007" in order to have the quirk to successfully bind to my device. After restarting home assistant server, I rejoined the device. Some of the status of the device now seems to be correctly read by the ZHA handler:

  1. So the device becoming unavailable is no longer an issue?

It's been three days since I joined the device. And I can see that the battery status of the device was only updated three days ago (when it was first joined).

The time doesn't update if the same battery value is re-sent. So just by looking at this value, we don't really know if there are any connection problems.

  1. What Z-Stack firmware are you running on your Sonoff Dongle-P coordinator? (should be written to the HA logs on startup)

  2. Can you read any attributes on the device (using the "Manage Zigbee device" -> "Clusters" dialog)? If so, try reading the operation_mode attribute on the OppleCluster while the quirk is updated to also apply on that device. You might need to press the button on the device briefly after you've sent the "Get Zigbee attribute" command using the HA UI.

Relevant code for the H1 remote about what 0/1 mean for the operation_mode attribute: https://github.com/zigpy/zha-device-handlers/blob/ad2eba0de34f68dcd6204aa4119387f800d79ec1/zhaquirks/xiaomi/aqara/remote_h1.py#L60-L71

tutivog commented 1 year ago

So I changed line 60 of remote_e1.py to "lumi.remote.acn007" in order to have the quirk to successfully bind to my device. After restarting home assistant server, I rejoined the device. Some of the status of the device now seems to be correctly read by the ZHA handler:

  1. So the device becoming unavailable is no longer an issue?

It's been three days since I joined the device. And I can see that the battery status of the device was only updated three days ago (when it was first joined).

The time doesn't update if the same battery value is re-sent. So just by looking at this value, we don't really know if there are any connection problems.

  1. What Z-Stack firmware are you running on your Sonoff Dongle-P coordinator? (should be written to the HA logs on startup)
  2. Can you read any attributes on the device (using the "Manage Zigbee device" -> "Clusters" dialog)? If so, try reading the operation_mode attribute on the OppleCluster while the quirk is updated to also apply on that device. You might need to press the button on the device briefly after you've sent the "Get Zigbee attribute" command using the HA UI.

Relevant code for the H1 remote about what 0/1 mean for the operation_mode attribute:

https://github.com/zigpy/zha-device-handlers/blob/ad2eba0de34f68dcd6204aa4119387f800d79ec1/zhaquirks/xiaomi/aqara/remote_h1.py#L60-L71

Thanks for your attention with this issue. I have followed your instructions and here are the results:

  1. about the device becoming "unavailable," the actual issue seems a little bit complex. It is true that in the home assistant ZHA page there is no longer any mention that the device is "offline." If that is what you are referring to, I think it is true that the issue is solved. But while ZHA no longer says the device is offline, it neither gets any kind of update from the device as well. At least from what I could gather from the user interface, there hasn't been any communication between the hub since the device is paired.

  2. I wasn't able to get a hub firmware info from the logs but I got a screenshot from the Visualization tab in Zigbee, I hope this could give you the information you need: image

  3. And about the attributes, sorry, I wasn't able to read ANY atrributes on the device. I also tried to read immediately after I paried the device and keep the device awake by pressing the button. But there is no luck.

magfro commented 1 year ago

I am also not able to use this remote together with SkyConnect (ZHA). It pairs ok but doesn't show battery and I can't read the clicks in zha_event.

//Magnus

Berq343 commented 1 year ago

Same here. I use Home Assistant Yellow (ZHA)

TobbeJ commented 1 year ago

Any update on this? i can get the lumi.remote.acn007 to show up in deconz but not the phoscon web gui and it never shows up in home assistant.

kmg454 commented 1 year ago

This switch seems only work with the Aqara hub

TobbeJ commented 1 year ago

well, yes but it does show up in deconz even after it claims to have failed the pairing but not as a proper device and definitely not in phoscon web gui. in this "paired but not really working" state i do get a message in the log every time i press the button so it is clearly receiving data from the button.

every button press results in this line added to the log: 14:00:50:270 ZCL attribute report 0x54EF4410006B50ED for cluster: 0x0012, ep: 0x01, frame control: 0x18, mfcode: 0x0000

an ugly hack would be to create a script that reads the log and then looks for this line and does something useful.

github-actions[bot] commented 9 months ago

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates. Please make sure to update to the latest version and check if that solves the issue. Let us know if that works for you by adding a comment 👍 This issue has now been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.

TobbeJ commented 9 months ago

this is still broken

andyhomeautomation commented 6 months ago

Any solution to this device problem?

Rausner commented 6 months ago

Seems to be non-functioning still. I have the same issue and should've done my research better before I wasted 15 euro on this crap device!

ryantang30 commented 5 months ago

Hi all, I managed to get the WXKG20LM working with all the functionality including single press, double press and long press, with a custom ZHA quirk. I noticed that the device input and output clusters (and also functionality) were similar to the Aqara E1 Single Rocker Switch. So I basically just copied the quirk for it and only changed the MODEL_INFO section to "lumi.remote.acn007", install the custom quirk, restart the HA and re-pair the device and it now works with all the automations!

Below are the steps that I took to do it, hope it helps someone!

  1. Remove the device on Home Assistant (HA) if you have previously attempted to pair it
  2. Open a terminal to your HA instance. Eg. SSH in or use the Terminal add-on for HA
  3. Navigate to the /config folder cd config
  4. Create the directory custom_zha_quirks by running the command mkdir custom_zha_quirks (If you already have a custom quirks directory, then navigate there)
  5. Change directory and create a Python file for the quirk cd custom_zha_quirks nano aqara_e1_mini_switch.py (actually any filename will work here)
  6. Copy the following content to the file:
    
    from zigpy.profiles import zha
    from zigpy.zcl.clusters.general import (
    Basic,
    Identify,
    MultistateInput,
    OnOff,
    Ota,
    PowerConfiguration,
    )

from zhaquirks.const import ( ALT_DOUBLE_PRESS, ALT_SHORT_PRESS, BUTTON, COMMAND, COMMAND_OFF, COMMAND_TOGGLE, DEVICE_TYPE, DOUBLE_PRESS, ENDPOINTS, INPUT_CLUSTERS, LEFT, LONG_PRESS, MODELS_INFO, OUTPUT_CLUSTERS, PROFILE_ID, RIGHT, SHORT_PRESS, TRIPLE_PRESS, ) from zhaquirks.xiaomi import LUMI, BasicCluster, XiaomiCustomDevice from zhaquirks.xiaomi.aqara.opple_remote import ( COMMAND_1_DOUBLE, COMMAND_1_HOLD, COMMAND_1_SINGLE, COMMAND_1_TRIPLE, COMMAND_2_DOUBLE, COMMAND_2_HOLD, COMMAND_2_SINGLE, COMMAND_2_TRIPLE, COMMAND_3_DOUBLE, COMMAND_3_HOLD, COMMAND_3_SINGLE, COMMAND_3_TRIPLE, MultistateInputCluster, ) from zhaquirks.xiaomi.aqara.remote_h1 import ( AqaraRemoteManuSpecificCluster, PowerConfigurationClusterH1Remote, )

BOTH_BUTTONS = "both_buttons"

class AqaraE1MiniSwitchSingleRocker(XiaomiCustomDevice): """Custom device representing Aqara E1 Wireless Mini Switch """

signature = {
    MODELS_INFO: [(LUMI, "lumi.remote.acn007")],
    ENDPOINTS: {
        1: {
            # SizePrefixedSimpleDescriptor(
            #   endpoint=1, profile=260, device_type=0,
            #   input_clusters=["0x0000", "0x0001", "0x0003", "0x0012", "0xfcc0"],
            #   output_clusters=["0x0003", "0x0006", "0x0019"])
            PROFILE_ID: zha.PROFILE_ID,
            DEVICE_TYPE: zha.DeviceType.ON_OFF_SWITCH,
            INPUT_CLUSTERS: [
                Basic.cluster_id,
                PowerConfiguration.cluster_id,
                Identify.cluster_id,
                MultistateInput.cluster_id,
                AqaraRemoteManuSpecificCluster.cluster_id,
            ],
            OUTPUT_CLUSTERS: [
                Identify.cluster_id,
                OnOff.cluster_id,
                Ota.cluster_id,
            ],
        },
    },
}
replacement = {
    ENDPOINTS: {
        1: {
            PROFILE_ID: zha.PROFILE_ID,
            DEVICE_TYPE: zha.DeviceType.ON_OFF_SWITCH,
            INPUT_CLUSTERS: [
                BasicCluster,
                Identify.cluster_id,
                PowerConfigurationClusterH1Remote,
                MultistateInputCluster,
                AqaraRemoteManuSpecificCluster,
            ],
            OUTPUT_CLUSTERS: [
                Identify.cluster_id,
                OnOff.cluster_id,
                Ota.cluster_id,
            ],
        },
    }
}
device_automation_triggers = {
    # triggers when operation_mode == event
    # the button doesn't send an release event after hold
    (SHORT_PRESS, LEFT): {COMMAND: COMMAND_1_SINGLE},
    (DOUBLE_PRESS, LEFT): {COMMAND: COMMAND_1_DOUBLE},
    (TRIPLE_PRESS, LEFT): {COMMAND: COMMAND_1_TRIPLE},
    (LONG_PRESS, LEFT): {COMMAND: COMMAND_1_HOLD},
    # triggers when operation_mode == command
    (ALT_SHORT_PRESS, BUTTON): {COMMAND: COMMAND_TOGGLE},
    (ALT_DOUBLE_PRESS, BUTTON): {COMMAND: COMMAND_OFF},
}
7. Save and exit nano editor ( Ctrl-X, Y )
8. Open the HA configuration file `nano /config/configuration.yaml`
9. Add to the bottom of the file the following (Change the path if your custom quirk directory is different):

zha: custom_quirks_path: /config/custom_zha_quirks/


10. Save and exit nano editor ( Ctrl-X, Y )
11. Restart HA (Settings > System > Power Button > Restart Home Assistant)
12. Add device again and ZHA will automatically use the custom quirk for this device ID over the built in one which was having issues. 

@tutivog @magfro @Berq343 @TobbeJ @kmg454 @andyhomeautomation @Rausner 
TobbeJ commented 2 weeks ago

took a while to get around to testing this, since it never worked with zha i moved the button to another controller (and location) using z2m instead but i have now moved it back. i tested this and i can see single and double press events being triggered and i can setup automations to make use of it.

@ryantang30 thanks, this works perfectly.

one tiny issue is that the one and only button shows up as "Left" in the ui when creating automations. but it doesn't matter much since it works and does what i want

much better to use this button with the new quirk than the zigbee green power based switch i used before it was nearly impossible to pair even with a controller software that supports it (zha does not) it broke a long time ago. (zgp devices is paired to another device that acts like a proxy which makes them very wiered)