[Device Support Request] Aqara T1 relay `lumi.switch.n0agl1`

[mbw2001]

Is your feature request related to a problem? Please describe. I have added the lumi.switch.n0agl1 to home assistant, it is a relay but identified as a lightbulb. As I am using it for a fan for the bathroom that is misleading. Secondly toggle from lovelace, doesn't work. PowerOff works, but PowerOn doesn't. I assume that is related to being identified as a lightbulb, but I don't know for sure. Sending zha_cluster_command with:

ieee: 'XXX'
endpoint_id: 1
cluster_id: 6
cluster_type: in
command: YYY
command_type: server

The the command being 1 to turn on and 0 to turn off works perfectly, but doesn't integrate well with the UI.

Describe the solution you'd like Providing a correct device type, and fixing the poweroff and power toggle functionality.

Device signature - this can be acquired by removing the device from ZHA and pairing it again from the add devices screen. Be sure to add the entire content of the log panel after pairing the device to a code block below this line.

{
  "node_descriptor": "NodeDescriptor(byte1=1, byte2=64, mac_capability_flags=142, manufacturer_code=4447, maximum_buffer_size=82, maximum_incoming_transfer_size=82, server_mask=11264, maximum_outgoing_transfer_size=82, descriptor_capability_field=0, *allocate_address=True, *complex_descriptor_available=False, *is_alternate_pan_coordinator=False, *is_coordinator=False, *is_end_device=False, *is_full_function_device=True, *is_mains_powered=True, *is_receiver_on_when_idle=True, *is_router=True, *is_security_capable=False, *is_valid=True, *logical_type=<LogicalType.Router: 1>, *user_descriptor_available=False)",
  "endpoints": {
    "1": {
      "profile_id": 260,
      "device_type": "0x0100",
      "in_clusters": [
        "0x0000",
        "0x0002",
        "0x0003",
        "0x0004",
        "0x0005",
        "0x0006",
        "0x0009",
        "0x000a",
        "0x0702",
        "0x0b04",
        "0xfcc0"
      ],
      "out_clusters": [
        "0x0019"
      ]
    },
    "21": {
      "profile_id": 260,
      "device_type": "0x0100",
      "in_clusters": [
        "0x000c"
      ],
      "out_clusters": []
    },
    "31": {
      "profile_id": 260,
      "device_type": "0x0100",
      "in_clusters": [
        "0x000c"
      ],
      "out_clusters": []
    },
    "41": {
      "profile_id": 260,
      "device_type": "0x0100",
      "in_clusters": [
        "0x0012"
      ],
      "out_clusters": []
    },
    "242": {
      "profile_id": 41440,
      "device_type": "0x0061",
      "in_clusters": [],
      "out_clusters": [
        "0x0021"
      ]
    }
  },
  "manufacturer": "LUMI",
  "model": "lumi.switch.n0agl1",
  "class": "zigpy.device.Device"
}

Additional context I have failed in actually making the quirk myself, but I got my HomeAssistant setup with the custom quirks folder, so I will happily test, and provide feedback and/or more information if needed.

[puddly]

The device type is ON_OFF_LIGHT = 0x0019 so that's right. It also has the following input clusters:

 0
 zigpy.zcl.clusters.general.DeviceTemperature,
 zigpy.zcl.clusters.general.Identify,
 zigpy.zcl.clusters.general.Groups,
 zigpy.zcl.clusters.general.Scenes,
 zigpy.zcl.clusters.general.OnOff,
 zigpy.zcl.clusters.general.Alarms,
 zigpy.zcl.clusters.general.Time,
 zigpy.zcl.clusters.smartenergy.Metering,
 zigpy.zcl.clusters.homeautomation.ElectricalMeasurement,
 64704

Can you enable https://www.home-assistant.io/integrations/zha/#debug-logging and post the section of your home-assistant.log file that contains you turning it both on and off a few times, noting which command worked? If it turns on it seems like it should turn off. Both should be done through the OnOff cluster.

[mbw2001]

