dresden-elektronik / deconz-rest-plugin

deCONZ REST-API plugin to control ZigBee devices
BSD 3-Clause "New" or "Revised" License
1.9k stars 498 forks source link

FireAngel AngelEye Carbon Monoxide Alarm + ZB-Module (ZBCO-AE-10X-EUR) #7938

Open ebaauw opened 5 days ago

ebaauw commented 5 days ago

Is there already an existing issue for this?

Product name

AngelEye Carbon Monoxide Alarm + ZB-Module (ZBCO-AE-10X-EUR)

Manufacturer

Fireangel

Model identifier

Alarm_SD_Device

Device type to add

Sensor

Node info

Screenshot 2024-09-22 at 17 37 36

Endpoints and clusters

Screenshot 2024-09-22 at 17 39 11

Basic

Screenshot 2024-09-22 at 17 37 21

Further relevant clusters

Power Configuration

Screenshot 2024-09-22 at 17 45 55

Poll Control

Screenshot 2024-09-22 at 17 39 29

IAS Zone

Screenshot 2024-09-22 at 17 38 13

IAS WD

Screenshot 2024-09-22 at 17 38 42
ebaauw commented 5 days ago

See https://www.angeleye.nl/producten/zbst-ae-630eur-zbco-ae-10x-eur-zbht-ae630-eur-copy. I got the sensor at the local DYI store, https://www.karwei.nl/assortiment/angeleye-koolmonoxidemelder-zigbee-smart-home-10-jaar-batterij/p/B131917. The sensor itself contains a non-replaceable battery that should last 10 years (which is probably the life time of the sensor hardware as well). It contains a detachable Zigbee module, with a replaceable CR2 battery. According to module's manual, it can be used with other sensors as well, see also #6111 and #6545.

I just paired the device with deCONZ and wrote the coordinator's MAC address to the _IAS_CIEAddress attribute in the IAS Zone cluster. I seem to remember, deCONZ would assign Zone ID 100, but it reports 0. The legacy code exposes the IAS WD cluster as a lights resource; the IAS Zone isn't exposed as sensors resource, since the device is not whitelisted.

{
  "capabilities": {
    "alerts": [
      "none",
      "select",
      "lselect"
    ]
  },
  "config": {
    "groups": [
      "0"
    ]
  },
  "etag": "662ccd3b9fa9b237c3b04710bd561a50",
  "hascolor": false,
  "lastannounced": null,
  "lastseen": "2024-09-22T15:36Z",
  "manufacturername": "Fireangel",
  "modelid": "Alarm_SD_Device",
  "name": "Laundry Room CO",
  "state": {
    "alert": "none",
    "reachable": true
  },
  "swversion": "20201218",
  "type": "Warning device",
  "uniqueid": "00:15:5f:00:dc:ba:2f:83-01"
}

It might be challenging to create a DDF for this device, as the same Zigbee module might be used for different types of sensors. We would need to check the Zone Type to know what sensors resource type to create, but that's only populated after enrolling the device, which would only happen once a DDF has been matched. I'm tempted to whitelist the device in the legacy code. I think that should handle the different sensor types without any issue. @manup @SwoopX any ideas here?

The device is a light sleeper, polling every 7 seconds; I didn't change any Poll Control settings.

The Zone Status indicates the device sends Restore reports, but no Supervision reports. Need to see if it accepts attribute reporting for periodic reports. The attribute is not reportable, so we would have to poll the device for periodic updates.

The siren can be activated through the IAS WD cluster (yeah!), but I only managed to do that using the Squawk command. Not sure if it doesn't support Start Warning, or if I simply haven't yet found the magic combination of parameters. In the first case, we need some hack to activate the siren from the API, as setting "alert" normally sends a Start Warning.

I suspect the Power Configuration cluster reports the replaceable battery of the Zigbee module.

SwoopX commented 5 days ago

That device is interesting and indeed tricky to handle. If the zone type is just populated after enrollment, I'm not sure if we could even nail that down with legacy code? That somehow feels like a major show stopper 🤔

Just as a side note: I made the alarm item fit for DDF, so you can assign whatever command you like. Check out the Develco smoke detector.

ebaauw commented 3 days ago

if the zone type is just populated after enrollment

I stand corrected: it is populated alright, even before enrollment. Got a fire sensor as well, just to test the differences. Other than the Zone Type, I see no differences is how the Zigbee module exposes itself. So if we can somehow use that attribute in a matchexpr we're OK.

Just as a side note: I made the alarm item fit for DDF, so you can assign whatever command you like. Check out the Develco smoke detector.

Brilliant. I'll use that to send Sqawk.