Requirements to MQTT interface

[akasma74]

This FR is an attempt to gather and discuss what's required from this component's MQTT interface. It's particularly important to people who don't use the UI alarm panel/Lovelace alarm card and only rely on MQTT command/state topics to get information from the alarm and to control it.

Here is one of the reasons to dicuss.

To me it seems like the current approach should be to make available via MQTT the same amount of information/same commands one can use via service calls/UI.

Speaking about 'open sensors' situation: I can see several things related to it:

1. arm_xxx command should have some kind of ignore_open_sensors flag. As an alternative (or as an additional feature?), it's possible to introduce set_ignore_open_sensors MQTT command to globally enable/disable arming with open sensors.

2. The general approach to handle arming process via MQTT/service calls should be the following: a. issue arm_xxx MQTT command/call arm_xxx service b. call wait_template with some timeout (say 3es conds?) c. check a condition that the alarm's state disarmed d. do something to let user know it's not armed I think MQTT switch uses a similar approach - it waits for a response in state topic after issuing a connand to command one.

3. How to get a reason why it didin't arm? I'm not sure that state topic is a good place for that but I'm open for ideas. The interesting question is how are we going to use this information as it will arrive when the alarm sends it, not when we need it.

That's it for now but I believe there's a lot more to consider/implement so feel free to add your thoughts.

[sparkydave1981]

I currently use this custom component in HA to communicate with a hard wired "Paradox" alarm system in my house using this interface. It would be awesome if I can have that functionality remain / improved. Currently the Paradox alarm doesn't seem to change the MQTT status topic during entry /exit delays (pending time as it's called in this component) Hopefully with the updates to HA alarm MQTT topics this could be added. I realise that this will require changes from the interface author, I'll post something on that GitHub when I get a chance. I just wanted to show what commands etc I use regarding the MQTT

[akasma74]

It would be awesome if I can have that functionality remain / improved.

I'm not going to take away anything so far ;) I take it the only improvement is that change of state during exit/entry - you're right, that's down to the interface's author in your case.

[jamos77]

I've just started to use NodeRedUIAlarm Panel only for a few days. So these are mainly ideas and have not much experience with using it yet. Just considering how BWAlarm works regarding open sensors. Is it that BWALARM checks for Open Sensors first before alarming and then if there are any open you can overide it and set the Alarm?

I think the benefit of how this works is that if you have multiple sensors you can easily see which ones are open and go and close a window you forgot about rather than walking round the house to check every door and window is shut.

Where this logic should take place for MQTT Alarming? BWAlarm or NodeRedUI Alarm Panel or some on both. NoderedUI Alarm Panel already pulls in the BWAlarm configso it may be possible to check for open sensors on the UI before sending an Alarm Set. If there is an MQTT OVerride payload command available then this may also be possible to implement on the NodeRedui Alarm Panel.

However if you wanted to control this logic from BWAlarm is it possible to send both a not set MQTT message with a list of open sensors based on what Alarm Mode was set?

[akasma74]

Is it that BWALARM checks for Open Sensors first before alarming and then if there are any open you can overide it and set the Alarm?

if one arms it from the UI panel then yes (as it's possible to do so via service calls/MQTT commands).

I think the benefit of how this works is that if you have multiple sensors you can easily see which ones are open and go and close a window you forgot about rather than walking round the house to check every door and window is shut.

I beleive that was originally the main reason behind it.

Where this logic should take place for MQTT Alarming? BWAlarm or NodeRedUI Alarm Panel or some on both.

As I said, there are seeveral ways to arm the alarm and all of them eventually call arm_xxx function that in particulat checks for open sensors and fails if there are some (and no override flag is set).

NoderedUI Alarm Panel already pulls in the BWAlarm configso it may be possible to check for open sensors on the UI before sending an Alarm Set. If there is an MQTT OVerride payload command available then this may also be possible to implement on the NodeRedui Alarm Panel.

yes, that's an option

However if you wanted to control this logic from BWAlarm is it possible to send both a not set MQTT message with a list of open sensors based on what Alarm Mode was set?

well, as I said earlier I don't want to use state topic for that but can use another one. my main question is do you have an idea how it would work in that case?

[jamos77]

Hi, This was easier than I thought to implement the open sensors view in Node Red UI Alarm panel. I have it working similar to BWALARM by checking if there are any open sensors that are (immediate or warning) but aren't also override sensors. If there are open sensors in this list then they are displayed in the panel and the arm_xxx is not sent.

[golfvert]

First of all, thank you for tackling this!! At the moment, I am doing this "outside" bwalarm. I have a nodered flows that listens to "ARM_AWAY" or "ARM_HOME", checks if one of the sensors that should be off/close is on/open (I maintain that list manually). If one is in the wrong state, I am playing of fail sound and goes to a sensor page where I can see which one is the culprit. So, pretty basic but it works...

After sending "arm_xxx" you expect a "pending" message on MQTT. If you were to integrate a more advance diagnostic function, I think the idea would be to send a "fail" message with the list of sensors that prevent the alarm going to "pending". That would be enough for me...

[akasma74]

After sending "arm_xxx" you expect a "pending" message on MQTT. If you were to integrate a more advance diagnostic function, I think the idea would be to send a "fail" message with the list of sensors that prevent the alarm going to "pending". That would be enough for me...

The thing is the state topic should reflect the alarms's state and therefore can only accept real states like disarmed, pending, armed_away etc. As fail is not a valid state, I'm not happy with sending it to the state topic, it'd rather go to information one and my question is would you be able to use that information? One of possible scenarios could be:

• send arm_xxx command
• wait until the alarm changes state from disarming (with timeout of say, 2 seconds)
• if the alarm is still disarmed, display last message from the information topic to the user

Does that make sense?

[sparkydave1981]

As fail is not a valid state, I'm not happy with sending it to the state topic, it'd rather go to information one and my question is would you be able to use that information? One of possible scenarios could be:

• send arm_xxx command
• wait until the alarm changes state from disarming (with timeout of say, 2 seconds)
• if the alarm is still disarmed, display last message from the information topic to the user

Does that make sense?

That seems workable to me. I have an issue where I control my hard-wired alarm via a key-ring remote as I'm leaving my house (generally leaving the driveway). Once that system changes to armed_away this is sent via MQTT to HA which then arms in away mode as well, thereby creating a sychronised alarm. I do this so that HA can monitor sensors that are connected to it like z-wave gear, which are not already part of the hard-wired system. The problem is that sometimes HA misses a state change from a sensor and thinks that the sensor is still 'triggered' and thus does not arm. By having this status available (ie: failed) I could be alerted to this before getting too far away.