Which means that if we have a door sensor and an intruder left it open, it’ll scream until disarmed, right? 
Provided there are only door sensors configured. It won’t be that easy with PIRs…
Anyway, I’ve just uploaded a new version of alarm_control_panel.py that checks the sensor that triggered the alarm when trigger_time elapses and re-triggers the alarm if it’s still active.
Feel free to check it out and comment.
so if an intruder enters alarm hits and if closes the door and time pass still there will be no siren. thats a problem too. i think it must hit until disarmed. gonna check more on commercial alarm systems routine
not really. the alarm (triggered) state will last for trigger_time seconds.
I believe it’s possible to add an option for that, but why not set trigger_time to 31556952?
It shouldn’t, because HA works on changes of state, not just state itself. It triggers when the door sensor goes from closed to open.
That’s what I’m saying, if the alarm didn’t re-trigger then the PIR’s would be useless after the initial siren time.
HA works on changes of state, but we started here:
Which means:
From my point of view there was only one state change, in step 2. And as you say that
we should go to step 3, that why I said
Do you see what I mean?
Wow. Actually I’m saying completely the opposite. My point was that even if an intruder waits for the siren (triggered by a door sensor) to expire and then then moves into any room with a PIR sensor, there will be another alarm. Don’t you think so?
My initial discussion was talking about how a commercial system works, not HA. That said, it’s been a while since I last tested a commercial alarm system so I can’t remember what happened when a door was left open and the siren timed out. HA does in fact require a change of state, not just a state by itself.
Yes, you are correct, if the installation has both door and PIR sensors, then if an intruder waits out the siren time (caused by the door sensor) then walks into the path of the PIR it will trigger the alarm again. However this is because they have triggered a different sensor. That is the key point here: a new state change has occurred, whereas the initial sensor (the open door) has not changed state. The alarm will re-trigger based on this new entity changing state.
I’m pretty sure we are on the same page here dude, all good 
well, I was talking about this component with a behaviour similar to a commercial system (as I have zero experience with them).
Just want to point out that there’s nothing to do with HA itself here. It’s all about this component. For example, with my latest change the alarm is triggered by sensor’s state change, BUT it re-triggers if that sensor’s state still active, i.e state itself. It’s all in our hands (code)
Good. I just wanted to point out that difference between this component and a commercial system is prominent if an alarm’s source is a sensor with “permanently” changed state (i.e door sensor) rather than “momentary” one (i.e PIR). And therefore it’s vital to have an adequate variety of different types of sensors to make your house more secure.
Sure. As I said, we can always fine-tune our component according our needs so feel free to try my latest change to see if it makes things any better
That recent change definitely sounds good as it closes up that issues that HA has with requiring a change of state to create an action. I’ll give it a try next week when I get time.
Thanks for your efforts with this component by the way. A lot of us are very appreciative!
hmmm, so this doesn’t do anything
alarm_arm_instant_perimeter:
sequence:
service: alarm_control_panel.alarm_arm_perimeter
entity_id: alarm_control_panel.house
data:
code: '-1'
wonder why?
the negative 1 for a code…?
Yeah, that changed at some point, this code works, try it for perimeter instant arming:
alarm_arm_instant:
sequence:
service: alarm_control_panel.alarm_arm_away
entity_id: alarm_control_panel.house
data:
code: 'override'
Thanks - but wouldn’t that need to be:
alarm_arm_instant:
sequence:
service: alarm_control_panel.alarm_arm_night
entity_id: alarm_control_panel.house
data:
code: 'override'
also I think I must be on an older codebase because my other scripts use -1 and they arm. hmmm. Thank you
By this:
I meant (and should have said) adapt it for your perimeter mode case.
This is the error my script generates:
homeassistant.exceptions.ServiceNotFound: (ServiceNotFound(...), 'Service alarm_control_panel.alarm_arm_perimeter not found')
Yet I can arm perimeter mode via the Alarm GUI or even by calling it from dev tools, viz:
the code seems to be unable to decide whether it’s perimeter mode or night mode. The two terms are used seemingly at random in alarm_control_panel.py
Going to try a reboot. I am modifying my scripts file on the fly but possibly it’s loaded into memory only once on HA boot?
-1 was change to override some time around Nov 2018:
Thanks all; this works for me now. It seems the scripts YAML file IS only loaded once on bootup and edits don’t take effect until after a reboot.
alarm_arm_instant_perimeter:
sequence:
service: alarm_control_panel.alarm_arm_night
entity_id: alarm_control_panel.house
data:
code: '-1'
Does anyone know if @gazoscalvertos ever released any of the changes/improvements shown in this vid?
yes, you need to restart HA. there might be another way, but still it won’t do it automatically
haven’t tried the Reload Scripts yet as from my experience the HA GUI interface sometimes doesn’t work well, I prefer cli.
some of the features are in the current code (this repo), but not all as far as I can tell
You can use the service: script.reload
