INFO: Continuous zone reporting in Not Armed status (MQTT examples) #89
Replies: 4 comments
-
Correct, the job of the interface is to provide realtime status - it's up to the target software to decide what to do with the information.
I'm not clear on what would constitute too many notifications unless you're setting things up to push out a notification to a human on every zone status change. For example, you could use motion sensor data to setup automations that turn on lights after dark in rooms with activity, or turn them off after a delay in rooms that have no activity, etc. These sorts of possibilities are entirely separate from the armed state of the panel.
I just checked and am seeing the same issue - will take a look. |
Beta Was this translation helpful? Give feedback.
-
Thank you, your explanation confirms what I thought but wasn’t sure, that the logic and handling on how to use the real-time events rests in the « application » software. |
Beta Was this translation helpful? Give feedback.
-
@aboulfad I think what you want is dsc.alarm[partition] ? This will only be set when the alarm gets triggered, i.e. motion detected while the alarm is armed. |
Beta Was this translation helpful? Give feedback.
-
@jimtng , thanks, what I wanted is clarification and I got it from the author :) what I will develop on the HAP-Node side (not using HB) is to detect and report to HomeKit only contact switch sensors (Zones) status when alarm is not armed, and ignore motion detectors. This is the behaviour I want when the alarm system is not armed. @taligentx , should I close this and re-open an issue to track the “D” issue? |
Beta Was this translation helpful? Give feedback.
-
Hello,
this is a request to understand the background behind the logic of the MQTT examples or other examples that report partition/zone status and potentially improve on it. Or I may be missing altogether something simple.
On my PC1832 panel (or maybe all?), the Zones continuously report their status (open, closed,...) regardless if the system is in Armed on Not-Armed as seen in Keybusreader sketch.
So the MQTT examples relay those status(es) to the MQTT broker and consequently to let's say Homekit. What that implies, that as people are triggering those zones, Homekit will continuously receive those updates.
The above behaviour is fine for contact type sensors, one would want to know if a door/window is left open even when alarm isn't armed and that would not yield many notifications. But a motion detector would yield too many notifications as people are moving along their surroundings on the end user device.
I have also noticed when the motion detectors trigger, the mqttPartitionTopic receives multiple
D
events (4-10), which I haven't figured out yet the connection.PS: I have not used homebridge yet, I am progressing step by step and monitor on the different MQTT topics what is being reported.
Beta Was this translation helpful? Give feedback.
All reactions