[Custom Component] Alarmo - browser managed alarm system

[neliss]

Hello everyone,

It was about time for a new release, so I released v1.4.0.
Let me summarize the changes.

Transitioning between arm modes (Thanks to @zbuh !)
It is now possible to make a switch directly between arm modes, wihout disarming in between.
For example, you can switch from “Armed Night” -> “Armed Away” (or back).
Details:

• Since the alarm remains armed, it is not required to re-enter the code for this action.
• If the conditions for the new state is not met, the transition will be aborted, and your “failed to arm” notifications/actions will be executed.
• The transition will be instant, so the exit/leave delay does not apply here

I find this functionality very practical for my vacuum robot, which occasionally triggers a motion sensor.
I use an automation to switch to “Armed Custom Bypass” while my vacuum does its job, in which some motion sensors are not watched.

Note that the Alarm Panel card for Lovelace automatically hides all arm buttons while the alarm is armed. So this card will not allow you to perform such transitions.

Arm on closing a door
As I already announced before, I added functionality for automatically skipping the (rest of) the Exit delay, when a (frontdoor) sensor is closed.
This function is useful when you set your alarm to “Armed Away” before leaving the house, since you will be able to get a confirmation (or error) notification as soon as you leave the house (and not when you’re already on the road).

The function can be found under this setting in the sensor configuration:

Note that your motion sensors (in the Hall) may still be activated when closing the door, so it might be needed to set the “Allow open while arming” option for such sensors (which will ignore the state of the motion sensor during the arming).

Introducing sensor types
Due to the growing amount of settings that you can apply per sensor (and the confusion that comes with it), I saw it needed to reorganize the sensor settings page a bit.
You can now assign a type to a sensor, and it looks like this:

When assigning a type, the panel attempts to set appropriate settings, and filters out settings which are not relevant for this type.
Defining a sensor type is optional, leaving the field clear will give you access to all settings.

I will try to update the readme in the coming days to give more details about all introduced features.
Hope you like it!

[neliss]

@tremebundo

This will help a lot of us. An option in every configured sensor like “Must be closed to permit arming” would be very helpful. And the hability to notifiy that situation when not meet.

Please give the “immediate” option a try.
Or let me know why this doesn’t work for you.
It was really intended for this application.

@JoeAstor

What am i doing wrong. When arming the alarm it goes directly to disarmd. This with both armed away and armed home

Probably a sensor is preventing it.
Try configuring an notification for “failed to arm” event, with the {{open_sensors}} wildcard in the message.
Or you could check the open_sensors attribute in the alarm_control_panel entity in HA.
Maybe the logs will also give you more info.

[JoeAstor]

Thx, did the trick!

[sparkydave (🇦🇺 Dave)]

@neliss

I find this functionality very practical for my vacuum robot, which occasionally triggers a motion sensor.

This will be awesome. I have the issue of a vacuum that gets detected on motion. Being able to to create an automation to change the alarm from armed_home to armed_away once the robot vac docks would be great.

[neliss]

Exactly, this is now possible.
Just create an HA automation that calls service alarm_control_panel.alarm_arm_away.

[tremebundo (Juan Manuel)]

@neliss

Please give the “immediate” option a try.
Or let me know why this doesn’t work for you.
It was really intended for this application.

Hi neliss,

Thanks for your hard work.
Well, I have tried setting a sensor as immediate, created an action to notify me (in my case, via Telegram) about the cancelling, and it works beautifully.
But, in my specific environment, I create an automation to send a notification via the mqtt.publish service to a tablet runnning MQTT Alarm Control Panel Android App that appears on the screen of the tablet in that case.
The problem I have in that when I set a sensor as immediate and try to arm, the state of alarm_control_panel.alarmo does not change from disarmed to any other state as far as I can see at developer tools - states or the alarmo/state at the mqtt broker. So, I do not know how to trigger that automation.
I have checked just today with 1.4.0
But, as I said before, all this is very specific to my setup. And even may be I have a mess in my config. So, if you do not see any clear error, please, do not waste your time. I could live with my custom automation.
Again, thanks a lot for your hard work. I am very near of a production system and my family approval

[Michael_Dahl]

Hi

Is there a debug mode that can be enabled ?

I have 3 actions in the app.
Trigger: Alarm armed -> Siren turn off
Trigger: Alarm disarmed -> Siren turn off
Trigger: Alarm trigger -> Siren turn on

But when I come home, I enter the front door, and walk to the RFID reader (Z-wave), and disarm the alarm, the siren turn on, for 0,5 to 1,0 second before turning off again. (The entry time is 30 seconds, and the alarm are normally deactivated with in 15 seconds.)

