Support Fire Angel Zigbee Module (P-LINE)

[ebaauw]

This PR does two things:

1. Expose the Zone Type attribute 0x0001 of IAS Zone cluster 0x0500 for matchexpr, cf. the work done in Expose OTA file version for matchexpr #7642 for OTA File Version;
2. Add support for the Fire Angel Smoke Alarm (ST-630-DET) and Carbon Monoxide Alarm (ZBCO-AE-10X-EUR) equipped with the Fire Angel Zigbee Module (P-LINE), see FireAngel AngelEye Carbon Monoxide Alarm + ZB-Module (ZBCO-AE-10X-EUR) #7938, AngelEye FireAngel Zigbee Module #6111, Fireangel ZB-Module #6545.

Ad 1) I changed the following:

• Define RAttrZoneType for /attr/zonetype, based on 0x0500/0x0001;
• Write the value of 0x0500/0x0001 to the zcl_values table in the database;
• Add RAttrZoneType to Device;
• Read the value of 0x0500/0x0001 into the Device RAttrZoneType on device DDF initialisation;
• Expose RAtttrZoneType on lights and sensors API endpoints. Not sure if we want or need this. It was already included in sensors web socket notifications out of the box. Note that this attribute doesn't need to be defined on any of the subdevices for the matchexpr to work, since the C++ code already added it to the Device.

Note that I didn't add a hook to reload the DDF when 0x0500/0x0001 is read (and changes value), due to the recent issues with the API ignoring messages from devices after DDFs are re-initialised.

Ad 2) I added DDFs for:

• Smoke alarm, based on matchexpr for Zone Type having value Fire sensor;
• CO alarm, based on matchexpr for Zone Type having value Carbon Monoxide (CO) sensor;
• A generic alarm device (ZHAAlarm), based on matchexpr for other Zone Type values.

Note the Zigbee module can also be installed in heat alarms, but I don't know what Zone Type these use. Could very well be Fire sensor.
On initial pairing, you should get a ZHAAlarm sensors resource; after reading IAS Zone and restarting deCONZ, this changes to a ZHAFire or ZHACarbonMonoxide.

{
  "config": {
    "battery": 91,
    "on": true,
    "pending": [],
    "reachable": true
  },
  "ep": 1,
  "etag": "d790c79357ddb6e33be69053fb9ca957",
  "lastannounced": null,
  "lastseen": "2024-09-25T09:17Z",
  "manufacturername": "Fireangel",
  "modelid": "Alarm_SD_Device",
  "name": "Smoke Alarm",
  "state": {
    "fire": false,
    "lastupdated": "2024-09-25T09:17:22.956",
    "lowbattery": false,
    "tampered": false,
    "test": false
  },
  "swversion": "3.1.8.14",
  "type": "ZHAFire",
  "uniqueid": "00:15:5f:00:dc:c8:ea:77-01-0500"
}

The only differences between the different devices are the type (ZHAAlarm, ZHAFire, ZHACarbonMonoxide) and the state attribute for an alarm (alarm, fire, carbonmonoxide).
I'm polling the alarm every 5 minutes for the Zone State, as the module doesn't support Supervision Reports nor attribute reporting for this attribute. This should keep state/lastupdated fairly current, but I need to assess the impact on battey usage.
state/tampered is set shortly after the smoke alarm is removed from it's base plate. It takes a couple of seconds before the Zone Status Change Notification is sent. [Note to self: check if CO alarm also supports this].
state/test briefly switches to true when pressing the device button, activating a self-test (cover your ears!).
The Zigbee module only reports voltage if its (user replaceable) battery. This should be reported every 12 hours out of the box. config/battery extrapolates the voltage linearly from documented range of 1.9V ... 3.0V to 0% ... 100%. Note that there's no indication for the internal, non-replaceable battery of the sensor.
swversion reports the firmware version of the Zigbee module, based on the File Version of the OTAU cluster.

Additionally, there's a Warning Device lights resource.

