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
Hi. I installed the Alarmo integration following the instructions. The last version. After the restart requested, however, the integration does not appear in the menu.
Has anyone had this problem before?
Thanks
I heard about such problems more than 20 times now 
This is a known problem of HA, and is solved by emptying your browser cache.
Note that you can check that the installation is successful by checking in the HA logs for a line ‘you are using a custom integration Alarmo bla bla’ which should appear right after startup of HA.
Could we get an HA service or something that I can call to do it? I don’t see how that’d be any less secure than the rest of the settings done in HA. That would allow it to work a little more like one alarm system.
1 Like
I followed your advice and it works. Thanks
A service to do what exactly, store new users in Alarmo?
I don’t think this is a fair request.
Services in HA are meant for operation purposes, not for setup/configuration. I would like to stick to that.
I would say you should just (one time) configure the same users/codes for Alarmo as you have in your lock, and then you should be able to operate both together.
Does anyone have recommendations for a lovelace config which shows only the state of the alarm (e.g. a badge), but when you tap it, it pops up the keypad so that you can arm or disarm it?
I have mine set up with a badge showing alarm state, but when I press the badge I get the normal HA entity popup, so I don’t get the Alarmo features that show me open sensors, etc.
I know I can add the Alarmo card, but then the keypad shows all the time, and it takes significant screen space.
I’d be interested to know what others have done.
What you see here, with the keypad, is just the ‘device’. I think using a ‘button’ card with tap/hold/double tap options will help you a long way. You can link almost anything to those, like I have here with a Boolean and automation.
What theme do you have? 
I guess I was just trying to have the same functionality of existing alarm systems, which I thought was a goal of Alarmo. Existing alarm packages integrate the users in the keypad/alarm “hub” with the locks if added to their system. Such as Vivint.
Thanks for the reply. I’m using the iOS themes from basnijholt, specifically iOS Dark Mode Theme - blue-red
For the alarm, I can do a button, but this is for a wall-mounted panel in my hallway. So I could have the button call a service to arm the alarm, but that requires defining the PIN in the service call and therefore prevents asking the user to enter the PIN. I need the ability to pop up the keypad to ask the user to enter the PIN.
I did some more digging and found browser-mod which has the ability to make a popup. This, in conjunction with the button card, got me what I wanted!
- type: button
entity: alarm_control_panel.master
tap_action:
action: fire-dom-event
browser_mod:
command: popup
deviceID: this
title: Home Alarm
card:
type: custom:alarmo-card
entity: alarm_control_panel.master
name: Home Alarm
use_clear_icon: false
Looks like since some time it is again not possible to start a script in the action section.
Will this feature come back or do I have to implement a workaround with an automation triggered on status change?
Someone knows?
Does anybody here arm a DIFFERENT depending on the sun’s azimuth and elevation?
One of my sensors gets triggered by raking sunlight at this time of year.
1 Like
This is not intended. If there is such issue I might have broken it 
You can create a bug report and I will take a look.
You could set up a sensor group, such that 2 sensors need to be triggered together, before the alarm is triggered.
good shout, didn’t know about sensor groups! thx