Automation syntax issue, maybe?

Configuration
1

Now that I have my alarm data showing up in HASS, I’m trying to get something set up so that when the alarm is armed ‘Away’, it triggers a scene to turn off specified lights and devices that don’t need to be on when no one’s home (I’m sure everyone has left something on that didn’t need to be on when they went away or to work at one point or another).

Through some trial and error and using the config checker, I arrived at this automation that the config checker said was valid:

#- alias: 'Alarm Arm Away Turn off Lights'
#  trigger:
#   condition: state
#     entity_id: alarm_control_panel.home_alarm
#     from: 'pending'
#     to: 'Arm Away'
#  action:
#    service: scene.turn_on
#    entity_id: scene.armed_away_lights

This should trigger this scene (found in my scenes.yaml):

  - name: armed_away_lights
    entities:
        light.leviton_dz6hd1bz_decora_600w_smart_dimmer_level_55_0:
             state: off

This one light I put in for testing - most likely, I’d set up a group of devices I wanted to be turned off upon arming it away once I actually get it working.

But when I restarted HA, it crashed all over itself and the following was in the home-assistant.log file:

2017-10-10 19:32:18 ERROR (Thread-2) [homeassistant.util.yaml] mapping values are not allowed here
  in "/home/homeassistant/.homeassistant/automation_old.yaml", line 237, column 15
2017-10-10 19:32:18 ERROR (MainThread) [homeassistant.bootstrap] Error loading /home/homeassistant/.homeassistant/configuration.yaml: mapping values are not allowed here
  in "/home/homeassistant/.homeassistant/automation_old.yaml", line 237, column 15

Line 237 is ‘entity_id: alarm_control_panel.home_alarm’

Based on my other automatons, it ‘looks’ right, but there’s obviously something about it that’s not playing nice - perhaps the condition ‘state’ doesn’t like the entity ‘alarm_control_panel.home_alarm’?

2

Shouldn’t it be platform: state ?

3

EDIT: @keithh666 is right. change this “condition: state” to this “platform: state”

Also, you may have an indentation issue with the 3 proceeding lines, but maybe not. And the trigger may never happen if the state isn’t exactly 'Arm Away'. that might have to be 'armed_away'.

One thing to note about the check config is it will only tell you if your configuration follows proper YAML formatting such as spacing, indentation, punctuation, declarations, etc. It will not tell you if your config will result in good components, automations, or frontend actions.

4

Thanks for the input - the ‘platform: state’ was part of my problem. Indentation wasn’t helping, and using ‘entity_id: alarm_control_panel.home_alarm’ apparently wasn’t working out either. After some more trial and error with ‘platform: state’, I got the indentation right (so HA would actually start -my errors were causing it to die before it got started), and then tried using the keypad sensor - what ended up working was the following:

- alias: 'Alarm Arm Away Turn off Lights'
  trigger:
    platform: state
    entity_id: 'sensor.home_alarm_keypad'
    from: 'Exit Delay In Progress'
    to: 'Arm Away'
  action:
    service: scene.turn_on
    entity_id: scene.armed_away_lights

I imagine I could probably do it with a group, rather than a scene (cut out a step as I’d really need a group anyway), and have something like:

service: homeassistant.turn_off
entity_id: armed_away_lights (Or it might be group.armed_away_lights)

And have a (hidden) group called ‘armed_away_lights’ that contains any lights and devices that want to be sent an ‘off’ command when the alarm arms away.

5

I guess I might as well continue on in this thread since it’s related, and in the end, most of my issues probably are from similar issues/misunderstandings. With keithh666 and squirtbrnr’s input, I got the ‘turn lights off when armed away’ working like a champ.

Now I want to set up a rule that when the front door goes from closed to open, with the conditions that the sun is below the horizon and the alarm is ‘Arm Away’, the living room lights turn on. I could NOT get it to work at all without crashing HA, so on a whim, I tried using the GUI automation editor - seemed like it was going to work well, until I got to ‘action’. Coming from:

  action:
    service: scene.turn_on
    entity_id: scene.armed_away_lights

I couldn’t figure out what/how I should put there to make it do something - but I used what was saved to the new automations file, removed it from there and put it in the old automation file with

  action:
    service: homeassistant.turn_on
    entity_id: light.leviton_dz6hd1bz_decora_600w_smart_dimmer_level_57_0

at the bottom of the alias, and HA started, the automation was there and when manually triggered, it turns the living room lights on. But when the alarm is ‘Arm Away’ and the front door opens, nothing.

I thought maybe the problem was a timing thing because the alarm goes from ‘Arm Away’ to ‘Entry Delay in Progress’, so I changed the config around and came up with this:

