Refactor Aqara remote switch H1 quirk to v2 format to support all variants

[jeverley]

Proposed change

This PR refactors the existing Aqara H1 quirk into the new v2 structure (originally undertaken as I'd encountered a new device variant for the double switch):

"signature": {
  "node_descriptor": {
    "logical_type": 2,
    "complex_descriptor_available": 0,
    "user_descriptor_available": 0,
    "reserved": 0,
    "aps_flags": 0,
    "frequency_band": 8,
    "mac_capability_flags": 128,
    "manufacturer_code": 4447,
    "maximum_buffer_size": 127,
    "maximum_incoming_transfer_size": 100,
    "server_mask": 11264,
    "maximum_outgoing_transfer_size": 100,
    "descriptor_capability_field": 0
  },
  "endpoints": {
    "1": {
      "profile_id": "0x0104",
      "device_type": "0x0103",
      "input_clusters": [
        "0x0000",
        "0x0001",
        "0x0003"
      ],
      "output_clusters": [
        "0x0003",
        "0x0006"
      ]
    },
    "2": {
      "profile_id": "0x0104",
      "device_type": "0x0103",
      "input_clusters": [
        "0x0003"
      ],
      "output_clusters": [
        "0x0003",
        "0x0006"
      ]
    },
    "3": {
      "profile_id": "0x0104",
      "device_type": "0x0103",
      "input_clusters": [
        "0x0003"
      ],
      "output_clusters": [
        "0x0006"
      ]
    },
    "4": {
      "profile_id": "",
      "device_type": "",
      "input_clusters": [],
      "output_clusters": []
    },
    "5": {
      "profile_id": "",
      "device_type": "",
      "input_clusters": [],
      "output_clusters": []
    },
    "6": {
      "profile_id": "",
      "device_type": "",
      "input_clusters": [],
      "output_clusters": []
    }
  },
  "manufacturer": "LUMI",
  "model": "lumi.remote.b28ac1"
},

Additional information

I've two switches, one of which seems to be intermittently affected by the issue home-assistant/core#127874 whereby it's recognised and works correctly after initial pairing, but following a restart of the ZHA integration or Home Assistant it's recognised as unk_manufacturer, unk_model and no longer functions.

Update:
I haven't encountered the issue above in the last week with the new v2 quirk (following multiple reboots and zha reloads).

Checklist

• The changes are tested and work correctly
• pre-commit checks pass / the code has been formatted using Black
• Tests have been added to verify that the new code works

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 89.78%. Comparing base (97413e3) to head (39b6eec).

Additional details and impacted files

@@            Coverage Diff             @@
##              dev    #3564      +/-   ##
==========================================
- Coverage   89.79%   89.78%   -0.01%     
==========================================
  Files         323      323              
  Lines       10414    10409       -5     
==========================================
- Hits         9351     9346       -5     
  Misses       1063     1063              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[jeverley]

I'm re-implementing this as a v2 quirk to expose the configuration options as well as exploring whether this resolves the unknown device bug home-assistant/core#127874 - we shall see.

[TheJulianJES]

Are we adding all these Identify clusters because the signature reported by the device is sometimes incomplete?
Is there any real function for these on endpoint 2 and 3 (or the client clusters)? If not, I wonder if we can just not add them?

[jeverley]

I've simplified this in 76158d1 to just add the first on endpoint 1 (it seems to be the only one that actually responds).

[TheJulianJES]

IIRC, if a cluster is ever reported by the device, we should use .replaces. It also removes the existing cluster with the same cluster id, should there be one already. It should not error out if there is no cluster with that ID.
Then, replaces also adds the custom cluster.

I don't see it in the signature from the v1 quirks, but I think we should still consider using replaces here, as it's a real cluster present on the device, just not exposed in the signature (by the device).
I guess that could theoretically change. With adds, we only add the custom cluster if one doesn't exist with the same cluster ID already (again, IIRC). In that case, we would not add the attribute definitions.

I think we should just use replaces for this one.

[jeverley]

Agreed, using replace should shield us from future variants which do expose the cluster.
Amended in 76158d1

[TheJulianJES]

Hmm, I guess the same might apply here. These are real clusters, just not exposed in the signature by the current device firmware.
I'd also consider using replaces for these.

[jeverley]

Some variants to expose the cluster in their signature, definitely correct to use replace.
Amended in 76158d1

[TheJulianJES]

These are probably fine to leave as-is. If they're not exposed by the device signature, we add them. If they are, we don't add them, but it's still the same cluster, as it's the default ZCL OnOff one.
I believe these clusters are also used if bound to another device when the remote is in that mode.

[TheJulianJES]

Due to the current implementation we have for friendly_name, this might break existing blueprints.
I wonder if we should comment it out for now (until the ZHA implementation is changed?).

[jeverley]

Have commented these out for now in 76158d1

[TheJulianJES]

Nice work!