Automation UI seems to always use strings for triggers and conditions

Configuration
1

Hi all,

New to Home Assistant, but not new to programming. I ran into a problem when creating automations using the UI.
I’m created an automation to turn off the lights when the sun elevation is above a threshold using the UI. In that automation, I need a condition to check whether the sun is rising (otherwise the lights also turn off in the evening, because the evening elevation for turning on the lights is higher than the morning threshold for turning them off).
When I create this automation using the UI, it fails to trigger. The following YAML is generated:

- id: '1603538892957'
  alias: Turn off the lights when it gets light
  description: ''
  trigger:
  - platform: numeric_state
    entity_id: sun.sun
    attribute: elevation
    above: '4'
  condition:
  - condition: state
    entity_id: sun.sun
    state: 'true'
    attribute: rising
  action:
  - domain: light
    entity_id: light.kastje_hal
    device_id: foo
    type: turn_off
  mode: single

This never triggers, because the “rising” attribute is a boolean, not a string. The numeric value is also put in the automation as a string, but that does work (probably due to an implicit type conversion).

I can fix this by manually editing the generated automation and removing the single quotes, but that’s obviously not a good solution (it also makes the automation “dirty”, so opening it in the Automation UI always shows a “Save” icon).

Is there any way to “cleanly” fix this? Or should I raise an issue about this?

2

Since 0.117 you can edit the YAMl from the UI directly, ao it’s not “dirty” anymore.

Is this condition really needed? The automation will only trigger when the elevation changes from below 4 to above 4, so in the evening it won’t trigger at all.

However, I think it would still be good to open an issue to get it fixed in the UI editor.

1 Like
3

Actually, on loading it in the UI automation YAML editor, the single quotes are put back in :frowning:

Without this condition, it re-triggers when HA restarts and the sun is setting but its elevation is above 4, resulting in my lights being turned off in the evening (the elevation for turning on the lights in the evening is set to “below 8”). With this condition it still triggers on a restart of HA in the morning, but that’s not as annoying (since the lights are usually already off then…).

That probably happens because the value of the elevation is 0 after a restart, so it changes from below 4 to above 4.

4

You can replace this State Condition:

  condition:
  - condition: state
    entity_id: sun.sun
    state: 'true'
    attribute: rising

with a Template Condition:

  condition:
  - condition: template
    value_template: "{{ state_attr('sun.sun', 'rising') }}"

which can also be written in the new abbreviated format (but I don’t know if the Automation Editor supports it):

  condition:
  - "{{ state_attr('sun.sun', 'rising') }}"
2 Likes
5

I didn’t take restarts into account (I only restart production when I update HA).

The state is probably changing from ‘unavailable’ to e.g. 4. You could have another condition like time is between 6 AM and 11AM or have a condition that checks if the previous state was not ‘unavailable’. Taras approach is way better, somehow didn’t think of this.

6

Thanks, for me as a programmer that would do fine, but it kind of defies the purpose of using the UI for me… There’s no drop down boxes to choose from, which you do get for the State condition (for everything except the value).

7

Problem: Prevent automation from being executed on startup.
Common solution: Add a condition that checks duration of Uptime Sensor.

The Uptime Sensor is reset on startup. If the automation is triggered on startup, the Uptime Sensor’s value will be very low, meaning the system was just started. The condition can check for a low value and prevent executing its action.

However, in this particular case, it’s simpler to use the sun’s attribute.

1 Like
8

It’s well known that the Automation Editor can’t do everything that is actually possible. It’s good for many but not all applications.

For that reason (and others like my automations are stored in multiple files), I use the Visual Studio Code editor to manage my automations along with this:

2 Likes
9

Yeah, if you’re an experienced programmer you will likely soon find that the UI editor is going to limit you.

It’s getting better (or so I hear…I never use it so I can’t confirm or deny that assertion :wink:) but it’s still not “there” yet.

And as @123 said I like to keep my config split into more manageable pieces and the UI editors put all of their associated code into single ‘monolithic’ files. And, along with it stripping out all comments from the code there are several good reasons to not use the UI editors.