Expose zone faults to Home Assistant (DSC)

[rct]

[I'm not sure whether this issue should be against this library, the Home Assistant integration, or both]

Currently if there is a zone fault, such as RF heartbeats that haven't been received for long enough, that information doesn't appear to be available to home assistant.

Observations on current behavior, during an RF timeout:

• The keypad entity does have the attribute trouble: true but doesn't indicate what the problem is. There is no attribute for trouble with a zone.
• The panel changes the zone state to open when the zone fault occurs. That is reflected in the entity for the zone, and last_tripped_time is updated.
• There don't appear to be any attributes for the zone entity that would indicate trouble with the zone, tamper, or zone low battery in the case of a wireless sensor.
• verbose trouble status code 849 is set to 0x10. That bit is Zone fault according to the Envisalink docs.

I'm not sure what the best way to expose this to Home Assistant, some ideas include:

1. Additional zone entity attributes expose fault, tamper, low battery.

   (I'm assuming since there aren't currently attributes for tamper or battery that they aren't currently implemented at a zone level. There is a keypad attribute for bat_trouble. but I think that might be tied to the panel's backup battery rather than RF sensors. I haven't tested that so I could be wrong.

2. Additional keypad boolean attributes that cover the bits from verbose trouble status (849):

• 0x10 - Sensor/Zone Fault

• 0x20 - Sensor/Zone Tamper

• 0x40 - Sensor/Zone Low Battery

  On a related note, there don't appear to be keypad (partition) or panel level attributes for these other verbose trouble status bits:

• 0x01 - Service is Required

• 0x04 - Telephone Line Fault

• 0x08 - Failure to Communicate

• 0x80 - Loss of Time

One of the simplest things to do might be to expose the verbose_trouble_status byte as an attribute of either the keypad or panel. However there might be a catch that I don't think the Envisalink ever sends 849 00 to turn off all of the trouble bits. I think the verbose trouble status may only be valid when it is also sending 510/511 keypad LED state/keypad LED flash state.

I'll have to dig through my logs. I'm logging everything because I'm using Juggie's AlarmServer to be a proxy for the Envisalink. It gets around the single connection problem.

Edit: when trouble cleared, it didn't send a verbose trouble update, but did send 510 and 841 - to clear the trouble in addition to the 606 to clear the zone fault.

[rct]

An additional consideration:

When a wireless zone has missed checking in and the panel sets a zone fault, it also sets the state to “open”. This will cause any automations to fire in Home Assistant unintentionally.

The panel doesn’t generate any alarms even if it is armed because it knows the zone is “faulted”.

From a security perspective, setting the wireless sensor zone to “open” is preferable, rather than giving a false sense that the zone is “closed” and is secure when it’s state is unknown.

In Home Assistant, when a zone is faulted, it might be better to mark the binary sensor as unknown/unavailable. This would prevent false triggering of automations.

A note about DSC, wireless heartbeats, and declaring a zone faulted

DSC wireless sensors send a heartbeat message periodically every 60 to 84 minutes depending on device type.

The default settings for missed check ins is not to report it until the device hasn’t checked in for 24 hours. This prevents alarm companies from getting a lot of trouble reports from transient RF problems. However this givens users a false sense of security and reliability as there could be many periods when the wireles device can’t be reliably received, but no notice is generated.

If you have system programming access (you know the installer code) you can decrease the number of missed intervals to get notifications sooner and have a more realistic idea of whether the messages from an actual event will be reliably received.

There is also a setting, disabled by default, that will generate e trouble notification if the receiver detects constant interference. This could be due to incidental RFI or intentional jamming.