any clues ?

[neliss]

@tremebundo

The problem I have in that when I set a sensor as immediate and try to arm, the state of alarm_control_panel.alarmo does not change from disarmed to any other state as far as I can see at developer tools - states or the alarmo/state at the mqtt broker. So, I do not know how to trigger that automation.

OK, clear.
The state will stay “disarmed” in such situation, so triggering on state change is not an option.
What I can do, is expose an event for the “failed to arm” condition, on which you could trigger with an automation.
Maybe it is possible to send the open_sensors data with the event, otherwise you could take it from the entity attributes.

@Michael_Dahl

But when I come home, I enter the front door, and walk to the RFID reader (Z-wave), and disarm the alarm, the siren turn on, for 0,5 to 1,0 second before turning off again. (The entry time is 30 seconds, and the alarm are normally deactivated with in 15 seconds.)

I’m not sure either, all looks OK.
Could be that you found a bug in Alarmo.
You could try with the debug logging enabled (this is how I use it).
In configuration.yaml:

logger:
  default: warning
  logs:
    custom_components.alarmo: debug

Please create an issue in GitHub for posting the logging, so we can investigate it more.

[tremebundo (Juan Manuel)]

@neliss

OK, clear.
The state will stay “disarmed” in such situation, so triggering on state change is not an option.
What I can do, is expose an event for the “failed to arm” condition, on which you could trigger with an automation.

Perfect. Take your time.

[sparkydave (🇦🇺 Dave)]

@neliss

OK, clear.
The state will stay “disarmed” in such situation, so triggering on state change is not an option.

Would it be possible to create a state ‘Pending’ which Alarmo goes to during the ‘exit delay’ time? It would also be great if a similar ‘Warning’ state could exist during the ‘entry delay’ time. This way we could automate based on these states.

[neliss]

This is already in place, see the documentation.
The state are according to the HA alarm panel entity definition, all is made to be generic and compatible with HA.

[sparkydave (🇦🇺 Dave)]

My bad. I am away for work so not actually able to play with HA for a a few weeks.

[quizzical]

@neliss

Transitioning between arm modes

I found the Alarmo custom component and decided to use it for my alarm system. I now read in this forum it’s only a couple months old. Quite amazing what you have accomplished!
The transitioning between arm modes is very helpfull, but I have the impression it’s not yet fully working:

If I trigger a motion sensor with a quite long off delay and set the arm-away mode, after the exit delay, it will return to disarmed and the open sensor attribute correctly reports the problematic sensor.
However if I set the exit delay to zero and then again trigger the motion sensor and set the arm-away mode: it will remain in disarmed mode and the open sensor attribute remains empty. If I set an action in the alarmo panel to trigger a boolean when it fails to arm, that does get triggered though. So inside alarmo it seems fine but it doesn’t seem to update the alarmo values in home assistant itself.

in case of interest:
I have abused your modes slightly.
I placed cheap car seat pressure sensors under our beds and attached them to cheap z-wave door sensors. So for €15 I now have bed occupancy sensors.
When we are all in bed the armed night mode turns on automatically.
If I get out of bed, the motion sensor in the hallway turns off (i achieve this by switching to the armed custom mode, which does not include that sensor) untill everybody is back in bed.
That sensor is near the starways so in case it detects motion while in armed custom mode, it will turn off the motion sensor in the hallway downstairs (i achieve this by switching to the armed home mode, which does not include that sensor and the previously mentioned sensor in the hallway).
If the motion sensor in the hallway downstairs detects motion while I am in this armed home mode, it assumes I want to get up for the day, and it completely disarms the alarm system.
Obviously it is possible I just had to do fetch something downstairs and then go back to bed. The bed occupancy sensor will detect that everybody is back in bed, and I will turn on the armed night mode again.
So I’m abusing your armed home mode, but it suits my need very well

[neliss]

@quizzical

However if I set the exit delay to zero and then again trigger the motion sensor and set the arm-away mode: it will remain in disarmed mode and the open sensor attribute remains empty. If I set an action in the alarmo panel to trigger a boolean when it fails to arm, that does get triggered though. So inside alarmo it seems fine but it doesn’t seem to update the alarmo values in home assistant itself.

Thanks for letting me know about this, I will check it out.

[quizzical]

I noticed a little peculiarity in your new feature to be able to transition from one armed mode to another
(eg from armed custom bypass to armed night): alarmo transitions trough disarmed first.
I first see an event that transitions the alarm from custom bypass to disarmed, then I see an event that transitions the alarm from disarmed to armed night.