{
  "capabilities": {
    "alerts": [
      "none",
      "select",
      "lselect"
    ]
  },
  "etag": "4d11a9ea58d1d06dffb73e74c989685f",
  "hascolor": false,
  "lastannounced": null,
  "lastseen": "2024-09-25T09:17Z",
  "manufacturername": "Fireangel",
  "modelid": "Alarm_SD_Device",
  "name": "Smoke Alarm",
  "state": {
    "alert": "none",
    "reachable": true
  },
  "swversion": "3.1.8.14",
  "type": "Warning device",
  "uniqueid": "00:15:5f:00:dc:c8:ea:77-01"
}

state/alert can be used to activate the siren (cover your ears!). Note the module only supports Sqawk, so you only get a short alarm.

[github-actions]

Hey @ebaauw, thanks for your pull request!

Tip

Modified bundles can be downloaded here.

DDB changes

Modified

• fireangel/co_alarm.json : Zigbee Radio Module (P-LINE) ✔️

• fireangel/smoke_alarm.json : Zigbee Radio Module (P-LINE) ✔️

• fireangel/generic_alarm.json : Zigbee Radio Module (P-LINE) ✔️

Validation

Tip

Everything is fine !

_{🕠 Updated for commit 1fba9f0}

[manup]

This works but you may consider just using the normal item based value storage which doesn't require extra code.

The reason I used this in the OTA version is to have the value in the database also for non DDF devices, so at the time they get a DDF the value is already available. Not sure if we need that here too.

[ebaauw]

After some testing, I think we do need the RAttrZoneType ResourceItem on the Device, but there's no need to save its value explicitly to ZCL_VALUES. Still no need to have the item on the lights or sensors resource.

[manup]

Just noticed this one, I'm not too happy about adding RAttrZoneType in this place and to every device.

I think it's okay to get the PR up and running, but ideally we can mark items in sub-resources to be cascaded to the parent (aka Device*) in future.

[ebaauw]

I think there's a bit of a catch 22 there? We only have the subdevices once the DDF has been matched, but we need the zone type to match the DDF. We might do a check that it gets added only to devices with the IAS Zone cluster?

[manup]

That's a good idea, the following should do the trick in device.cpp and gets executed right before the DDF is matched but also after the Simple Descriptors have been read.

void DEV_GetDeviceDescriptionHandler(Device *device, const Event &event)
{
    DevicePrivate *d = device->d;

    if (event.what() == REventStateEnter)
    {
        // if there is a IAS Zone Cluster add the RAttrZoneType
        if (DEV_GetSimpleDescriptorForServerCluster(device, 0x0500_clid))
        {
            device->addItem(DataTypeUInt16, RAttrZoneType);
        }

        DEV_EnqueueEvent(device, REventDDFInitRequest);
    }
    ...

[ebaauw]

Unfortunately, this doesn't work. I think the value of RAttrZoneType is not persisted across restarts. After re-adding the logic to persist zone type in ZCL_VALUES, it still doesn't work, as the attempted restore happens before the state enter event, which adds the item. When adding the item on restore, it works!

but there's no need to save its value explicitly to ZCL_VALUES

I can no longer reproduce this. Maybe it worked, because at that time the resource item was still defined on the subdevices, or simply because the value was still in ZCL_VALUES. Or maybe I simply screwed up and tested against the wrong build. When manually removing the value from the database, the sensors resource reverts to ZHAAlarm.

[manup]

Tested in my setup with a breakpoint in debugger, adding the zone type item works.

[github-actions]

This pull request is now merged. The new DDB files have been uploaded to the store.

DDB Files

Modified

• fireangel/smoke_alarm.json : Zigbee Radio Module (P-LINE) : with hash (d8c76b70c8)

• fireangel/co_alarm.json : Zigbee Radio Module (P-LINE) : with hash (e9f621a391)

• fireangel/generic_alarm.json : Zigbee Radio Module (P-LINE) : with hash (8e956116e6)

_{🕤 Updated for commit ae412b4}