#Need help optimising my automation

1 messages · Page 1 of 1 (latest)

tender moss
#

So I wrote a .yaml automation to synchronize a lamp to another lamp last night. There is no external data to just use instead because said source lamp is gets its data from some closed source code that is running on a seperate device. The source light is also a lot smaller than the target lamp that's why I divide the brightness by 4.

triggers:
 - entity_id: light.source
   for:
     milliseconds: 100
   trigger: state
conditions:
 - condition: template
   value_template: >
     {% set new_brightness =
     (state_attr('light.source', 'brightness') | int /
     4.0) | round(0) | int %} {% set new_hs_color =
     state_attr('light.source', 'hs_color') %} {{
     new_brightness != state_attr('light.target_a', 'brightness') | int or
     new_hs_color != state_attr('light.target_a', 'hs_color') or
     new_brightness != state_attr('light.target_b', 'brightness') | int or
     new_hs_color != state_attr('light.target_b', 'hs_color') }} 
actions:
 - target:
     entity_id:
       - light.target_a
       - light.target_b
   data:
     brightness: >-
       {{ (state_attr('light.source', 'brightness') |
       int / 4.0) | round(0) | int }}
     hs_color: "{{ state_attr('light.source', 'hs_color') }}"
   action: light.turn_on
mode: restart


proud scaffold
#

I don't see anything problematic there though, unless this runs on an actual toaster

kind jungle
#

is light.source custom?

tender moss
#

Raspberry Pi 3B+ in a Docker container next to a Pihole install on the Debian OS.

It currently has 20 seconds delay when running with its trigger but is much faster (less delay) when manually trigger but that's probably not feasible to.

tender moss
# kind jungle is light.source custom?

It's not the real name of the actual lamp that is used as the source but I changed the names to make it more readable. But it is a lamp controlled by external proprietary software.

kind jungle
#

3b+ is gunna start to struggle a bit but should be okay for basic stuff.
the delay is most likely the trigger and not the action

tender moss
#

Yeah I figured. Was thinking about just having it trigger every second or so but I don't know if that would be better.

#

I can hop onto my computer and look for the more complex code that I used earlier before cutting it down to just this.

kind jungle
#

what type of lamp is it? you said in other channell you piped it though multiple things, is it a custom sensor or something?

proud scaffold
tender moss
#