Hi,

Thanks for the reply and sorry for the slow feedback!

Is there anything I can grep for in the logs, because enabling debug logs and tailing my logs is like watching the Matrix.

Pressing the switch in Lovelace shows:

2021-05-17 10:45:36 DEBUG (MainThread) [homeassistant.core] Bus:Handling <Event call_service[L]: domain=light, service=turn_on, service_data=entity_id=light.toilet_udsugning>
2021-05-17 10:45:36 DEBUG (MainThread) [homeassistant.components.zha.entity] light.toilet_udsugning: turned on: {}

I don't know if more relevant information can be found later in the logs as well? But I cannot see anything.

But the interface just toggles back to off and the switch doesn't activate.

If i turn it on using zigbee cluster command and use the interface to turn it off I get:

2021-05-17 10:52:31 DEBUG (MainThread) [homeassistant.components.zha.core.channels.base] [0xFCDF:1:0x0006]: executed 'off' command with args: '()' kwargs: '{}' result: [0, <Status.SUCCESS: 0>]
2021-05-17 10:52:31 DEBUG (MainThread) [homeassistant.components.zha.entity] light.toilet_udsugning: turned off: [0, <Status.SUCCESS: 0>]
2021-05-17 10:52:31 DEBUG (MainThread) [homeassistant.core] Bus:Handling <Event state_changed[L]: entity_id=light.toilet_udsugning, old_state=<state light.toilet_udsugning=on; supported_color_modes=['onoff'], color_mode=onoff, off_brightness=None, friendly_name=Toilet Udsugning, supported_features=8 @ 2021-05-17T10:52:14.573951+02:00>, new_state=<state light.toilet_udsugning=off; supported_color_modes=['onoff'], off_brightness=None, friendly_name=Toilet Udsugning, supported_features=8 @ 2021-05-17T10:52:31.457486+02:00>>
2021-05-17 10:52:31 DEBUG (MainThread) [zigpy_deconz.api] Command Command.aps_data_indication (1, 1)
2021-05-17 10:52:31 DEBUG (MainThread) [zigpy_deconz.api] APS data indication response: [30, <DeviceState.APSDE_DATA_REQUEST_SLOTS_AVAILABLE|2: 34>, <DeconzAddress address_mode=ADDRESS_MODE.NWK address=0x0000>, 1, <DeconzAddress address_mode=ADDRESS_MODE.NWK address=0xfcdf>, 1, 260, 6, b'\x08.\n\x00\x00\x10\x00', 0, 175, 223, 155, 56, 137, 0, -66]
2021-05-17 10:52:31 DEBUG (MainThread) [zigpy.zcl] [0xfcdf:1:0x0006] ZCL deserialize: <ZCLHeader frame_control=<FrameControl frame_type=GLOBAL_COMMAND manufacturer_specific=False is_reply=True disable_default_response=False> manufacturer=None tsn=46 command_id=Command.Report_Attributes>
2021-05-17 10:52:31 DEBUG (MainThread) [zigpy.zcl] [0xfcdf:1:0x0006] ZCL request 0x000a: [[Attribute(attrid=0, value=<TypeValue type=Bool, value=Bool.false>)]]
2021-05-17 10:52:31 DEBUG (MainThread) [zigpy.zcl] [0xfcdf:1:0x0006] Attribute report received: on_off=0
2021-05-17 10:52:31 DEBUG (MainThread) [zigpy_deconz.zigbee.application] Sending Zigbee request with tsn 46 under 159 request id, data: b'182e0b0a00'
2021-05-17 10:52:31 DEBUG (MainThread) [zigpy_deconz.api] 'aps_data_indication' response from <DeconzAddress address_mode=ADDRESS_MODE.NWK address=0xfcdf>, ep: 1, profile: 0x0104, cluster_id: 0x0006, data: b'082e0a00001000'
2021-05-17 10:52:31 DEBUG (MainThread) [zigpy_deconz.api] Command Command.aps_data_request (20, 159, 0, <DeconzAddressEndpoint address_mode=2 address=0xFCDF endpoint=1>, 260, 6, 1, b'\x18.\x0b\n\x00', 2, 0)
2021-05-17 10:52:31 DEBUG (MainThread) [zigpy_deconz.api] APS data request response: [2, <DeviceState.APSDE_DATA_REQUEST_SLOTS_AVAILABLE|2: 34>, 159]
2021-05-17 10:52:31 DEBUG (MainThread) [zigpy_deconz.api] Device state changed response: [<DeviceState.128|APSDE_DATA_REQUEST_SLOTS_AVAILABLE|APSDE_DATA_CONFIRM|2: 166>, 0]
2021-05-17 10:52:31 DEBUG (MainThread) [zigpy_deconz.api] Command Command.aps_data_confirm (0,)
2021-05-17 10:52:31 DEBUG (MainThread) [zigpy_deconz.api] APS data confirm response for request with id 159: 00
2021-05-17 10:52:31 DEBUG (MainThread) [zigpy_deconz.api] Request id: 0x9f 'aps_data_confirm' for <DeconzAddressEndpoint address_mode=ADDRESS_MODE.NWK address=0xfcdf endpoint=1>, status: 0x00

