Automation Help Please - Motion, Brightness with Condition

Hi All,

I have been struggling to get the following automation to trigger properly and am at a loss. It is a super simple automation. When motion is detected at the front door turn on the light and set the brightness to 100. If the outdoor light is already on and above 100 brightness then don’t change it.

I am trying to check if the brightness is above 100 with a condition template. Brightness shows up as a state in Dev Tools States. I have run the automation with the Brightness of the light at 255 and 75 and it always switches it back to 100.

I know I have made a super simple error, but can’t see it.

- id: Ring_Motion
  alias: Ring Motion
  trigger:
  - entity_id: binary_sensor.front_door_motion
    platform: state
    to: 'on'
  condition:
    - condition: template
      value_template: "{{ state_attr('light.zmtl_outside', 'brightness') | int < 100 }}"
  action:
  - service: light.turn_on
    data:
      entity_id: light.zmtl_outside
      brightness: 100

How “did you run” it? If it’s with the “Run actions” button in the automation that will do just that, run the actions without checking trigger or condition.

And although possible with a template, why not simply use the numeric state?

- id: Ring_Motion
  alias: Ring Motion
  trigger:
  - entity_id: binary_sensor.front_door_motion
    platform: state
    to: 'on'
  condition:
    - condition: numeric_state
      entity_id: light.zmtl_outside
      attribute: brightness
      below: '100'
  action:
  - service: light.turn_on
    data:
      entity_id: light.zmtl_outside
      brightness: 100

OMG, I had completely forgotten that Run Actions ignored conditions and I think your simplifications is much better. Will try that out.

For future reference, there’s no functional difference between your Template Condition and the suggested Numeric State Condition.

If you’re just looking for a reduction of code, you can use the shorthand notation for Template Conditions:

- id: Ring_Motion
  alias: Ring Motion
  trigger:
  - entity_id: binary_sensor.front_door_motion
    platform: state
    to: 'on'
  condition: "{{ state_attr('light.zmtl_outside', 'brightness') | int < 100 }}"
  action:
  - service: light.turn_on
    data:
      entity_id: light.zmtl_outside
      brightness: 100


Please consider marking septillion’s post with the Solution tag. The cause of the problem you experienced was correctly identified to be due to manually executing the automation.

Thanks Taras,

I am always looking to reduce code and simplify my automations. Over a number of years they have grown quite wieldy.

Reducing and simplification are not the same :smiley: I prefer the numeric state as it’s the defined building block for the task and the UI supports it. Not saying the template version is wrong, but I tend to only use templates if I really need to. In 90% of the cases the use of a template just indicates where work needs to be done on the standard automation engine.

Timo,

I can see your point, but as I have split my automations out into separate files over time I have had no joy with the UI. I think only automations in automations.yaml can be played with in the UI.

Stuart

I would ask where you got that statistic but I think I already know from where.

Again, not saying that there is anything wrong with templates. If you like them, for all means, use them! I don’t see any problem in that.

And yes, that 90% is a personal estimate. But that 10% just indicates things that the standard engine indeed can not do and templates can. Which makes me believe there is an opportunity for improvement on the standard engine. Because like it or not, I believe that is the way forward with HA and seeing all the work that has been done on it last two years, I think that’s the way the core developers see that as well. Again, not saying it will ever replace templates/Jinja. They can happily co-exist.

What exactly is this “standard engine” you are referring to?

The YAML code for all automations is converted into JSON and fed to the automation processor. Any templates within YAML are first evaluated by the Jinja2 processor. Either way, it all ends up being consumed as JSON.

I’m surprised you’ve come to that conclusion. I can’t claim to know what the core developers think but based on what has been released in the past two years, there have been more additions and improvements to templating than the introduction of any new types of triggers or conditions.

The notable exception are Device Triggers and Device Conditions. They were invented along with the concept of Devices and are designed to be used with the Visual (Automation) Editor … mostly because they are verbose (compared to a service call) and use a long-winded device_id whose value cannot be easily discovered by the end-user. However, everything they do is equivalent to existing triggers and conditions so not really “new” as much as “duplicate”.

The YAML based flow.

Then I must have missed a ton of template features… And no, I don’t consider trigger based sensors etc to be a template addition.

But really, I mainly I don’t get why you get so upset if somebody likes YAML automations over templates… :confused: Templates are not better than YAML. YAML isn’t better than templates. Or even better than NodeRed. And even though I don’t even like YAML, I personally do prefer the more structured way of YAML as I do believe it’s in it’s basics more clear for beginners with no code experience.

And yes, all things that are added to YAML that in the past could be done in templates you can consider a duplicate. Like I said, there are things you can only do with a template at the moment and that indicateds weak spots in the YAML. But in my opinion that just makes it a new feature if it’s added to YAML.

So please, don’t get so offended if somebody doesn’t share the same preference. :confused:

Foot note: in this text YAML is a synonym for YAML style automations/scrips/LoveLace-config.

I’m far from offended just disappointed. You’re not demonstrating a good grasp of how YAML and Jinja2 are employed when you make up nebulous terms like “standard engine” and “YAML based flow”. That unfamiliarity is what leads you to make preposterous claims like the “90%” estimate and that’s disappointing because it’s a disservice to other users.

Why do I have a bad grasp? :confused: Because it doesn’t matter that YAML and Jinja both boil down to JSON and use the same backend. Because that’s just not visible to a normal user. From a normal user perspective it’s about the interface where you have full YAML (possibly via the UI) or mixed with Jinja templates (or NodeRed or other third party scripts). And like I said, it can happily coexist. But if I have to use a template for a simple task because it can’t be done with YAML alone it does feel like an opportunity for improvement. And a couple got fixed last year (like being able to use an entity with above/below). But that’s no disservice to anybody.

You appear to have contradicted yourself because earlier you said neither is better than the other.

Anyway, if you have encountered situations where you use a Template Trigger or Template Condition but think it should also be possible to do with a State Trigger/Condition, or some other Trigger/Condition (Numeric State, Time, Sun, etc), just post a Feature Request explaining the proposed enhancement.

No I don’t. Something having opportunities for improvement does not automatically make it worse than the other even though the inspiration comes from the other :slight_smile:

Like I said, post your ideas for improvements in Feature Requests. You apparently must have a few in mind given that you believe 90% of templates represent “work that needs to be done on the standard automation engine”.

Yeah, I should. But that’s normally in the middle of making an automation etc. So I think I will just save them for a single request sometime or a what the heck month. But thanks for the reminder :slight_smile:

But like I said, a lot has been done last year. The chooser and and being able to use an entity as above/below are two great examples.