Feature Request: Allow arming/disarming with automations without requiring code

[syphernl]

Checklist

• [X] I checked for similar existing requests (both open and closed) before posting.
• [X] My request is generic, other users may benefit from it too.

Proposal

Currently you can only arm/disarm if you know a user's code. Using this code, it can be determined which user did the arming/disarming.

However, for automation purposes it would be nice if you could provide a user instead of a code. This way, the automations/scripts etc do not need to know the user's code but can still act as that user. This would also make it easier if a user code changes.

Additional info

• Make the code parameter for the alarmo.disarm and alarmo.arm services optional (if user is provided)
• Add an optional user parameter to the alarmo.disarm and alarmo.arm services

[nielsfaber]

I don't see the benefit of providing a user when you are using automations (you could say user is only applicable when arming via keypad, rfid tag etc). The only reason the alarmo.arm / alarmo.disarm services require a code, is to avoid a security hole in Alarmo (arming should be consistently require a code else it might be abused).

You can also register a user automation with password automation in Alarmo. If you would provide code: automation in the service call it would allow you to do so, and you will see that the arming/disarming was done via an automation. I would say this is a more effective/accurate to the change you're proposing. Am I overlooking something?

[syphernl]

I am currently doing it similarly as to what you have described, but using a random code rather than a password that is tied to the automation user. However, because of this you won't be able to see who changed the alarm to that specific condition.

An example use-case:

• You use an app to track user locations/presence (e.g. HASS Companion app or OwnTracks) which is installed on user Bob and Alice's phones.
• You have a HASS automation that checks when person.bob or person.alice goes from home to away
• HASS knows which user state change triggered the automation
• Within this automation, Alarmo is asked to arm the alarm on behalf of the user:

  service: alarmo.arm
  data:
  entity_id: alarm_control_panel.alarm
  user: bob
  mode: away
  skip_delay: true
  force: true

• It is now known that user bob has armed the alarm, rather than automation.

An alternative to this would be creating an automation user for each user (e.g. automation bob / automation alice) and use its code/password to trigger with in order to not have to know the user's code / be affected if the user code is changed in the future. But this does not feel logical/practical.

[nielsfaber]

The changed-by-user setting was intended for manual arming actions (so through the Lovelace card). Your proposal still feels a bit hacky to me, since in fact the system was armed by an automation... I wonder why assigning a user is so important to you. Alarmo internally doesn't do much with the changed_by property.. Do you have additional automations which send notification to the right person or something? I'm just trying to see the bigger picture 🙂

Regarding

However, for automation purposes it would be nice if you could provide a user instead of a code.

I'm hesitant to allow automations to arm/disarm without providing any code. It feels like some security backdoor to me, although I cannot think of a scenario where this could compromise the alarm. It doesn't seem in-line with other alarm integrations in HA as well, as far as I know the code always needs to be provided. Any thoughts on this?

[syphernl]

The changed-by-user setting was intended for manual arming actions (so through the Lovelace card). Your proposal still feels a bit hacky to me, since in fact the system was armed by an automation... I wonder why assigning a user is so important to you.

I'd like to use it for tracking/auditing purposes. But I just noticed that the logging of it isn't showing any name right now:

Alarm changed to Disarmed by service alarmo.disarm

The notification sent by Alarmo properly includes a filled in value for {{changed_by}} in this case.

Alarmo internally doesn't do much with the changed_by property.. Do you have additional automations which send notification to the right person or something?

That was indeed the idea so that the person leaving or arriving gets a notification the alarm is properly armed or disarmed instead of everyone.

I'm just trying to see the bigger picture

Regarding

However, for automation purposes it would be nice if you could provide a user instead of a code.

I'm hesitant to allow automations to arm/disarm without providing any code. It feels like some security backdoor to me, although I cannot think of a scenario where this could compromise the alarm.

Well, for that you'd still need direct access to HA. What about adding a toggle Allow automations to manage without code alongside the Use arm code and Use disarm code toggles?

That way it would provide users to choice whether they want to "take the risk". Just like they can already do by configuring Alarmo to not require a code to arm or disarm the alarm in the first place.

It doesn't seem in-line with other alarm integrations in HA as well, as far as I know the code always needs to be provided.

I believe that is indeed the case. But since it doesn't provided multi-code support (which is still a bit weird to me IMHO) this made my desired automations/notifications impossible which is where Alarmo came in to alleviate that limitation :)

Any thoughts on this?

[nielsfaber]

What about adding a toggle Allow automations to manage without code alongside the Use arm code and Use disarm code toggles?

I will try to add this option.

[mckellip]

Just wanted to add info on a secure way of doing this and a use case scenario of when a per user arm/disarm might be nice.

To make it more secure each user code have a secure key. Then in automations you would use that secure key instead of the user pincode that you might change or a very unsecure user name. The secure key would be similar to a generated api key a lot of sites do. Then there could also be the option to revoke the key on a per user basis too, if wanted/needed. I use healthchecks.io and I like their interface for it.

For a scenario I could see this being useful... if a family member got home and used an rfid tag, fingerprint, bluetooth device, etc (anything other than the keypad). Then I could still get a notification that the alarm was disarmed by my kid/spouce on my phone. That way I would know they were the ones that disabled the alarm and they were home.

I guess there are other ways to do this because you could tie each rfid tag/fingerprint to a specific person and use a general secure code on the alarm.

I don't have a use for this feature right now, but those ideas came to my head as I was reading this feature request so I thought I would share.

[nielsfaber]

@syphernl

What about adding a toggle Allow automations to manage without code alongside the Use arm code and Use disarm code toggles?

I am not sure how to implement this request. The reason is that it is not possible for me to detect from the side of Alarmo how the service was triggered. If users arm the alarm from the card it looks the same as calling the service through an automation. Hence allowing automations to arm/disarm without code implies that you can do the same through the card (which in turn is the same as having no code configured at all).

[nielsfaber]

Closing since no solution could be found to implement this.