Proposal 3: don't only store problems

[macinspak]

Originally from #24, submitted by @bartbutenaers

I have not analyzed the internal kitchen of these nodes yet into detail, so perhaps this is already possible somehow.

When I want to switch my alarm from Off to Away, I want to show a list of the current problems. In the following demo my Node-RED flow sees that there is still one door open, which it shows to me:

Then I can decide whether I cancel the state-change and close the door first. Or I can continue switching the state.

To keep my flow simple, it would be nice if the alarm-nodes could store this information, and make it queryable. Indeed the sensor node gets all values from all sensors, and it knows (based on the last sensor value and the Trigger dropdown options) which sensors currently have detected an issue.

[macinspak]

Yes, I had also been thinking about the best way to implement this.

I guess again I had been postponing it myself as I tend to arm the house after leaving and not had this issue. But it is a standard sort of function. Perhaps having real-time nodes always outputting "open or close" state will allow people to build their own led dashboard equivalent, and maybe some logic or additional parameters that will auto-fail setting a mode and returning a separate error output connection if the alarm would immediately fire? Then standard behaviour remains, but you can set an "exit delay" for any mode via that node configuration or passing in a parameter as part of the msg. Then you could fail to switch the mode and push a push notification or "pip" an alarm or something? Or play a sound on your alexa or homepod?

What do people think?

[bartbutenaers]

I had been postponing it myself as I tend to arm the house after leaving and not had this issue

Indeed when you activate remotely your alarm (via e.g. a smart phone), this is not really useful. Because when you already left your house, you cannot do this:

1. Press the "Cancel" button
2. Close the front door (which was still open as mentioned in the popup)
3. Activate the Away mode again (and now no popup anymore since all doors are closed.

Although it is still a bit useful, because you can blame your wife and kids in the car that they again forgot to close some doors ;-)

Currently I do it like this in my node:

1. When a sensor value arrives, I calculate whether it is a trigger value or not (similar like you do it in your Sensor node).
2. Then I store per sensor (e.g. per topic) the boolean result of that calculation. So I remember whether the last value was a trigger value or not.
3. When I want to activate my alarm, I ask my node a list of all sensors (e.g. topics) whose last value was a trigger value.
4. I show those sensors in a popup.

In my case this is all inside a single node, but I like your approach of multiple nodes a LOT more! Because I have a lot of wiring towards the same node, which again leads to a spaghetti flow. To avoid ruining your nice concept, could it perhaps be useful to add a new node to your repository? E.g. a Query node, whose config screen contains a dropdown where you can select a query. In this case the "Sensors with trigger value" query. Then we could put that Query node in between the Dashboard nodes in my use case:

Note that the issues popup need only to be showed if there are any sensors whose last value was a trigger value! Because it has no use to show an empty popup...

Therefore it would be useful that such a node had two outputs:

• when the query resultset contains 1 or more entries, then an output message is being send on the first output.
• when the query resultset contains 0 entries, then an output message is being send on the first output (containing an empty array) and also on the second output.

The second output can be omitted, but then again you need to add an extra Switch node to check whether the resultset is empty. Resulting again in a less clean flow...

But there might be better ways to implement this in this node suite ...

[macinspak]

Going to think about this one. I like the idea. We can use it to trigger warning "pips" or a push notification to let you know you armed the house, but the back door is still open so you had better turn around, go back and close it.

[bartbutenaers]

Hi @macinspak, If you should have had time to think about a proposal, it would be nice if we could discuss about it. Thanks !! Bart

[macinspak]

It has indeed also been bugging me on how best to implement. I mean, if you look at traditional alrams, they used to do that alarm pip if there was an unsecured zone, but I cannot remember if they refused to arm. Maybe it is OK to arm, and then they walk out the front door, because CLOSING the door does not trigger the already armed system? Maybe as it only should alarm on OPEN then it's ok. It just means if you arm it and do NOT close the front door, then that zone or sector is disabled. I think from memory it used to do that on the old alarm systems right? I mean it would disable the unsecured zones?

I guess we just need to work out the semantic to make the most sense. What are the use-cases?

1. woman pushes button and walks out front door, get's notification they left the laundry door open?

   • they ignore it and it's disabled? Doesn't matter if it opens and closes (banging in the wind as it's latched open)?
     • they walk down the side and pull the door shut and now it's armed (because it would only trigger on a new "open" event)?

Is it that simple? Or what other cases do we need to cater for?

Love your thinking by the way, great to have someone now to bounce this off to get the best outcome. Andrew

On Fri, Oct 1, 2021 at 8:59 AM bartbutenaers @.***> wrote:

Hi @macinspak https://github.com/macinspak, If you should have had time to think about a proposal, it would be nice if we could discuss about it. Thanks !! Bart

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/Anamico/node-red-contrib-alarm/issues/27#issuecomment-931759869, or unsubscribe https://github.com/notifications/unsubscribe-auth/AGHK2LEPPO6AG274YYNXDBLUETTVRANCNFSM5BYCN2XA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

[bartbutenaers]

Sorry to keep you waiting!!!

I cannot remember if they refused to arm

Hmm not sure either. But I don't think that logic needs to be part of your node. Let the people handle that in their flows. For example I like to show a popup (to display all sensors that are currently detecting an issue), but other people can just refuse arming, or activate anyway, or ...

If we could just so something like this:

1. A message is injected into your node.
2. The Filtrex expression analyses the sensor value, and labels it as a problem or not.
3. The value and the corresponding problem status is stored per sensor.
4. We can query the problem status of each sensor, to determine in our flow what should happen next

This way everybody can decide what to do with the problem sensor values. I think such a design is much more flexible, compared to when your node would decide everything on its own. I mean I step 4 you can:

1. You can show a notification popup: "unable to arm the alarm, because some sensors have problems currently".
2. You can show a notification popup where you can select 'ignore' to continue arming.
3. You can arm the alarm system anyway, ignoring all current problems.
4. You can have a list of which sensors are ignorable and which not. If a non-ignorable sensor has a value, then you can't arm the alarm system.
5. And so on ...

Or what other cases do we need to cater for?

Suppose your alarm keypad is inside a PIR-secured zone:

1. You want to leave the house, so you enter the room.
2. The PIR sensor detects you and an alarm problem value will be injected.
3. The PIR value should now be ignored, because - as soon as you leave the house- the sensor value will get back to normal again. So it is ignorable during arming.
4. You enter your key code to activate the alarm (in e.g. 30 seconds).
5. You leave the room.
6. The pir sensor value will get back to normal.
7. The alarm is activated, and that moment there is no PIR problem anymore.

8. Hopefully this makes sense?