Automation keeps turning off - related to BWAlarm (ak47 edition)

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 seems to happen when the alarm arms as per:


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.

Here are the automations relating to the alarm:

- id: alarm_armed_away

  alias: '[Alarm] Away Mode Armed'

  initial_state: 'on'

  trigger:

  - platform: state

    entity_id: alarm_control_panel.house

    to: 'armed_away'

  action:

  - data:

      message: 'Alarm Away Mode Armed'

    service: notify.html5


  - data:

      message: 'House alarm armed, away mode'

    service: tts.google_translate_say


    entity_id: media_player.lounge_mini

- id: alarm_armed_home

  alias: '[Alarm] Home Mode Armed'

  initial_state: 'on'

  trigger:

  - platform: state

    entity_id: alarm_control_panel.house

    to: 'armed_home'

  action:

  - data:

      message: 'Alarm Home Mode Armed'

    service: notify.html5


  - data:

      message: 'House alarm activated, home mode'

    service: tts.google_translate_say


    entity_id: media_player.lounge_mini

- id: alarm_arming_away

  alias: '[Alarm] Away Mode Arming'

  initial_state: 'on'

  trigger:

  - platform: state

    entity_id: alarm_control_panel.house

    to: 'pending'

  action:


  - data:

      message: 'House alarm activating, away mode'

    service: tts.google_translate_say

    entity_id: media_player.lounge_mini

- id: alarm_disarmed

  alias: '[Alarm] Disarmed'

  initial_state: 'on'

  trigger:

  - platform: state

    entity_id: alarm_control_panel.house

    to: 'disarmed'

  action:

  - service: switch.turn_off

    entity_id: switch.alarm_siren1_switch

  - service: script.turn_on

    entity_id: script.alarm_lights_off

  - service: notify.html5


    data:

      message: 'Alarm Disarmed'

  - data:

      message: 'House alarm disarmed'

    service: tts.google_translate_say


    entity_id: media_player.lounge_mini

- id: alarm_triggered

  alias: '[Alarm] Triggered'

  initial_state: 'on'

  trigger:

  - platform: state

    entity_id: alarm_control_panel.house

    to: 'triggered'

  action:

  - service: switch.turn_on

    entity_id: switch.alarm_siren1_switch

  - service: notify.html5


    data:

      message: 'ALARM TRIGGERED!!! {{ states[states.alarm_control_panel.house.attributes.changed_by.split(".")[0]][ states.alarm_control_panel.house.attributes.changed_by.split(".")[1]].name }}'


  - service: script.turn_on

    entity_id: script.alarm_lights_on

- id: alarm_warning

  alias: '[Alarm] Warning'

  initial_state: 'on'

  trigger:

  - platform: state

    entity_id: alarm_control_panel.house

    to: 'warning'

  action:

  - service: notify.html5


    data:

      message: 'ALARM Warning {{ states[states.alarm_control_panel.house.attributes.changed_by.split(".")[0]][ states.alarm_control_panel.house.attributes.changed_by.split(".")[1]].name }}'

  - data:

      message: 'House alarm tripped and authorities notified. Get out of the house'

    service: tts.google_translate_say


    entity_id: media_player.lounge_mini

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

where is it?

just because it’s around that time? their code has nothing special. can you reproduce if you trigger them manually?

well… disable the custom component and see if it goes (hiding) :wink:

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

Just a thought

Phil

No, that only has lights in it:

alarm_lights:
  name: Alarm Lights
  entities:
    - light.bedroom_lamp
    - light.couch_light
    - light.front_door_light
    - light.living_room_light
    - light.ensuite_light

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

does it happen every time you arm away?

what log? have you checked logbook? or, if you can reproduce it, have you tried changing log levels to say, info?

and what does that mean?

out of interest, could you post your bwalarm.yaml here?

Yes

The history page since it was easy to display

… 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