- alias: Turn Living Room Lights on when we come home
  condition:
  - condition: numeric_state
    entity_id: sun.sun
    below: '3.5'
  trigger:
  - entity_id: binary_sensor.front_door
    platform: state
    from: closed
    to: open
  - entity_id: sensor.home_alarm_keypad
    platform: state
    from: Arm Away
    to: Entry Delay in Progress
  action:
    service: homeassistant.turn_on
    entity_id: light.leviton_dz6hd1bz_decora_600w_smart_dimmer_level_57_0

Still nothing - then on a whim, I commented out

  condition:
  - condition: numeric_state
    entity_id: sun.sun
    below: '3.5'

and voila - it worked. If the alarm is ‘Arm Away’ and transitions to ‘Entry Delay in Progress’ and the front door goes from ‘closed’ to ‘open’, the living room lights turn on, but not if the the door is opened while the alarm is off or if it’s armed stay. The sun is below 3.5 (It’s -30 something right now, I think), so it should work, but apparently something about it isn’t liked. And oddly, after just commenting out the condition lines of the automation, HA started complaining about an error in the automations. But they still work. After a reboot of the RPi, the automation error went away, so there must be something buggy about just reloading automations a whole bunch of times. I guess with enough reloads, it goes cross-eyed.

Any ideas what I’m missing here? After almost 2 hours of trying to make it work, I’m out of ideas. Most everything about it except some ordering and the ‘action:’ lines was copied from what was created by the GUI automation editor.

6

I think it should look something like this …

 - alias: "Send notification upon Freezer Door Open"
   trigger:
     - platform: state
       entity_id: switch.rfl_freezer_open
       to: 'on'
       for:
         minutes: 10     
   condition:
     condition: state
     entity_id: input_boolean.keithhome
     state: 'off'
   action:
     - service: notify.mypushbullet
       data:
         title: "Freezer Door Open"
         message: 'Freezer Door Open'

So it looks to me like your indentation is off and condition should come after trigger.

For the sun condition try …

   condition:
     - condition: state
       entity_id: sun.sun
       state: 'below_horizon'

or state: ‘down’

7

Indentation looks fine and although your code layout doesn’t follow what’s in the examples and component page, it is correct. The frontend automation builder creates the automations a little funny, but functionally they’re the same. For readability and troubleshooting though, it’s best practice to list it in this order: trigger, condition, action.

for the sun condition like keithh666 suggested, use the above/below horizon state. Or if you specifically want a before/after sunrise/sunset or an above/below horizon value, then you can do either of these:

condition: sun
event: sunset
offset: "-00:45:00"

or

condition: numeric_state
entity_id: sun.sun
value_template: '{{ state.attributes.elevation }}'
below: 3.5

I think you were missing the value_template part of your condition initially.

Check out the examples for using the sun component and as a condition in automations.

8

Thanks guys - I’m finally getting somewhere! To be honest, I’m surprised I’ve gotten as far as I have with the relative little I’ve been bothering people here - when it comes to programming (and this boils down to a form of programming), I’m a total moron.

Anyway, I think I’ve gotten pretty much everything working almost as I want it - When the alarm gets armed away, it turns a group off, when it goes from ‘Entry Delay in Progress’ it turns my garage door opener outlet back on, if the sun is below the horizon and the front door is opened and the alarm goes from ‘Arm Away’, it turns the living room lights on (I tested with sun.sun ‘state: above_horizon’, and it turned the lights on, so I changed it to ‘below_horizon’. The only glitch is the Living room lights and garage door opener outlet will only work if an entry door is breached and it goes to ‘Entry Delay in Progress’ before going to ‘disarmed’ - if I use a remote FOB to disarm it, it goes from ‘Arm Away’ to ‘Ready’, so obviously, it doesn’t meet the required conditions and doesn’t trigger the action.

Is it possible to set ‘or’ conditions on a ‘platform: state’ trigger?

- alias: Turn Living Room Lights on when we come home
  trigger:
  - entity_id: binary_sensor.front_door
    platform: state
    from: closed
    to: open
  - entity_id: sensor.home_alarm_keypad
    platform: state
    from: Arm Away
    to: Entry Delay in Progress
    to: Ready
  condition:
  - condition: state
    entity_id: sun.sun
    state: below_horizon
  action:
    service: homeassistant.turn_on
    entity_id: light.leviton_dz6hd1bz_decora_600w_smart_dimmer_level_57_0

I’m sure that’s wrong (Only thing added is ‘to: Ready’ - the rest is in place and works), but something like that?

Edit: After thinking about it, a simpler way was to make separate automations specifically for disarming the alarm with the FOB.

It definitely seems like automation reload is buggy. I was doing just automation reload and I tested the lights on with FOB disarm earlier using ‘state: above_horizon’, when that worked, I changed it to ‘state: below_horizon’ and in doing some other tinkering, reloaded automation several times, then I noticed that when I disarmed it with the FOB, it was still turning the lights on even though the sun is over the horizon and thus it should not have been triggered. After a reboot of the RPi, it’s now working right (not tuning the LR lights on when I disable it with the FOB)

9

Yes. see here for using OR conditions.