This is the code that added the in between steps (I have to post it in multiple parts due to character limit. I was just using one lamp for testing.

#
  - entity_id: light.source
    for:
      milliseconds: 100
    trigger: state
conditions: []
actions:
  - variables:
      ziel_brightness: >-
        {{ (state_attr('light.source', 'brightness') |
        int / 4.0) | round(0) | int }}
      ziel_hs_color: "{{ state_attr('light.source', 'hs_color') }}"
      start_brightness: "{{ state_attr('light.target', 'brightness') | default(0) | int }}"
      start_hs_color: "{{ state_attr('light.target', 'hs_color') | default([0,0]) }}"
      max_steps: 6
  - repeat:
      sequence:
        - target:
            entity_id: light.target
          data_template:
            brightness: >
              {% set current_brightness = state_attr('light.target',
              'brightness') | int %} {% set diff_brightness = (ziel_brightness -
              current_brightness) | abs %} {% set step_brightness =
              (diff_brightness / max_steps) | round(0) | int %} {% if
              diff_brightness > 0 %}
                {% if current_brightness < ziel_brightness %}
                  {{ [current_brightness + step_brightness, ziel_brightness] | min }}
                {% else %}
                  {{ [current_brightness - step_brightness, ziel_brightness] | max }}
                {% endif %}
              {% else %}
                {{ current_brightness }}
              {% endif %}
#
            hs_color: >
              {% set current_hs_color = state_attr('light.target',
              'hs_color') | default([0,0]) %} {% set ziel_h = ziel_hs_color[0] |
              float %} {% set ziel_s = ziel_hs_color[1] | float %} {% set
              current_h = current_hs_color[0] | float %} {% set current_s =
              current_hs_color[1] | float %} {% set diff_h = (ziel_h -
              current_h) | abs %} {% if diff_h > 180 %}
                {% set diff_h = 360 - diff_h %}
              {% endif %} {% set step_h = (diff_h / max_steps) %} {% set diff_s
              = (ziel_s - current_s) | abs %} {% set step_s = (diff_s /
              max_steps) %}

              {% if current_h < ziel_h and diff_h < 180 or current_h > ziel_h
              and diff_h > 180 %}
                {% set new_h = current_h + step_h %}
              {% else %}
                {% set new_h = current_h - step_h %}
              {% endif %} {% if current_s < ziel_s %}
                {% set new_s = current_s + step_s %}
              {% else %}
                {% set new_s = current_s - step_s %}
              {% endif %} {{ [new_h | round(2), new_s | round(2)] }}
          action: light.turn_on
        - delay:
            milliseconds: 6
      until:
        - condition: template
          value_template: >
            {{ state_attr('light.target', 'brightness') | int ==
            ziel_brightness and state_attr('light.target', 'hs_color') |
            default([0,0]) | list == ziel_hs_color | list }}
mode: restart```
#

ziel stands for target

proud scaffold
#

That it runs quickly when manually triggered tells me this is 100% a trigger problem

#

And that means that HA isn't detecting the state change instantly - a common problem if the entity has to be polled

tender moss
tender moss
proud scaffold
#

That's "fixed" in the integration with HA

#

There's nothing you can do in the automation

kind jungle
#

What lamp and software is it your connecting to?

tender moss
#

Can't I just replace the condition to run it every second instead of waiting for HA to check for a state change? Because triggering the automation is faster and also doesn't change the polling rate.

tender moss
# kind jungle What lamp and software is it your connecting to?

I knind of don't want to tell until I have a somewhat working version running to host on Github as a blueprint. Because I doubt that I can quickly learn how to host my own server that can be added an integration conecting to this hot mess. And I'm glad that I finally have a weird little project that I can work on that no one else is working on publicly as far as I can tell

proud scaffold
#

HA does not know the state changed

#

Running the automation every second won't help

#

State change triggers are instant - the moment HA knows then they fire, there's zero meaningful delay

#

At best your approach won't help, at worst it'll add another delay

tender moss
#

Yeah but the automation is just reading the current state from the device that is an entity in HA and manually triggering it is much faster which means that the delay is happening between the state changing and the automation being triggered

proud scaffold
#

No

#

That's not how HA works

tender moss
#

Ok why is it suddenly faster to trigger the automation myself?

proud scaffold
#

The automation reads the current state from HA's state engine - it at no point communicates with the devices

tender moss
#

I knoooow

proud scaffold
#

Really?

#

Yeah but the automation is just reading the current state from the device
Says otherwise

#

Check the trace, see what's really going on

tender moss
#

But still if I trigger the automation it instantly changes to the most recent state that is know by HA at that point before having a huge delay again. And not doing it gives me no sudden boosts like that. So why is it suddenly less delayed when triggered that way and what can I do to constantly have the shorter delay that I experience when triggering the automation manually in HA?

proud scaffold
#

Check the trace

shy rootBOT
#

To test an automation there's three stages you can follow. Testing the action, the condition and action, and the whole automation:

  1. Use Configuration -> Automations to find the automation and then select Run in the three dots menu. If this fails your problem is in the action: section, and details should be found in your log file
  2. Use Developer tools -> Services and call automation.trigger on the automation with skip_condition: false. If the first passes but this fails then the problem is in your condition: block
  3. Use Developer tools -> States to find the trigger entity, click the name, then change the state (at the top) to something that'll trigger the automation before pushing Set State. If this fails then the problem is with your trigger: section, or the automation is turned off (you can check that in Automations, automations that are turned off will show Disabled)

You can also see this section in the docs about testing and automation traces.

kind jungle
#

another possible is that that the trigger is being spammed and as the automation is in restart mode it doesnt actually complete until the entitiy settles for a bit?

proud scaffold
#

Could be, the trace would show that though

tender moss
#

I'm running the automation for a bit and then look at the trace

kind jungle
#

there is a sperate trace for each time the automation runs

proud scaffold
#

Let it run itself, that's what you need

tender moss
#

Started it, waited a second, changed the state of the source light and ended it after it had done what it should. Running it longer and changing the source lamp would just repeat the same action in the same way that's why I stopped it after this point. I guess that made sense right?

kind jungle
#

the automation is running fine. as descceibed earlier is that its probably something to do with how the sensor which triggers it updates. and you are unwilling or cant tell/show us what that is so we are at a dead end

tender moss
kind jungle
#

maybe you could set up a webhook and then when there is an update your script could directly trigger the automation via a web call?

kind jungle
#

why? just post here in case others have ideas

#

i am heading off in a moment anyway

tender moss
#

Because I don't want anyone else seeing it and doing it which would lead to me being bored again and someone else doing all the cool stuff

kind jungle
#

you know your in an opensource project discord right? with people that like things being open?

tender moss
#

I just want the initial version to be somewhat working and then have it open source on GitHub

#

I don't think it would be fun to just push out a broken mess and make it public and have people complain I guess

kind jungle
#

people will complain if it works. dont let that stop you thowing stuff up and seeing what people think and giving suggestions

tender moss
#

Guess I'll start to write up some documentation and getting it out in the current state

kind jungle
#

yeah, just throw it up and make it clear its an alpha with various issues but its coming along and feedback would be nice.
dont be scared of failing, you might get a couple of assholes be assholes but thats life.

tender moss
#

What would be a good choice for a license for the repository?