Skip to content

Alarm systems and IAS ACE devices #8141

@ebaauw

Description

@ebaauw

Does the issue really belong here?

  • I definitively want to report a bug within deCONZ or its REST-API

Is there already an existing issue for this?

  • I have searched the existing issues and there is none for the bug at hand

Describe the bug

Looking into alarm systems (at the request of one of my Homebridge deCONZ users), I found a number of bugs, inconsistencies and shortcomings. I'll use this issue to document them, hopefully being able to submit one or more PRs to address these.

Bugs

  1. The API for /alarmsystems doesn't report errors correctly.
  2. The API allows linking unsupported devices, i.e. devices that would never trigger an alarm.
  3. The web sockets notifications for /alarmsystems don't honour websocketnotifyall.
  4. Currently supported IAS ACE devices expose IAS Zone (0x0500) and IAS ACE (0x0501) on a single ZHAAncillaryControl resource. This causes state/lastupdated to be updated when the IAS Zone sends a supervision report, causing API clients to see ghost button presses.
  5. The alarm system doesn't send Panel Status Changed commands to linked IAS ACE devices when its state changes. Instead, it relies on the IAS ACE device to issue a Panel Status Request. I find the frient Intelligent Keypad only sends this command when it's woken up by proximity or pressing a button, not even periodically. Consequenly, the panel will not reflect status changed caused by others, like the alarm triggering, entry delays, exit delays when the alarm system is armed through the API or by another linked IAS ACE device. I think this is the cause of Keypad status is not updated if alarm system state is changed via API #5809.
  6. As ancillary control device implements the client IAS ACE cluster, it has no persistent state. Like state/buttonevent for a ZHASwitch, state/action reflects the last button pressed (see also 4). The state/panel and state/seconds_remaining items are copies of the corresponding state items of the alarm system, not state items of the control device. In particular, state/lastupdated shouldn't be (and, luckily, currently isn't) be updated when any of these items changes.
  7. The use of ZHAAncillaryControl devices is limited to alarm systems. The panel items, state/panel and state/seconds_remaining cannot be updated directly through the API (but they can be updated through the GUI by sending a Panel Status Changed command). The entered PIN code is not exposed (unlike Z2M).

Omissions

  1. The alarm system does not support the following sensors (corresponding to IAS Zone devices): ZHAAlarm, ZHACarbonMonoxide, ZHAFire, ZHAWater) and doesn't trigger alarm on the associated items RStateAlarm, RStateCarbonMonoxide, RStateFire, RStateWater. Additionally it doesn't trigger the alarm on RStateTampered and RStateTest.
  2. The alarm system doesn't support other sensors that report a measured value (like ZHACarbonDioxide, but also ZHATemperature, ZHAHumudiy, etc). However, for these we would need a configurable range of "normal" values. The alarm would trigger when the measured value falls outside this range. Note that you would want a range instead of a threshold, e.g. to check that the fridge doesn't get too warm.
  3. The alarm system doesn't support linking IAS WD devices. Consequently, you need to setup rules to sound the siren when the alarm has been triggered.

Steps to reproduce the behavior

Ad 1 - wrong API error reporting:

When specifying an invalid attribute:

$ deconz put -v /alarmsystems/1/config '{"code": "1234"}'
deconz put: request 1: PUT /alarmsystems/1/config {"code":"1234"}
deconz put: error: request 1: http status 404 Not Found

When specifying an invalid value:

$ deconz put -v /alarmsystems/1/config '{"armed_away_exit_delay": "aap"}'
deconz put: request 1: PUT /alarmsystems/1/config {"armed_away_exit_delay":"aap"}
deconz put: error: request 1: http status 503 Service Unavailable

Expected behavior

Ad 1 - wrong API error reporting:

When specifying an invalid attribute, the API should return HTTP status 200 OK with error(s) in the response body, like e.g.:

$ deconz put -v /sensors/1/config '{"code": "1234"}'
deconz put: request 1: PUT /sensors/1/config {"code":"1234"}
deconz put: warning: request 1: /sensors/1/config/code: api error 6: parameter, code, not available
[
  {
    "error": {
      "address": "/sensors/1/config/code",
      "description": "parameter, code, not available",
      "type": 6
    }
  }
]

When specifying an invalid value, the API should return HTTP status 200 OK with errors in the response body, like e.g.:

$ deconz put -v /alarmsystems/1/config '{"code0": "aap"}'
deconz put: request 1: PUT /alarmsystems/1/config {"code0":"aap"}
deconz put: warning: request 1: /alarmsystems/1/config/code0: api error 7: invalid value, aap, for parameter, code0
[
  {
    "error": {
      "address": "/alarmsystems/1/config/code0",
      "description": "invalid value, aap, for parameter, code0",
      "type": 7
    }
  }
]

Ad 4 IAS ACE devices

The IAS Zone should be exposed as a separate ZHAAlarm resource. The associated items, state/tampered, state/lowbattery , config/enrolled, and config/pending should be removed from the ZHAAnciallaryControl. The DDF validator needs to be changed, as it currently treats these attributes as mandatory for ZHAAnciallaryControl.

Ad 5 Panel Status Change

The alarm system should send Panel Status Change notification to each linked IAS ACE device when its state/armstate changes. There's no need for this, when only state/seconds_remaining changes, as the IAS ACE device counts down by itself.

Ad 6 Panel state

state/panel should be exposed as config/armstate and state/seconds_remaining as config/seconds_remaining.

Ad 7. Limited use of IAS ACE devices

The panel attributes, config/armstate and config/seconds_remaining sould be updatable over the API, resulting in a Panel State Change command, so the IAS ACE device can also be used independently from an alarm system.
The entered code might be exposed as state/code.

Screenshots

n/a

Environment

  • Host system: all
  • Running method: all
  • Firmware version: all
  • deCONZ version (not Home assistant Addon version!): 2.29.2 (and others)
  • Device: all
  • Do you use an USB extension cable: n/a
  • Is there any other USB or serial devices connected to the host system? If so: Which? n/a

deCONZ Logs

n/a

Additional context

For HomeKit support, see ebaauw/homebridge-deconz#246.

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions