I have the BWAlarm (ak47 edition) installed via HACS and for some strange reason one of the automations turns itself off. I can’t find any code which is doing this but maybe another set of eyes can help me.
It is happening when the alarm goes to ‘armed_away’. So I figure it’s either the ‘pending’ finishing that causes it or the ‘armed_away’ starting that causes it.
I have a few related scripts but nothing sus there either:
#script:
alarm_lights_on:
alias: Alarm Lights On
# alias: Turn ON the alarm_lights group in police mode
sequence:
- service: homeassistant.turn_on
data:
entity_id: group.alarm_lights
effect: police
#script:
alarm_lights_off:
alias: Alarm Lights Off
# alias: Reset the alarm_lights group to no effect and then turn off
sequence:
- condition: state
entity_id: group.alarm_lights
state: 'on'
- service: homeassistant.turn_on
data:
entity_id: group.alarm_lights
effect: stop
- service: homeassistant.turn_off
data:
entity_id: group.alarm_lights
#script:
house_alarm_away_mode:
alias: House Alarm Away Mode
# alias: Turn house alarm ON in away mode after an exit delay (plus the usual alarm exit delay)
sequence:
- service: tts.google_translate_say
# - service: notify.google_assistant_broadcast
entity_id: media_player.bedroom
data:
message: 'Arming house alarm in one minute'
- delay: '00:00:05'
- service: alarm_control_panel.alarm_arm_away
entity_id: alarm_control_panel.house
So other than this being something within the custom component that is causing it, I can’t see the issue. Any help would be great. Cheers
Its as per the image, the automation called ‘[Alarm] Warning’
This is one example of many (only this single automation ever turns itself off each time), all happening in relation to the alarm being armed, so not a coincidental time. As you can see below, it happened again this morning under the exact same conditions:
I think given the above, it’s fair to say that disabling the component will certainly stop it happening since I won’t have an alarm system to arm, which is clearly causing this. Nothing else is in the log at this timestamp
Hey - is the automation in the group: group.alarm_lights ?
You turn off everything in that group with your script … if the automation is there (perhaps from the old frontend where you might have used it for a card), it will be turned off also
Also, I have done a search of all my yaml files for the text ‘warning’ and nothing comes up other than what I have posted above. There simply isn’t any code that I can see which causes this action
… so I set the logger to debug for this component and have discovered the following. The component is turning off the warning for some reason… I just don’t know why
Well, do you know why it’s there? Here is the description. Namely,
warning
(string) (Optional)
Entity ID to turn on when the alarm has been tripped.
alarm
(string) (Optional)
Entity ID to turn on when the alarm has been triggered.
When alarm is armed, they both being turned off to ensure they’re off.
So basically it designed for switches that control sirens/lights/etc and not for automations.
Does it explain your situation?
ah! right. Ok, thanks for that. To be honest I hadn’t gone back into the docs regarding this. Its strange though because I have been using this component since it was first created by the original author and I don’t remember it behaving this way. I guess I just didn’t notice. I’ll remove that entity and it should be fine
Actually, I just re-read that description and I’m certain that in the past this was able to trigger the warning automation. Could you please check the component code to see why this is no longer the case? Either way, the docs say that it will turn on that entity when the alarm is tripped, not off when it is armed. I think there is still an issue here. As I said, I have been using this without this problem with this same config since it was created by @gazoscalvertos
If you can read the code, have a look at the last original version (4 strings down, turn_on) and compare it to the code in my repository (tbh I can see no difference). It extracts domain from the string and calls domain.turn_on in both cases. Same goes to turn_offlater.
And guess what happens when you call automation.turn_off?
well, there’s a lot happening under the hood as you saw in the debug print.
and if you check the original code, it does exactly that - turns off a warning and alarm entities upon setting the alarm.
And if you ask me why, I’d say ‘God knows’ but my idea is this code resets the entities (remember, they are switches) to make sure they are off.
Is that an issue? Don’t think so unless you convince me as I can see no harm in switching off a switch that controls a siren and the alarm is not triggered
If you wish, you could install the original component and check if that actually was the case if after all the evidence you don’t believe me.
As I showed here, I haven’t changed the code in question and without a valid evidence I can see no reason in changing anything now.
The only thing I might do it to change code so it rejects automations as entities but I don’t think it’s necessary - maybe I’ll just issue a warning instead…
Hope it’s understandable.
yeah, no longer needed.
AFAIK the TS used it to make sure it’s definitely on during his fight with the ghost automation killah
Well I guess I could change the warning automation to a script so that this component simply executes the script. Having a single entity as the warning seems too basic for my liking as I use the warning to trigger a TTS to a nearby Google Home as well as send a message to our phones. This is why I use an automation. For the record those automations were provided (as templates to modify to our specific needs) by the original author.
I haven’t tested it yet. Would this then mean that there is similar code for the alarm triggered event? Because this brings me back to my previous comments about using automations. Currently I have an ‘alarm triggered’ automation which gets triggered on alarm and works perfectly…
Let’s not this topic for that. If you think something is not quite right, please open a new issue on Github as it’s easier to keep track of such things that way.