The device type is ON_OFF_LIGHT = 0x0019 so that's right.

That makes sense, but the device is a relay, so while it could technically be used to control a light, it can also be used for a million other things. So is there any way to force it to be seen as a normal switch?

[github-actions[bot]]

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.

[aeklo]

Unable to make this device work, even though it is supposed to be supported: https://zigbee.blakadder.com/Aqara_SSM-U01.html

The device is found and included, but shows up with an temperature entity instead of the switch, and no power sensors. Have tried deleting/re-adding lots of times, and it shows up the exact same way every time.

I added the exact same relay a couple of months ago, which worked perfectly, so I assume something has changed in ZigPy/ZHA maybe? The device signature for the successfully added, and the non-successful are different (see attached files). Any chance this could be resolved?

problem_device.txt successful_device.txt

[GingerAdonis]

I added the exact same relay a couple of months ago, which worked perfectly, so I assume something has changed in ZigPy/ZHA maybe? The device signature for the successfully added, and the non-successful are different (see attached files). Any chance this could be resolved?

This might be unrelated to your issue, but I'll give it a go anyways: I've noticed that Conbee II firmwares 26700700 and 26720700 also break new lumi.switch.n0agl1 entities when used with ZHA. Downgrading to firmware 26680700 fixed it for me. After adding the entities it's safe to upgrade to newer firmware.

[aeklo]

I have the Conbee 1, but this applies to this one as well. Downgraded to 26390500, and the device added successfully. Thanks!

[GingerAdonis]

This is probably still an issue on zigpy's end as this issue also (still) happens on a SONOFF ZigBee 3.0 USB Dongle Plus. Re-opening this issue would be great.

[2dom]

Indeed still an issue on SONOFF ZigBee 3.0 -

[w-marco]

Can confirm, just paired this exact module and only the two entities from above show up. no switch entity. weirdly, already paired modules still have the switch entity and work fine.

also using sonoff stick 3.0 plus (TI Chip)

Edit: FWIW downgrading the firmware to 20210120 helped and added all entities when re-pairing the device. I then upgraded the firmware again and all is fine. I did always shutdown HASS before changing firmware, then reboot the device so the stick initializes fresh, then start HASS again.

somehow it seems like conbee and the sonoff firmware use a similar library under the hood and zha in conjuction with some update there gets broken when interviewing the device.

[2dom]

Should we also put this in the Sonoff firmware issue tracker?

[puddly]

Until there's conclusive evidence that this is a firmware problem, I don't think that's necessary.

