Nice! I will try this component as well 
thanks for your efforts, people like me (who can barely get yaml files working…) really appreciate this help.
Maybe @KTibow can help? I saw he managed that in the scheduler card and his comments were quite useful for me 
Very excited! BWAlarm is the most useful integration for me.
One desire or suggestion. Excuse me if it is a no sense. I would like to add some sensors that should trigger alarm always. No matters if armed of disarmed, away or home. That´s for smoke, gas or water flow sensors. This way I could manage all these sensors into alarm system.
Also, I could help with Spanish translation.
Makes sense.
I never said Alarmo was only a burglar alarm, it could be more versatile than that 
Could you make a Feature Request for it on GitHub?
I’m mostly interested in the desired response to an event:
Would like to gather opinions before making something 
Translations will come soon!
Hi, if you want i can translate It in italian.
Great job!
Thanks for your work
I love this component and i am watching if i will replace my appdaemn alarm system. But I am missing something like Device_tracker to automatically arm or disarm … any chance to add those?
Something I realised doing some testing on my side, changing the entry time from 60 to 30 seconds, it remains the same even though I saved it.
Hi,
Very exciting new component. I am going to try it when I have time.
One thing I use with others HA alarm components is audio messages from Google cast via tts.
Something like, “The alarm is arming, and you have to exit before 30 secs.” when the state of the alarm goes to “pending”.
Or “The alarm is armed. Please, enter your code” when it goes to “warning”.
Those are simple automations not related to this or other components.
What I would like, is that when someone tries to arm the alarm and one or more sensors defined are open, the process is aborted and somehow, HA knows it and I could automate a response via tts like: “The alarm could not be armed because of this (or these) open sensors”
Could that be possible?
Thanks for your work.
You could already make an automation to arm or disarm the alarm based on state update of your device_tracker.
But ideally it should be supported from within. But it might take some time before I can implement this properly.
Did you think of how to handle your pincode?
Ideally the alarm should recognize that it is being armed through an automation (instead of manually), but I’m not sure if this is possible in HA (since its just a service call).
Are you planning to add the code in your automation? Or is your alarm set without code?
Oh weird. I will look into that.
I noticed that sometimes the browser is not synced/refreshed after the configuration is saved, but I guess thats not the case here.
Is this for all arm modes?
For now you can make automations that watch the state of the alarm.
But eventually these things could be integrated in the UI.
Especially since you want to know some variables, such as a failed sensor preventing you from arming, or the actual leave time (which you might want change to something else than 30 sec)
Such a message is already sent through the built-in Push notification. But I received already enough feedback that I want to make the user decide which service / format is used.
I would like to be able to make actions configurable on any state change (or failed state change).
I would prefer to create a text field where you could enter your message to be sent to the Google service call (or whichever you choose), and in that message you could use wildcards like {{ open_sensors }}.
This seems much more user-friendly to me than exposing such variables as attributes of the alarm_control_panel entity, which you would need to process through jinja templates in an automation…
It is, I have just tested and it happens in all modes but only with the entry time.
I am actually using Appdaemn to arm or disarm the alarm_panel. I will just replace then the alarm_panel entity and configure my appdaemon app that your component will control the pannel iso appdaemon. for the moment i use a code yeah which is automatically insert by the appdaemon app.
That sounds pretty reasonable. My vote for that way.
Thank you for this @neliss.
I tried to go back to manual alarm after BWalarm stopped working but i wanted multiple user codes. You have saved the day!
Thank you for this @neliss.
The panel will not ARM HOME (w/ and w/o code being required) while ARM AWAY and everything else seems to work fine.
That’s weird, tcs2tx, I have just tested this on mine and it is working well. Do you get any error in the logs? Have you got any previous automation that could be messing with this? If you go on developer tools, state, does the alarm just stay in disarmed when you try to arm home?
I figured out the problem - the problem was that in the configuration settings, there are settings under the General tab for (1) Arm Away, (2) Arm Night and (3) Arm Home. After installation, only Arm Away is enabled but the Arm Home is included on the default card that is populated in Lovelace. This is a test machine that was setup only to test the alarm, and I had mistakenly enabled Arm Night instead of Arm Home. Now that I noticed the disconnect, Arm Away now works after enabling it in the settings. For reference, everything works if I create a custom card and choose what States to include on the card that match the enabled settings. So, everything works as it should. I suspect that most people will end up using some sort of custom card, but you may want to consider enabling Arm Home by default or having the buttons on the default card match what is in the settings so idiots like me will not have a problem with the default install.
EDIT - Once again, thanks for your effort on this project. I am new to Home Assistant and only a hobbyist (not an IT professional). This is the first time I have tried to set up an alarm and I was expecting it to be MUCH harder from a programming standpoint. I am very surprised and VERY happy how easy it was to install and setup a basic working solution, despite me being an idiot with the problem I raised here.
Ah ok, I’m glad that its a simple issue
Nothing wrong with mentioning a suspected bug. It suggests things are confusing anyway.
Actually I filed a bug/feature report in the HA repo a while ago about this.
It doesn’t make sense that the user has to tell which arm modes the alarm has, the card could just check the properties of the entity to see what it supports.
Even a more severe issue in HA: if you open the more-info dialog of the alarm_control_panel entity, you will find it always shows ‘arm away’ and ‘arm home’ as options, no matter what capabilities your alarm actually has.
There is also no feedback for the user, clicking will simply have no effect if the alarm does not implement these modes.
Very user-unfriendly. I think a lot of people will make the same mistake as you.
In my opinion the problem is in HA (as I just mentioned).
Fixing it in this component would be a plan-B.
The Arm Night mode of an alarm system is much more common than Arm Home (I mean, who turns on his alarm during the day, while being at home? not me )
This is exactly why I chose to enable Arm Away and Arm Night by default.
Glad you like it. But this is just a very simple starting point, you know.
I intend to develop this project a lot more. Hope you stay onboard to discuss useful features.
Just trying to get this to work but not having much luck:
{{ states[states.alarm_control_panel.alarmo.attributes.changed_by.split(".")[0]][ states.alarm_control_panel.alarmo.attributes.changed_by.split(".")[1]].name }}
This would tell me which sensor was triggered but I am getting a:
UndefinedError: ‘None’ has no attribute ‘split’
So not sure if this is not available with alarmo or I am missing something else (which is also possible) 
No this is not implemented (yet?)
Was it exposed like this in BWalarm?
Why would you expect an array of values here? Usually one sensor trips first right?
My view on this matter:
This is what I used to on bwalarm bu I just asked to confirm if I was doing something silly. I had to clean a lot of stuff from my automations and going through it, I saw the warning I had before.
The way you describe for sure looks more user-friendly and I believe it would also be easier to manage too.