node-alarm-dot-com / homebridge-node-alarm-dot-com

Alarm.com plugin for Homebridge using Node.js
MIT License
58 stars 23 forks source link

Freeze Sensor (heat sensor) incorrectly appears as a smoke sensor #109

Open sslupsky opened 1 year ago

sslupsky commented 1 year ago

Describe the bug A heat/freeze sensor is being configured as a smoke sensor. This sensor is a contact that opens/closes at a preset temperature. It is not a smoke sensor.

To Reproduce Configure alarm panel with a heat sensor

Screenshots

Screenshot 2023-02-12 at 10 19 29 PM
robertavram-md commented 1 year ago

Same here IMG_9594

chase9 commented 1 year ago

I think this bug stems from my own misunderstanding of how these devices work.

The old way these devices worked was how you described. This meant all sensors were simply opened or closed. In the last update I tried to choose more specific states matching the hap-nodejs so that sensors showed up with their specific types in homekit. You can view some of these types here.

In any case, I picked smoke detected since there is no heat option in homekit. Seems like the best course of action is to revert to contact open vs closed?

sslupsky commented 1 year ago

Think of it as a "threshold sensor".

A "threshold sensor" in the historical context is a bimetallic switch that opens or closes depending on the ambient temperature. Think of the old style Honeywell thermostats where a mercury switch opens or closes based on the thermal expansion of the bimetallic coil. See https://en.wikipedia.org/wiki/Bimetallic_strip

Modern threshold sensors comprise a digital temperature sensor with a digital output that signals if the temperature is above/below a set point. The set point (threshold) of modern sensors can be fixed or programmable.

Referring to the following Apple Developer doc: https://developer.apple.com/documentation/homekit/hmcharacteristic/characteristic_types

Can you create a sensor that is a combination of types? For instance, combining the following types:

ContactState (or maybe OutputState is more appropriate?) (from Power and Switches) CoolingThreshold (from Temperature) for a freeze sensor HeatingThreshold (from Temperature) for a heat sensor

I think these correspond to the following types in the link you provided above: ContactState (or ProgrammableSwitchOutputState) HeatingThresholdTemperature CoolingThresholdTemperature

The cooling or heating thresholds may be fixed by the sensor. So the threshold value entered by the user for a fixed "threshold sensor" is a way to document what that threshold is so the UI can report it properly.

There are a few characteristics described in your link called a "RelayControlPoint", "RelayState" and "RelayEnabled" but I do not understand the context in which they are intended to be used. These types do not appear in the Apple Homekit characteristics I linked to earlier.

chase9 commented 1 year ago

The issue with this is that the system expects a temp to be set as the threshold and as far as I know there is no temp reported from the sensors. I suppose we could set a hot max of 1 and a cold max of -1 and report an issue this way?

sslupsky commented 1 year ago

I think you would let the user set the threshold. If the contact changes state then the threshold has been exceeded. No way to tell ahead of time which way these sensors work. Some will close when the temperature rises above the threshold some will open when the temperature rises above the threshold. Similar behaviour for a freeze sensor.

Ic3Nine commented 1 year ago

I just want to jump on this as well. I added the plugin yesterday and it works wonderfully for pretty much all sensors and arming/disarming. Now I can control automation better than just deleting the whole thing from the alarm.com site when going on vacation. Anyway, both the heat sensor and smoke sensor are triggered in my Home app.

I don't know if this is any indication but on the control.adt and alarm.com websites when managing devices both heat and smoke sensor show OK(Sensor is not Reset). As opposed to OK(Idle)/OK(Closed|Open) for doors/windows.

12 |   | Ok (Closed) | Door/Window Sensor | Door/Window Sensor |   -- | -- | -- | -- | -- | -- 13 |   | Ok (Idle) | Glass Break Sensor | Glass Break Sensor |   14 |   | Ok (Activated) | Motion Sensor | Motion Sensor |   15 |   | Ok (Sensor is Not Reset) | Smoke Sensor | Smoke Sensor | N/A 16 |   | Ok (Sensor is Not Reset) | Heat Sensor | Heat Sensor | N/A
chase9 commented 11 months ago

Hi everyone, coming back to this issue while I try to fix up sensors being reversed.

I misread the initial report. The issue here is that Homekit does not have a heat/freeze sensor. There is a temp sensor, but it's for actual temperature monitoring, not if the sensor has crossed a threshold. This leaves us with making temp sensors show up as either smoke detectors or contact sensors. I opted for smoke detectors since I thought that was a better fit, but I admittedly wasn't thinking about freeze sensors!

It sounds like it might be best to switch back to showing temp sensors as contact sensors?

sslupsky commented 11 months ago

It sounds like it might be best to switch back to showing temp sensors as contact sensors?

Specifically, temp threshold sensors should be modelled as contact sensors.

chase9 commented 11 months ago

What's your reasoning for that? I would think we prefer to use the smoke detector since Homekit assigns smoke detector faults higher priority then a contact sensor.