If you are able to reliably join and use the device with one firmware version and not the other, please upload detailed debug logs (https://www.home-assistant.io/integrations/zha/#debug-logging) of both cases.

[GingerAdonis]

Should we also put this in the Sonoff firmware issue tracker?

Don't think so as it also occurs using other sticks. Other solutions like Zigbee2mqtt aren't affected by this problem.

[johand77]

Any update on this? I just added this device to HA and did get identical results as @2dom.

[johand77]

I have the Conbee 1, but this applies to this one as well. Downgraded to 26390500, and the device added successfully. Thanks!

Downgrading indeed works, thank you!

[loclamor]

Thank you ! As of 7 Oct. 2022 downgradinding to 26680700 works as a charm (lastest firmware 26780700 does not work) : after remove device from zha and add it again, all entities show up !

[dontinelli]

I can confirm both the issue with the latest firmware as well as the workaround with downgrade to firmware 26680700. One additional remark: under the latest firmware of Conbee II there were no updates on the energy consumption and the power. With the downgrade these both sensors again are updated. I therefore do not intend to update the firmware again until also this issue is solved.

[KaherdinTristan]

I too have the issue with HA, ZHA integration, Conbee 2 stick, and AQARA T1; Not showing the light switch in HA. I was on the latest Conbee 2 firmware; "deCONZ_ConBeeII_0x26780700.bin.GCF" when this occured.

[2dom]

Hm - any love for this issue. I would love to complete the cabling in my annex....

[AndersWestman]

Downgrading the firmware on the ConbeeII will put me between a rock and a hard place I'm afraid, as I need a newer firmware (minimum 266b0700 I believe) to get my lumi.plug.maeu01 with fw.0020 to work... See https://github.com/zigpy/zha-device-handlers/issues/1952

I had my lumi.switch.n0agl1 fully working until I upgraded my ConbeeII fw from 26580700 to 26780700 which solved one issue but created another one...

[GingerAdonis]

Downgrading the firmware on the ConbeeII will put me between a rock and a hard place I'm afraid, as I need a newer firmware (minimum 266b0700 I believe) to get my lumi.plug.maeu01 with fw.0020 to work... See #1952

The downgrade is just required while pairing the affected devices, afterwards you can restore to the desired firmware.

[AndersWestman]

The downgrade is just required while pairing the affected devices, afterwards you can restore your original firmware.

Ok, then I don't understand why my lumi.switch.n0agl1 stopped working. Well, it partly worked. The switch on/off still worked, but I did not got any updated measurements and assumed it was a result after the fw update. Mabey that's not the case? I tried to re-pair it, but are after that missing most entities as all other above...

[2dom]

OK ... here is how to fix this by hand:

• Back-up your HA
• Add your Lumi Switch as usual via ZHA integration
• Check device info for MAC address
• install SQLite Web from Addons and add /config/zigbee.db in configuration
• Find the table called "in_clusters_vX" where X is the highest number available
• execute query (insert your in_cluser table name and MAC address below): INSERT INTO "in_clusters_v11" (ieee, endpoint_id, cluster) VALUES('54:ef:44:10:00:15:a2:16','1','6')
• restart home assistant
• reconfigure device
• light switch should appear

[TheJulianJES]

From what I've read here, it seems like the device doesn't work properly when it receives Xiaomi manufacturer codes during pairing. The "standard" mode (OppleMode = 0) seems to work correctly with ZHA though.

@2dom Can you provide the device signature after you made the modifications? (Also, what coordinator and firmware version are you running?)

[400HPMustang]

From what I've read here, it seems like the device doesn't work properly when it receives Xiaomi manufacturer codes during pairing. The "standard" mode (OppleMode = 0) seems to work correctly with ZHA though.

@2dom Can you provide the device signature after you made the modifications? (Also, what coordinator and firmware version are you running?)

Not who you were asking BUT I arrived here with the same issue. I'm using a SkyConnect. Here is the device signature after I ran the SQL Query in the other comment.

{
  "node_descriptor": "NodeDescriptor(logical_type=<LogicalType.Router: 1>, complex_descriptor_available=0, user_descriptor_available=0, reserved=0, aps_flags=0, frequency_band=<FrequencyBand.Freq2400MHz: 8>, mac_capability_flags=<MACCapabilityFlags.AllocateAddress|RxOnWhenIdle|MainsPowered|FullFunctionDevice: 142>, manufacturer_code=4447, maximum_buffer_size=82, maximum_incoming_transfer_size=82, server_mask=11264, maximum_outgoing_transfer_size=82, descriptor_capability_field=<DescriptorCapability.NONE: 0>, *allocate_address=True, *is_alternate_pan_coordinator=False, *is_coordinator=False, *is_end_device=False, *is_full_function_device=True, *is_mains_powered=True, *is_receiver_on_when_idle=True, *is_router=True, *is_security_capable=False)",
  "endpoints": {
    "1": {
      "profile_id": 260,
      "device_type": "0x0100",
      "in_clusters": [
        "0x0000",
        "0x0002",
        "0x0003",
        "0x0004",
        "0x0005",
        "0x0006",
        "0x0009",
        "0x000a",
        "0xfcc0"
      ],
      "out_clusters": [
        "0x000a",
        "0x0019",
        "0xffff"
      ]
    },
    "21": {
      "profile_id": 260,
      "device_type": "0x0100",
      "in_clusters": [
        "0x000c"
      ],
      "out_clusters": []
    },
    "31": {
      "profile_id": 260,
      "device_type": "0x0100",
      "in_clusters": [
        "0x000c"
      ],
      "out_clusters": []
    },
    "41": {
      "profile_id": 260,
      "device_type": "0x0100",
      "in_clusters": [
        "0x0012"
      ],
      "out_clusters": []
    },
    "242": {
      "profile_id": 41440,
      "device_type": "0x0061",
      "in_clusters": [],
      "out_clusters": [
        "0x0021"
      ]
    }
  },
  "manufacturer": "LUMI",
  "model": "lumi.switch.n0agl1",
  "class": "zigpy.device.Device"

I can control the light, but the device temperature is incorrect and I have no power monitoring available. Not sure if it's possible to fix that or not? You folks are a lot smarter than I am.

[Gilles2senior]

Just installed one of those Xiaomi Aquara SSM-U01 which looks like a great device based on size and features. Unfortunately, similar to others, beyond switch command (as light) only device temperature appears with wrong value. Even though the power monitoring entities seem to be listed, value remains at 0.

[MarkuBu]

OK ... here is how to fix this by hand:

* Back-up your HA

* Add your Lumi Switch as usual via ZHA integration

* Check device info for MAC address

* install SQLite Web from Addons and add /config/zigbee.db in configuration

* Find the table called "in_clusters_vX" where X is the highest number available

* execute query (insert your in_cluser table name and MAC address below):
  INSERT INTO "in_clusters_v11" (ieee, endpoint_id, cluster)
  VALUES('54:ef:44:10:00:15:a2:16','1','6')

* restart home assistant

* reconfigure device

* light switch should appear

Does this also work with MariaDB?

I run into the same issue. Is there still no solution for this? I use ZHA and Skyconnect, so the Conbee workaround doesn't help me

[TheJulianJES]

• https://github.com/zigpy/zha-device-handlers/pull/2513

will change a few things for HA Core 2023.9.0. Please try the Home Assistant beta tomorrow with this relay and report any issues you might still have.

With this new quirk version, it's required/recommended to have an up-to-date coordinator. You might need to (remove and) re-pair the device. Power usage should work (except power factor). There may be further changes required for the quirk (adding OppleMode attribute and setting that to 1), but we'll see how far these changes bring us.

[TheJulianJES]

Can anyone confirm if the quirk introduced in HA 2023.9.0 improves things for this device? Are there any issues left?

[jsk-sct]

I tried to re-pair it and didn't get the new type switch (it remained as a light) but I had an old conbee stick (gen1) so I changed that to skyconnect and then it showed up as a switch in HA. Had some trouble with it not registering active power but after a few re-pairnings it now shows that too. So it seems to work fine but haven't tested completely yet.

[400HPMustang]

I can also confirm that the relays show up as switches now and the power monitoring works correctly