I noticed this because I want my bedroom light to only briefly change brightness when I transition from disarmed to armed night (to let me know the house recognised I’m going to bed and the alarm is secure).
I don’t want this to happen when I transition between armed modes, but because alarmo first disarms the alarm for these transitions, my automation thinks the alarm was disarmed.

Do you think it would be possible to not fire an event to set the alarm to disarmed when transitioning from one armed mode to another? That would seem more logical to me

[Greg]

Just stumbled across this and going to give it a go to replace my complex Node Red nodes - looks like it’ll do everything I’ve currently got in Node Red, in a nice UI. Good work!

The one thing I see missing though is in notifications using the mobile app there’s no ability to send a “critical alert” which bypasses the phone’s DND mode. I use this for the house alarm notifications so I get them even if I’m asleep (obviously):

{
    "message": "{{body}}",
    "title": "{{title}}",
    "data": {
        "push": {
            "category": "HOUSE_ALARM_TRIPPED",
            "sound": {
                "critical": 1,
                "volume": 0.5
            }
        }
    }
}

[neliss]

@quizzical

If I trigger a motion sensor with a quite long off delay and set the arm-away mode, after the exit delay, it will return to disarmed and the open sensor attribute correctly reports the problematic sensor.

However if I set the exit delay to zero and then again trigger the motion sensor and set the arm-away mode: it will remain in disarmed mode and the open sensor attribute remains empty.

I just tried this, for me the behaviour is as I would expect it.

In the entity attributes, I see:

open_sensors: 
binary_sensor.motionsensor_hall: open

And I also got a push message accordingly.

@quizzical

If I set an action in the alarmo panel to trigger a boolean when it fails to arm, that does get triggered though. So inside alarmo it seems fine but it doesn’t seem to update the alarmo values in home assistant itself.

This does not make sense with the structure of the code.
Automations are always fired together with updating the state of the HA entity.
If this doesn’t happen, perhaps some error occured while executing the automation, check the logs for details.

@quizzical

I noticed a little peculiarity in your new feature to be able to transition from one armed mode to another
(eg from armed custom bypass to armed night): alarmo transitions trough disarmed first.
I first see an event that transitions the alarm from custom bypass to disarmed, then I see an event that transitions the alarm from disarmed to armed night.

Same about this, the behaviour you are reporting does not match with the implementation, and also not with how it behaves for me.

Sequence of steps I used:

1. I set the alarm to Armed away via the alarm panel card
2. I use a service call to switch to Armed home (since the alarm panel card doesn’t show this option)
3. I disarm via the alarm panel again

Result:

The push messages I received are accordingly (I don’t get a disarmed notification while switching modes).

Please report the problems you experience via GitHub.
Make sure to provide some evidence (screenshots, screen capture video, loggings etc) so I can follow the steps you did and see what goes wrong (maybe I don’t follow the same procedure as you do).

@Greg

The one thing I see missing though is in notifications using the mobile app there’s no ability to send a “critical alert” which bypasses the phone’s DND mode. I use this for the house alarm notifications so I get them even if I’m asleep (obviously):

As far as I know, the notification editor already allows you to customize the notification service_data with such extra parameters.
However you need to switch to the YAML editing mode and add them manually (the GUI doesn’t allow you to edit these extra properties). See also the actionable notifications section in the documentation.

[Greg]

@neliss

As far as I know, the notification editor already allows you to customize the notification service_data with such extra parameters.
However you need to switch to the YAML editing mode and add them manually (the GUI doesn’t allow you to edit these extra properties). See also the actionable notifications section in the documentation.

Ahh, great - taking a look at that bit now

[Greg]

Superb - works fine

Here’s what I entered in the editor if anyone else wants to make a notification critical:

name: Alarm triggered
modes: []
triggers:
  - state: triggered
actions:
  - service: notify.mobile_app_gregs_iphone_xs
    service_data:
      message: 'The alarm is triggered! Cause: {{open_sensors}}.'
      data:
        push:
          sound:
            name: default
            critical: 1
            volume: 1.0

[quizzical]

It was a bit tricky as I’m still a novice at node red (which I use for my automations), but I created some automations to work with the open_sensors information.

If the open sensors information is filled in because the alarm was on it will send a notification on my android phone (I created a subflow that will turn off do not disturb mode and set the volume loud etc) with a picture of the nearest camera if there is one at that location and with a speech message as well. If there is an entry delay, it will take the picture immediately, but wait to see whether the alarm is actually triggered before sending the notifications with the pictures.

If the arming failed, it will send me a vocal en text message with the sensors that are open (will become fully functional when this issue is fixed) and asking me whether I want to retry arming or force arming.
Really excited about what a nice alarm I’m able to build thanks to Alarmo!

For most, the built in notifications in Alarmo will be sufficient though