Your solution is interesting, but not sure will work if you are in a hurry to leave. We should consider these cases:
Use of the alarm card. You just get a message with the “Continue” and “Cancel” buttons. You can decide immediately if to override or not.
You arm the alarm using a button (my case). In this situation you can only rely on the smartphone for the message, but I think is not immediate to use. In my case I use a small color bulb that blinks when arming/pending, turns a different color when armed night or away. Works fine, maybe I could add a different color here to show there is a sensor on and so can’t arm. In this case you can check for the sensor or just re-arm to override without even looking at the phone.
Woul be nice to have a device (color bulb) output where to show all the “statuses”.
Armed automatically when you leave the house. In this case you can rely on the smartphone for messages.
@neliss One more thing about sensors. Right now you can set a sensor to trigger when armed in open or more modes. But there are sensors, see the water sensor, that you may want to trigger the alarm, even if disarmed.
For example, I have a rainwater collection well that when reaches a certain level a sensor starts the pump to empty the well. I have an extra sensor that sends an alarm in case the water overflows because the pump doesn’t work. Right now it is connected to a Gigaset Elements system that triggers the alarm even if disabled; it saved me from flood a couple of times already.
@ everyone: I appreciate your enthousiasm and all ideas I received so far
Now I need some time (let’s say ~2 weeks), to add all these discussed improvements.
I’d like to ask to stop asking for more features for a bit…
Because it’s getting overwhelming and I cannot keep track of it all
If you want to help me: please transfer/organise/bundle your suggestions as feature requests in the issue list of my GitHub page.
This helps me to keep track of the todo list.
I do require sending the code via MQTT as it’s a requirement of the alarm interface I’m using (and adds security… to a security system)
I would like to have ARMED_AWAY, ARMED_HOME, DISARMED, PENDING, TRIGGERED exposed.
I have different MQTT topics for ‘in’ and ‘out’ of the alarm interface.
Feedback for sensors is in the ‘out’ topic (data OUT of alarm)
Option to overirde would be good but I my commercial alarm system only allows this for zones (inputs) that I have coded to allow it. If you added the ability to selectively control which zones (inputs) allowed for overriding, that would be really nice since some really shouldn’t be overridden for security purposes.
Having the option for multiple (at least two) ‘areas’ would be awesome. Multiple ‘areas’ is very common in commercial alarm systems (my old house alarm could do up to 256), my current system has two areas which can be ARMED_HOME, ARMED_AWAY or DISARMED independently, allowing a shed for example to be armed separately from the house. Each area has it’s own parameters for ENTRY DELAY, EXIT DELAY, SIREN, etc. It’s basically the same as having two completely independent systems, but controlled from one panel.
Works fine so far. But I got one question. Does the alarm be armed automatically when the users leave the house? Because for me this doesn’t work and I had to arm the system with an automation.
No, nothing is in place for this yet.
Currently I’m working on improving the customisation of notifications and devices to be triggered on alarm (like siren).
It could be a next step to add functionality for automatic arming.
This is very user-dependent so it will never be fixed in Alarmo, but perhaps configurable.
How would you deal with cases like a window that you left open, or a failing sensor?
Alarmo will not be able to arm if there are open sensors.
You will be able to receive a notification of these issues, but perhaps you are already on the road by the time you receive this.
I am planning to add a function like: if you try to arm and there are failures, it does not work (you will get notification). If you arm again within, say 5 minutes, it will be ‘forced’ and sensors that are open at that point will be blacklisted/bypassed temporarily (until next disarming).
I prefer democratic decision making Please let me know your preferences, and I will take them into account for improvement.
As I mentioned a few posts above, this is common in commercial alarm systems, however they also usually give you the option to enable/disable this on a zone (input) by zone basis since some things should never by bypassed.
I think that automation could be left to the user, with the preferred own arming logic.
Talking about other things, a way to define multiple sirens could be useful.
And finally, I want to ask (I’m a newbie) how a sensor can be bypassed.
Example: during the summer I left my covers closed but window opened. Covers and windows has separate sensors, but both as perimeter. I want to arm the alarm, bypassing the window one… having the possibility to close the window during the night without disarm and without triggering the alarm.
Now I handle this on my zwave controller (zipabox by zipato, that I want to abandon, so I’m playing with HA) that has a virtual alarm system that works with that logic: if a sensor is not ready for arming, I can bypass it, so I can arm the alarm, than I can close the window during the night without alarm disarming (but the next opening cause the alarm to trigger).
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.
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?
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_panel entity will now expose a changed_by property 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.
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!
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.
Please let me know your preferences, and I will take them into account for improvement.
