What is the best solution to apply?
“Door” sensor with all “Active Modes”
but if the “Entrance” sensor is active with “at home” mode, the “door” sensor is inactive for 5 minutes
is it possible to create with Alarmo?
@Nettuno69 Out of the 3 questions you have asked here, all 3 times I didn’t really understand what you meant. I don’t want to be rude, but I could probably help you better if you phrase your question more clear.
As for this question:
I believe the alarmo-card uses the translation from HA. For italian (I assume you are italian), see here.
If this translation is incorrect, please notify the HA development team.
Alarmo-card also has the possibility to customize the displayed name per state, see here.
Alarmo is made compatible with the Android MQTT Alarm Panel, so if you’re looking for a control panel, I can recommend it.
As for combining with other alarm systems, I think this is hard to achieve. The problem is that Alarmo is designed as ‘master’ of the system, i.e. it needs direct access to all sensors and will decide when system is armed/disarmed/triggered. Most alarm systems have this functionality internally, so it is hard to keep them in sync regarding states, delay times, pin codes, sensor info etc. if all have their own behaviour. This is not what Alarmo is designed for.
It’s true, I have only been HA for a week; I come from the VERA System which has another logic.
In my learning path, I often find incomplete instructions, that I understand the reasoning but it is not explained where it should be applied and often it is necessary to insert lines in the configuration.yaml but the Verification from error … uffff (forgive the outburst of the newbie)
In Vera system, a sensor had the property of “armed” or “disarm” with a switch from its detection function, giving way to create automations by virtue of the state, eg. if arm sounds the alarm if Disarm turn on the entrance light
(maybe in HA you have to create the Templates but I don’t know how)
In Alarmo I would like to bring this function back to “at Home” mode, that is:
- If the “Entrance sensor” has detected movement, for the next 5 minutes turn on the entrance light and the “Door Sensor”, when it detects the opening, must NOT signal the alarm.
- If the “Entrance sensor” has NOT detected movement, the “Door sensor” must signal the alarm
I hope I have explained well, thanks for your patience and above all, forgive the translation
I understand this feeling. Documentation quality of HA is a bit of a weak point. Especially for me as hobbyist trying to create this plug-in, the route to success can be quite difficult.
Documentation for Alarmo is probably also poor, I am spending way more attention on maintaining the code than the documentation. If you have tips for improvement, please let me know! For me it’s hard to spot the missing pieces, since I know exactly how things work.
In HA, the alarm system is completely separated from the sensors. The alarm is defined in an alarm_control_panel entity, which you have to arm/disarm. The sensors are watched (by the alarm device) to determine whether arming is allowed, and of course when the system is triggered.
I cannot help you with adding intelligence / arm state to sensors directly, I recommend you to get used to the HA approach instead.
In Alarmo you can only choose to either include or exclude both the ‘Entrance sensor’ and ‘Door sensor’ for the home mode, but they cannot work together.
The only exception is by defining a sensor group, where triggering only occurs in case ‘Entrance sensor’ and ‘Door sensor’ are both active, but it does not consider in which order this occurs.The sensor group feature is intended for motion sensors which sometimes have ‘false’ positives.
I suggest you to create a separate binary sensor which indicates whether ‘Door sensor’ was activated without ‘Entrance sensor’ being activated, and include this binary sensor in Alarmo for the Home mode instead.
Example (I didn’t test it but it might be a starting point), must be added to configuration.yaml:
template:
- binary_sensor:
# this sensor will turn on together with entrance sensor, turns off after 5 minutes without motion
- name: "Entrance Sensor delayed"
delay_off:
minutes: 5
state: >
{{ is_state('binary_sensor.entrance_sensor','on') }}
# this sensor will turn on if door is opened without motion in the last 5 minutes
- name: "Door Sensor without entrance"
state: >
{{ is_state('binary_sensor.door_sensor','on')
and is_state('binary_sensor.entrance_sensor_delayed','off') }}
Note that binary sensors can also have states ‘unknown’ (=system is starting) and ‘unavailable’ (=communication lost), you might want to extend the template sensors for detecting these cases.
I strongly recommend to use packages, allowing you to create a folder with separate yaml files for splitting the configuration. So you could add the template sensors to a ‘hall_sensor_logic.yaml’ so you can keep things organised.
The concept is clear, I have to apply myself in practice.
Forgive the comparison due: in the Vera system there are the Timer Cards, I saw the passage of time being able to create automations based on their term, restart etc. 
Here, I do not see the timer scrolling, I cannot stop it which is frustrating but I will find the way. (maybe it’s the idea for a plugin!)
I tried to understand packages, I saw the aliens 
Your Template works perfectly and thank you, I will use your help to learn more 
To configure the Card, I give error “Custom element not found: alarmo-card”, I think I have to put a “alarmo-card.js” file, (which I can’t find in the link ), into www/alarmo-card and then I have to insert the statement in configuration.yaml, right?
There is a timer entity in HA which can be started and stopped by the user, although I believe there is no ‘live’ countdown visible.
Simply put in the top of the configuration.yaml:
homeassistant:
packages: !include_dir_named packages
#rest of the things, like timezone, units, etc.
Now you can create a folder ‘packages’ and put unlimited yaml files (names don’t matter) here, they will altogether form ‘one big’ configuration.yaml. So it’s just a way of organizing your setup, nothing more.
If you plan to use more plugins in HA, I suggest to install HACS. It’s a plugin which adds a library of 3rd party plugins, so you can simply pick Alarmo, and Alarmo-card for installing. HACS takes care of installing it and gives you instructions of what you should do (e.g. restart HA after installing). I recommend it since it also helps a lot with updating your plugins. Alarmo has releases approximately every month.
For adding the card to HA without HACS, see instructions here.
1 Like
Thanks for your patience, your simple explanations took logic (even packages), now everything works fine.
I wish you Merry Christmas from Italy … a greeting
I am trying to set configuration options on sensors, specifically the front door contact which is set to type ‘Door’. I cannot see any advanced options, just the header for advanced options. I have tried different browsers and the app all do the same.
I cant figure out what I am doing wrong, anybody got any suggestions?
I would expect an arrow button to show up on the right, like so:
From your screenshot it seems to have disappeared completely.
Also, you are missing a similar button at the top for returning from the page:
Are you running latest-greatest version of HA?
Could you switch to standard theme just to make sure it is not hidden due to having the same color as the background?
Can you check whether the icon buttons show up fine in other pages throughout HA (e.g. in Configuration → integrations):
Indeed it was hidden by the dark background, problem solved.
Thanks for much for help
From reading it is mentioned the codes you set are encrypted. Does anyone know if it’s possible to sync those codes or add them via MQTT? Basically, I want my zigbee locl codes to automatically sync and arm/disarm the alarm.
No, the MQTT interface can only be used to arm/disarm the alarm and read back the status. Not for configuration (including adding new codes). Alarmo will not send the code entered for arming/disarming over MQTT, it is also not possible to retrieve the configured codes (since they are stored encrypted indeed).
Hi, i had this component from two month working perfectly i try to arm from panel as normal and last week stop to work. If i try to arm calling service it work, anyway the alarm doesnt trigger alone. Any idea? Thanx
I cannot help you unless you share some details of what doesn’t work exactly (expectation vs reality) and of course the problems can also be caused by your configuration, so please share relevant information.
My alarm state isn’t persistent across HA restarts; it always reverts to unarmed at startup. I briefly used the manual alarm panel prior to adding this integration but not long enough to notice whether this issue existed prior to Alarmo or not.
I’m not sure what relevant information I can provide to diagnose the issue besides the basics:
- Home Assistant 2021.12.9 running on Home Assistant OS
- Alarmo integration 1.8.2
- Alarmo card 1.2.3
- I am not using MQTT
Any pointers would be appreciated.
Alarmo waits with restoring to its former state until all the sensors which are used in that state are restored as well. Maybe there is a sensor which doesn’t start up nicely?
You can find information about this in the logs.
You can also enable debug logging for the alarmo component to see more details.
Thanks for the tips. I set logging to debug and confirmed the alarm was unable to be set due to sensors not being ready. Interestingly I had a zigbee smart plug that was misbehaving that was not related to any sensors used in my Alarm, but it must have been holding up all of ZHA (which most of my sensors DO use). So the issue has been resolved. However, I’d like to understand the behavior in more detail for my own learning. Below are the relevant lines in the log, from both before and after I fixed the issue by removing the plug.
When the faulty zigbee smart plug was connected:
2022-01-17 10:52:34 DEBUG (MainThread) [custom_components.alarmo.alarm_control_panel] Initial state is armed_home
2022-01-17 10:52:34 DEBUG (MainThread) [custom_components.alarmo.alarm_control_panel] Waiting for all sensors to be ready...
2022-01-17 10:53:04 INFO (MainThread) [custom_components.alarmo.alarm_control_panel] Not all sensors are initialized yet, starting anyway.
2022-01-17 10:53:04 INFO (MainThread) [custom_components.alarmo.alarm_control_panel] Cannot transition from state None to state armed_home, there are open sensors
2022-01-17 10:53:04 DEBUG (MainThread) [custom_components.alarmo.automations] alarm_control_panel.master has failed to arm
After the faulty plug was removed from the zigbee network:
2022-01-17 10:56:52 DEBUG (MainThread) [custom_components.alarmo.alarm_control_panel] Initial state is armed_home
2022-01-17 10:56:52 DEBUG (MainThread) [custom_components.alarmo.alarm_control_panel] Waiting for all sensors to be ready...
2022-01-17 10:57:22 INFO (MainThread) [custom_components.alarmo.alarm_control_panel] Not all sensors are initialized yet, starting anyway.
2022-01-17 10:57:22 INFO (MainThread) [custom_components.alarmo.alarm_control_panel] Alarm is armed (armed_home) by Rick.
2022-01-17 10:57:22 DEBUG (MainThread) [custom_components.alarmo.alarm_control_panel] entity alarm_control_panel.master was updated from None to armed_home
First question is that it appears the alarm only waits 30 seconds for sensors to start. Is this adjustable?
2nd question: even after I “fixed” the problem, I’m still getting a warning showing sensors aren’t ready, but the alarm successfully arms anyway. How is it arming if sensors aren’t ready?
Thanks for the help!
This time is indeed set to 30 seconds, my bad. It is currently defined as fixed. I think making it configurable will raise confusion to most users, I rather make a choice that should work for everyone. Feedback about this is welcome though.
Just to be clear, this is the maximum (deadline), if all sensors are ready before, the alarm will restore its state before (in my own home it doesn’t take more than 10 seconds, my sensors are hosted by ZWaveJS / Zigbee2Mqtt).
This means that there are still sensors taking more than 30 seconds, else Alarmo wouldn’t (shouldn’t) wait. I guess you should be able to see this in the history, zooming in on what happens during/after restarting HA. There should be binary sensors in ‘unknown’ state, rather than on/off.
It has this 30 seconds ‘deadline’ because until then the alarm is in unknown (‘none’) state, not offering any protection. I think it is better to have the ‘failed to arm’ triggered in case recovery fails, then to remain waiting for a sensor for indefinite time.
Alarmo cannot judge whether unknown should be treated as safe or unsafe, so ignoring such state is a risk as well IMO.
I think this is an exceptional situation, I don’t expect many people would reboot / update their HA whilst the alarm is armed. Regardless, the restoring of previous state should be handled gracefully, provided your sensors are initialised timely. Do you have a large setup?
I’m still digging into my setup to understand why it takes so long for the sensors to become available. I uninstalled and reinstalled the ZHA integration but it didn’t appear to have helped. I have 18 Zigbee devices, that doesn’t seem to me to be a large installation.
Completely agree. But what is confusing to me is that in my situation, Alarmo is arming successfully while complaining that some sensors are still unavailable. I would have expected Alarmo would do the following:
- As soon as all involved sensors become available, arm the alarm
- If 30 seconds pass, trigger the ‘failed to arm’ message
However based on what I see in the logs, it seems to be doing this:
- Wait until all zigbee sensors are available, regardless of whether they are involved with the alarm or not
- When all sensors are available, or when 30 seconds pass, attempt to arm the alarm.
a) If the involved sensors are available, the arming is successful.
b) If the involved sensors are unavailable, trigger the ‘failed to arm’ message
Am I understanding the logic correctly? If so, why is this preferred over the logic that I expected to see?
Zigbee2Mqtt may be the ultimate solution, so that a restart of HA doesn’t affect my Zigbee network. I found this post which I may replicate in the future.
I would be interested to know what a “normal” Zigbee initialization startup time is, for people who run ZHA as opposed to Zigbee2Mqtt.
Could you open a github issue for this to discuss this more?
Regardless of ZHA being slow, the state restoration should make sense.
I would like to look into what’s happening and what could be potentially improved on the side of Alarmo.
This is definitely not how I intended it to work.
Also the 30 seconds delay was intended to be a ‘worst-case scenario’ restore fallback mechanism, if it is reached every time this is not good.
1 Like