Agreed. I currently have my automatic arming disabled if ‘Guest Mode’ in ON, so I like having control of this myself
great module. thank you!
don’t know how far you want to go with Alarmo, but i would love to see a presence simulation in HA.
of course it’s relatively simple to do a static simulation,
but i think the perfect presence simulation should capture the movement (lights on/off) from the last couple of days and clone it.
- no tinkering for the users
- impossible to see a difference in behavior
maybe alarmo could be the right module for this ?
I like the idea, but it will be quite a challenge to implemented this.
Currently I’m pretty busy with making the core + UI of the alarm more mature + configurable.
The whistles and bells have a low priority now…
1 Like
Hi Dave,
I’m working on the MQTT implementation as we speak.
I have some open items, would like your feedback on them.
Current status:
In the command topic, two payload formats are supported:
- Simple string, like
"ARM_AWAY" - JSON format: like:
{command: "ARM_AWAY", code: 1111 }
The command will have no effect if a code is required for the (arm / disarm) command but not provided.
If the ‘require code’ option in the mqtt configuration is disabled, the code checking / authorization is
skipped.
In the HA mqtt alarm control panel, these command strings are configurable. Is this option useful in your opinion?
What do you mean by this?
Only that state and command are separated?
Or does the command need a feedback topic?
I saw something like this in the homebridge implementation (there is a setTargetState and a getTargetState topic). It’s used for acknowledging the command here, to detect a non-responsive
alarm controller.
This is TBD.
Wondering about the best solution still. Currently I’m thinking about sending a dictionary, with <entity_id>: <state> format per blocking sensor.
I guess also other non-happy-flow scenarios (such as a wrong pincode) should get feedback.
I tried to add an ‘availability’ topic as well, but I noticed that I couldn’t configure a last-will message (to notify the endpoint of Alarmo going down).
I kind of gave up on this, I guess the birth/last-will mechanism of the HA MQTT component should be sufficient as well (except when Alarmo crashes while HA keeps running).
Was surprised to see that the availability topics of the MQTT alarm_control_panel are input data (so from HA-side it is monitored if the endpoint goes down).
I’m not sure what the use-case would be for this, since I assumed an endpoint is typically an HMI panel (like a touchscreen/button pad in the hallway).
IMO Alarmo has no dependency on this device, so I wouldn’t know what response should be if the panel goes offline.
Any thoughts on this?
I think the easiest is to take out the middleman here (being me) and link you to the interface I use.
A new release (v1.1.0) of Alarmo just came out 
This release comes with a lot of big changes. Most of which are under the hood.
I will try to summarize what I worked on.
Migration to Websocket API
(TL;DR - This update has breaking changes, upgrade on your own risk)
One of the main difficulties with this UI-based component is handling storage of configuration.
Since settings are not stored in a YAML file, a different way of storage is needed.
Up to now, the settings were stored as attributes in the alarm_control_panel.alarmo entity.
This approach is quite common, but is not very scalable (things get messy and bulky quickly).
I consulted with the HA dev team for an alternative. The advice was to use the internal Store class (which uses the HA SQL database) for storage.
Since configuration is not readable from the alarm_control_panel entity anymore, a new way of communicating between the frontend and backend is needed.
Enter the Websocket API, a method that allows the Alarmo panel read/write access with the database through the alarmo component.
I love the change. It opens many doors for future expansion and works very intuitive.
The bad news: this method is not compatible with the old method of storage + communication.
So: by upgrading Alarmo to this version, you will lose all your settings.
I hope this is a one time thing.
UI structure improvements
I got some feedback that the Alarmo panel didn’t display well on all devices and/or themes.
I worked hard to make the UI more mobile-friendly and in style of HA.
Most changes are subtle, I trust you will be able to find back your settings where you expect them.
I created a ‘localize’ file, which allows the Alarmo panel to be translated. I will need some help from you to get all major languages in place (I can only cover English and Dutch).
I propose to wait a bit more to allow the dust to settle (there may be some structural changes up ahead).
Other changes
-
There is a new Notifications editor that allows you to customize notifications. I tried to take into account all your wishes, think it turned out pretty nicely.
-
For defining other actions (switching devices), a similar panel is in the making. It is not yet in place, but will come in a bit. Ofcourse you can use an automation in the mean time.
-
There is MQTT support in place. It will be extended to provide more flexibility, but already supports setting/getting states similar to the HA MQTT alarm_control_panel.
-
Support is added for always-on sensors (like fire detectors). They will always trigger your alarm, even if it is disarmed. I’m planning to extend the customization, because it currently results in immediate activation of the siren, WIP.
-
An option is added to allow sensors to be open/active/on after arming. This is meant for motion sensors that take longer to reset than it takes you to leave the house.
-
The
alarm_control_panelentity will now expose achanged_byproperty with the sensor (or sensors) that triggered (or blocked arming of) the alarm. This provides a means to create automations outside of Alarmo.
I probably forgot some more stuff that is worth mentioning. Sorry about that.
Note
Due to the amount of changes, there are probably new bugs introduced.
Please take this into account. Better not to rely on it for the security of your house.
Let me know if have issues (preferably via GitHub), it helps me speed up the development.
3 Likes
For some reason I can’t arm. I have some doorsensors setup, created user with code and when making an alarm panel with alarmo as alarm, i want to arm home and it just don’t do anything. in logs it says: wrong code provided. What’s causing this? Even without code in config, it won’t arm.
THanks!
2 Likes
I am having the exact same issue !
1 Like
Just saw that my alarm is now showing up as armed and I can’t disarm it, that’s weird. I couldn’t arm before and now I can’t disarm it. I am still looking into it but just wondering if someone else is seeing the same.
Edit: Actually, the alarm state is unavailable which I don’t get it as it was available (though not allowed to arm it) without changing anything. Edit2: Got it sorted, had to remove from integration and re-add it, very weird. Still can’t arm it, though.
The message “wrong code provided” means exactly what it says.
There are two conditions in which you can get this error:
- No code (or empty string) is given as code,
- There is no user which has a code matching with the one you entered.
In addition to that, 1+2 will only be checked when you have configured the alarm to require a code:
With the info you provided i cannot say more than this at this point.
Are you using the Lovelace Alarm Panel card for controlling the alarm?
Please use GitHub for reporting issues.
Im using your alarm now just came from bw aalarm keep up the good work
1 Like
Okay Neliss,
So why can’t I arm my alarm:
When I press “arm home” nothing happens, on my log there’s no result showing that something went wrong, but still it won’t arm.
edit: found it.
YOu have to give some time (10 seconds) as delay in order for it to work
There is currently a bug, if you set leave time to None, it won’t arm. If you increase that, then it will arm. It was discussed in the issues on github, i reported it.
@martheijnen Please don’t report issues here.
If everyone starts doing that, the thread will become a big mess in no time.
And please, when reporting an issue, always:
- Check which issues are already reported by others
- Check which version you are using (both the component/backend and the panel/frontend)
- Check the error logs for clues
- And ofcourse share this info when reporting an issue
As @Memphisdj said, there is a small error in the code which results in an error when leave time = 0. I am working on it.
I have just installed this and great work.
I have now setup 2 users but the changed_by: will stay null
Is there anything else to do?
Changed_by will give info about the sensors that caused triggering of the alarm or blocked the alarm from arming.
It is not related to users.
I’m not really a fan of the naming either, but this property is defined by HA and I think is what it’s meant for.
I could add a property that tells you whose code was used for arming/disarming.
That makes sense then.
Would be nice to have sensor to see who has changed the alarm
1 Like
Hi there gr8 work you have there is it possible to by pass sensors? If i have 1 2nd floor window open allow me to arm the alarm anyway?