I wanted to avoid having to manually switch the “allow for disarming” for the guest. My idea is to enable guest mode automatically when the router detects some of my allowed guests and if they are present they can disarm the alarm. This needs to be controlled in an automation.
With the way it’s done right now I think I can create an automation that catches the disarming with the changed_by: guest. If the guest disarmed the alarm and the guest mode is off, I will arm again or even trigger it. But I would like to have a more seamless solution, if possible.
I see one scenario where you have a guest mode attribute on the alarm and then one switch on the user to say if it’s a guest or not, and if the alarm guest mode is on, then all the guest users can disarm.
Another more complex solution would be to create a sensor per user like: sensor.alarmo_user_guestA with some user options as sensor attributes (the allow arm and disarm only I guess), this way you could change the permissions per user in the automations.
What do you think? Will you eventually develop some solution like this?
This is awesome BTW. I haven’t gotten it all setup yet since I didn’t have sensors that could really be used by the alarm, but I recently got some and I’m going to start using it.
Looks great! I’ll update if I find any issues and if I think of anything else that can be done.
@neliss another thing I would like to have is the possibility to use is the same or equivalent services of the manual alarm control panel, i.e., alarm_control_panel.alarm_trigger, alarm_disarm, etc… this would allow for a very easy transition for those that have already done their implementation with the native alarm_control_panel, which is my case. This also adds another level of flexibility that can be very powerful.
Please let me know your thoughts on the guest mode stuff as well as for the services.
Alarmo publishes its state to zigbee2mqtt/<keypad name>/set via mqtt
mode for the keypad can be one of disarm, arm_day_zones, arm_night_zones, arm_all_zones, exit_delay, entry_delay, not_ready, in_alarm, arming_stay, arming_night, arming_away
And Node-Red listens to topic zigbee2mqtt/<keypad name> for payload.action and payload.action_code from the keypad and sends the new alarm state to Alarmo.
The change node changes the keypads payload.action to Alarmo format ( disarm to alarm_disarm ect.)
The keypads alarm state (led status) is always in sync with Alarmo.
How pass parameters to alarmo action script?
Have this action:
`
name: Flash Light
modes:
armed_away
triggers:
state: triggered
actions:
service: script.turn_on
service_data:
entity_id: script.flash_light
device: sonoff_100028e0e9
area: ‘1618921001’
`
When I try it, get error: “extra keys not allowed @ data[‘device’]”
The script was working before I added parameters.
Are parameters supported for alarmo actions?
cant’ do step 3 in “install” instructions:
“3. Go to Configuration → Integrations and click the big orange ‘+’ button. Look for Alarmo and click to add it”.
Alarmo doesn’t appear, … not showed in integrations list.
I am currently integrating Alarmo in my HA.
I can arm the different Areas seperately however, when I’m trying to arm the system using the Master, this doesn’t do anything.
Do you have any idea? Do you need any further information?
Your section 3.3.3. regarding the Alarmo-card is not correct, your screenshots show the Lovelace Alarm Panel Card (which is not my work).
Its fine to use that card, but Alarmo comes with its own flavour with some extra functions.
A small warning: things might change in the future, especially regarding the setting up of actions/notifications I’m planning to make some modifications. Hope this will not bother you.
Perhaps we can merge your guide in the readme of Alarmo, such that it can be found by more people, and I could help maintaining it when things change?
I would love some help with extending the instructions, especially written from the perspective of the user rather than me (some things might be intuitive to me but not to others).
I expect that one area fails which causes the master to abort the arming for all areas.
The best way to troubleshoot this is by creating a lovelace view with all areas + the master, as I did here.
If you use the ‘alarmo-card’ for this view, you should be able to get all info to see what’s going on.
If this doesn’t help, maybe the HA logs will be able to show more.
As a last resort you can enable the debug logging for Alarmo by adding this to configuration.yaml and restart HA:
Please let me know if you need assistance
Consider to create an issue in github to discuss it more.
You mean to use the gateway as a siren?
From what I heard, the siren of the Xiaomi gateway can only be turned on/off by a specific service, and it is not available as a switch (or similar) entity.
I suppose a custom automation is needed to target the specific service, this is easier to do outside of Alarmo.
I use Alarmo and two Xiaomi gateways. I have writen automations for flashing them on the exit delays, entry delay, fixed orange when armed_night, red when armed_away, green for some time when disarmed and custom beeps on the delays.
The main alarm siren I have is a zwave one.
Good choice. I managed to get my gateway to ring but it stops after a few seconds. It does not reflect the settings entered in Alarmo of course and in the automation too… any ideas?
@jasonshearer
I just released an update which allows you to scale the buttons.
There are definitely more things to be done for improving the card, but it’s a start.