2020-02-25 07:08:32 DEBUG (MainThread) [custom_components.bwalarm.alarm_control_panel] [message_received] payload: “armed_away”
2020-02-25 07:08:32 DEBUG (SyncWorker_33) [custom_components.bwalarm.alarm_control_panel] [alarm_arm] (service: alarm_arm_away, passcode: “None”, ignore_open_sensors: False) begin
2020-02-25 07:08:32 DEBUG (SyncWorker_33) [custom_components.bwalarm.alarm_control_panel] [alarm_arm] no code required, alarm_arm_away the alarm as “HA”
2020-02-25 07:08:32 DEBUG (SyncWorker_33) [custom_components.bwalarm.alarm_control_panel] has_open_sensors all clear
2020-02-25 07:08:32 DEBUG (SyncWorker_33) [custom_components.bwalarm.alarm_control_panel] [process_event]
2020-02-25 07:08:32 DEBUG (SyncWorker_33) [custom_components.bwalarm.alarm_control_panel] [process_event] state changes from disarmed to pending
2020-02-25 07:08:32 DEBUG (SyncWorker_33) [custom_components.bwalarm.alarm_control_panel] [process_event] Pending user leaving house
2020-02-25 07:08:32 DEBUG (SyncWorker_33) [custom_components.bwalarm.alarm_control_panel] [setsignals] armed_away
2020-02-25 07:08:32 DEBUG (SyncWorker_33) [custom_components.bwalarm.alarm_control_panel] [save_alarm_state] (pending) begin
2020-02-25 07:08:32 DEBUG (SyncWorker_33) [custom_components.bwalarm.alarm_control_panel] [_clean_states_info] remove check_before_arm from states
2020-02-25 07:08:32 DEBUG (SyncWorker_33) [custom_components.bwalarm.alarm_control_panel] [save_persistence] File “/config/resources/bwalarm/bwalarm.json” saved successfully
2020-02-25 07:08:32 DEBUG (SyncWorker_33) [custom_components.bwalarm.alarm_control_panel] [save_alarm_state] (pending) end
2020-02-25 07:08:32 DEBUG (MainThread) [custom_components.bwalarm.alarm_control_panel] [code_format] self._code: REDACTED, self._state: pending, code_arm_required: False, returning number
2020-02-25 07:08:32 DEBUG (MainThread) [custom_components.bwalarm.alarm_control_panel] [device_state_attributes]
2020-02-25 07:08:32 DEBUG (SyncWorker_33) [custom_components.bwalarm.alarm_control_panel] [alarm_arm] (service: alarm_arm_away, passcode: “None”, ignore_open_sensors: False) end
2020-02-25 07:08:32 DEBUG (MainThread) [custom_components.bwalarm.alarm_control_panel] [_async_state_changed_listener] old_state: “disarmed”, new_state: “pending”
2020-02-25 07:08:32 DEBUG (MainThread) [custom_components.bwalarm.alarm_control_panel] [_async_state_changed_listener] mqtt.publish(topic=paradoxdCTL/in, state=pending, qos=0, retain=True)
2020-02-25 07:09:03 DEBUG (SyncWorker_2) [custom_components.bwalarm.alarm_control_panel] [process_event]
2020-02-25 07:09:03 DEBUG (SyncWorker_2) [custom_components.bwalarm.alarm_control_panel] [process_event] state changes from pending to armed_away
2020-02-25 07:09:03 DEBUG (SyncWorker_2) [custom_components.bwalarm.alarm_control_panel] [setsignals] armed_away
2020-02-25 07:09:03 DEBUG (SyncWorker_2) [custom_components.bwalarm.alarm_control_panel] [process_event] Turning off warning
2020-02-25 07:09:03 DEBUG (SyncWorker_2) [custom_components.bwalarm.alarm_control_panel] [save_alarm_state] (armed_away) begin
2020-02-25 07:09:03 DEBUG (SyncWorker_2) [custom_components.bwalarm.alarm_control_panel] [_clean_states_info] remove check_before_arm from states
2020-02-25 07:09:03 DEBUG (SyncWorker_2) [custom_components.bwalarm.alarm_control_panel] [save_persistence] File “/config/resources/bwalarm/bwalarm.json” saved successfully
2020-02-25 07:09:03 DEBUG (SyncWorker_2) [custom_components.bwalarm.alarm_control_panel] [save_alarm_state] (armed_away) end
2020-02-25 07:09:03 DEBUG (MainThread) [custom_components.bwalarm.alarm_control_panel] [code_format] self._code: REDACTED, self._state: armed_away, code_arm_required: False, returning number
2020-02-25 07:09:03 DEBUG (MainThread) [custom_components.bwalarm.alarm_control_panel] [device_state_attributes]
2020-02-25 07:09:03 DEBUG (MainThread) [custom_components.bwalarm.alarm_control_panel] [_async_state_changed_listener] old_state: “pending”, new_state: “armed_away”
2020-02-25 07:09:03 DEBUG (MainThread) [custom_components.bwalarm.alarm_control_panel] [_async_state_changed_listener] mqtt.publish(topic=paradoxdCTL/in, state=armed_away, qos=0, retain=True)

It seems to be part of the normal process, but this shouldn’t happen otherwise the warning automation will not trigger when someone enters the house

Not quite.
Would you be so kind and post your bwalarm.yaml here?
At least a string that has warning key.

Sure

platform: bwalarm
name: House
code: 'REDACTED'
panic_code: 'REDACTED'
alarm: automation.alarm_triggered
warning: automation.alarm_warning
panel:
  cameras: []
  panel_title: ''
  camera_update_interval: ''
  hide_sidebar: 'True'
  enable_sensors_panel: true
states:
  armed_away:
    immediate:
    - binary_sensor.master_bedroom_multisensor_sensor
    - binary_sensor.lounge_multisensor_sensor
    - binary_sensor.motion_sensor_158d0001ad43db
    - binary_sensor.gym_multisensor_sensor
    - binary_sensor.ensuite_multisensor_motion
    delayed:
    - binary_sensor.passage_multi_sensor_sensor
    - binary_sensor.kitchen_multi_sensor_sensor
    override:
    - binary_sensor.passage_multi_sensor_sensor
    pending_time: 60
    warning_time: 60
    trigger_time: 600
  armed_home:
    immediate:
    - binary_sensor.lounge_multisensor_sensor
    - binary_sensor.gym_multisensor_sensor
    delayed:
    - binary_sensor.kitchen_multi_sensor_sensor
#    - binary_sensor.garage_multisensor_sensor
    override: []
    pending_time: 60
    warning_time: 60
    trigger_time: 600
  armed_perimeter:
    immediate:
    - binary_sensor.lounge_multisensor_sensor
    delayed: []
    override: []
    pending_time: 60
    warning_time: 60
    trigger_time: 600

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

I hope it will.

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

On a side note… sort of… ‘initial_state:’ must be true or false now… on or off no longer works from what I’ve read…

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_off later.
And guess what happens when you call automation.turn_off? :wink:

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 :wink:

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 :wink:

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.

Glad that it seems to be resolved.

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…

I think so.

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.