Color Loop Blueprint with Configurable Colors and Transition Time

Blueprints Exchange
,
21

I believe the following should work (I’m still fairly new to HA so there may be a better solution)

When turned on:
service - scene.create - Give it a name, choose your entities -
Activate your color changes

When turned off:
deactivate color changes
service - scene.apply - {your scene name}

22

I am also running into the problem where the color selector isn’t working, and I am also getting the error

Error: UndefinedError: list object has no element 1

In the variable declaration step. My guess is recent HA changes may have broken the script, but I am not certain.

23

I’m using this blueprint with a lightgroup. I have the case that sometimes I would like to turn off a single light in the group. Unfortunately, if I use the script directly on the lightgroup this light again gets turned on on the next iteration. Another option would be to have seperate colorloop scripts for the individual lights, but when they’re no in sync. Does anyone have an idea how this could be solved?

24

Also having the same issues , i think the recent changes are the thing why

25

This is one of the best posts I have ever read. The way you explain the path of the light with the diagram is genius and saved me a ton of time in a script I’m building to simulate a sunrise across the lights in my home.

EDIT I should note, my bulbs don’t support color transition, so I have done the calculations to adjust color slowly if you are interested in those.

26

I love this!

May I ask is there anyway to add randomness to the time? I’m thinking of trying to adapt this script to be able to make ocean effects and flame effects, but a constant transition time isn’t as realistic as variable ones.

I’ve tried going into Yaml mode and adding “{{ range(1, 31)|random}}” but that didn’t work.

Any suggestions?

Happy Holidays!

27

To add some context after half a year, soon after the last post I migrated the db to remote postgres db running on nas, disabled the zipped backups as the nas takes daily zfs snapshots and after half a year the uncompressed database size is

SELECT pg_size_pretty ( pg_database_size ('ha1db'))

pg_size_pretty
16 GB

So thats 14GB increase in 6 months say 2GB uncompressed a month. This might seem gigantic, but there are points to take into consideration:

  • I do not think any of it now comes from this blueprint as I only switch 3 colors with long delay
  • I have a :poop:ton of sensors and 2 linked remote HA instances
  • Data is set to be kept for 365 days
  • There’s 24TB free space on the nas
28

any solution for this?
i’m running into the same issue and have no idea how to debug

29

Hey everyone, I just added a new version 2.0 of the Color Loop blueprint.

Here is the gist of the changes:

  1. Changed it from being a Script Blueprint to an Automation Blueprint:
    • Unfortunately this means its a breaking change so all existing Scripts using the blueprint will need to be re-added as Automations (see below)
  2. I have added a new input for a Toggle element to control the color loop:
    • This will allow a separate toggle entity to turn the color transitions on/off.
    • You can use the same toggle for multiple separate color loops to turn all of the loops on/off.
    • This vastly helps when using light groups and you want to turn off the color loop.
    • If you leave the toggle on and turn the lights off, when you turn the lights back on they will start looping again.
    • This toggle is somewhat optional, where if you want to always have the color looping whenever the light is on, you can add the light itself as its own toggle.
  3. Fixed issues with light groups:
    • With the new toggle it is easy and (hopefully) bug free to turn off the color looping when you are using light groups.
    • While the color is looping, you can now turn off individual lights and they won’t turn back on.
    • Turning off some lights will keep the color loop running.
    • Turning off all lights will stop the color loop.
    • When all lights are off, turning any lights in the group back on will restart the color loop (provided the toggle is on).
  4. Fixed issue with lights sometimes turning themselves back on:
    • There is now logic to not only help prevent this from occurring, it will also ensure that the light is left set to the color where it was stopped on.
  5. Updated the blueprint docs:

How to update from version 0.1 to 2.0:

  1. Download / install the new blueprint from above.
  2. Have two windows/tabs open.
  3. Window 1:
    1. Go to Settings > Blueprints > Automations & Scenes > Blueprints
    2. Click CREATE AUTOMATION
    3. Click the ⋮ button in the top-right and select Edit in YAML
  4. Window 2:
    1. Edit the old script-based color loop you want to transfer over
    2. Click the ⋮ button in the top-right and select Edit in YAML
  5. Copy over the relevant YAML from the old script to the new automation:
  6. Window 1:
    1. Click the ⋮ button in the top-right and select Edit in visual editor
    2. Add the required toggle (or set it to the same light)
    3. Save!
  7. Window 1:
    1. Delete the old script.
  8. Repeat for any other color loop scripts.
  9. Delete the old blueprint.
  10. Consider adding the new toggle(s) to the overview for an easy way to turn on/off color loops.
1 Like
30

I am also running into the problem where the color selector isn’t working, and I am also getting the error

Error: UndefinedError: list object has no element 1

In the variable declaration step. My guess is recent HA changes may have broken the script, but I am not certain.

I have yet to run into the issue with no color selector yet, perhaps try another browser as the color selector is browser dependent (ie: the color selector is much different in chrome on windows than mobile chrome).

I don’t regularly update Home Assistant so it may have been an issue with some version in between?

If you are manually editing the YML to set the values it could the error above be an indentation error?

Maybe try copying the following YML into your automation/script and update as needed:

description: ""
alias: Color Loop
use_blueprint:
  path: mdolnik/color_loop.yaml
  input:
    light: light.my_light
    helper_toggle: input_boolean.color_loop_lights
    color_1:
      - 255
      - 0
      - 0
    color_2:
      - 4
      - 255
      - 0
    color_3:
      - 0
      - 42
      - 255
    max_color_distance: 20
    max_changes_per_second: 2
    transition:
      hours: 0
      minutes: 0
      seconds: 20

Note: helper_toggle is new for the version 2.0, but the same YML above should work in the old version if you remove that line.

31

I am not sure if I want to add randomness at this point officially, it would be a little tricky (UX-wise) to have input for both “Do you want it to be random” as well as “how random do you want it”

Also the randomness you are looking for probably involves a lot of quick color changes which I’m more or less wanting to avoid.

Regardless, you should be able to modify the downloaded blueprint to add the following transition_seconds override between the declarations of color_distance_abs and iterations_desired:

... (Version 0.1: line 397) (Version 2.0: line 615) ...
        # Get the hue color distance.
        # https://stackoverflow.com/questions/1878907#comment119528981_7869457
        color_distance: '{{ ((hue_next - hue_cur + 540) % 360) - 180 }}'
        color_distance_abs: '{{ color_distance|abs }}'

        ######## ADD THIS LINE HERE ############
        transition_seconds: "{{ range(1, 31)|random }}"
        ########################################

        # Determine the ideal amount of steps to make between colors.
        iterations_desired: >-
          {% if color_distance_abs < max_color_distance %}
...

Note: This is the YAML of the blueprint itself, not the color loop created by it. I don’t know if there’s any official way to edit this YAML from the UI, you would need to copy/modify the source blueprints/automation/mdolnik/color_loop.yaml file.

This change would be hard-coded to the random values you set and will override the Transition Time input.

I briefly tested this and it seems to work, let me know if this works or not for you.

Also if enough people want randomness, I’ll see if I can work it in officially.

32

Lol and here am I concerned with my db sitting at 107MB…

But my DB is still pretty small since I’ve have had all my color looped lights ignored from being logged to the DB via:

recorder:
  exclude:
    entities:
      # Exclude any logging of the chosen light.
      - light.my_light
      # Exclude any logging of this color loop script.
      - automation.my_light_color_loop
    event_types:
      # Do not record ANY service calls
      - call_service
  # Write to DB every 30 seconds
  commit_interval: 30

The original concern was mostly to do with the DB write frequency (commit_interval) rather than the DB size.

But for DB size, I reckon if you are running multiple lights that are updating once a second, your DB would start ballooning until it hits the purge_keep_days amount (default 10 days) then become stable from then on.

33

At this point, even with version 2.0 not really, but sort of?

The latest version will pause on the last color if you turn the toggle off. When the color loop is restarted it will take X amount of seconds to get to the first color.

So if you have 3 colors: Red, Blue, Green and a 10 second transition. If you turn the toggle off after 5 seconds it should end up pausing on purple/pink. Turn the toggle back on and it will go from purple/pink to Red over 10 seconds then continue the loop as normal.

I know that’s not quite the same, but Blueprints can be a bit “dumb” in that, unless you provide it with an outside entity to store information in, it will forget everything about itself when its completed it job.

So in order to have it remember how far along the loop it has gone I would have to either:

At this point I’m thinking of waiting on the latter, unless many people feel this is important.

Edit:
:man_facepalming: Just realized I read your question backwards… Lets say your light is currently Cyan and you start the RGB loop, you want it to turn back to Cyan when you turn the color loop off?

If so, that’s a little more doable as the value could be retained during the automation and restored afterwards, the tricky part is knowing when the loop is canceled as I’ve added quite a few exit points in the logic.

I’ll give this a bit of ponder and see if I can get something working… at some point… no promises

34

Try the new version 2.0 this issue should be resolved now.

You would add a separate toggle entity which turns the color looping on/off on the light groups then you can separately turn on/off the color loop effect or turn on/off individual lights in the group as the effect is running.

You can also have one toggle control different color loop automations so you can toggle the color loop effects on multiple lights at the same time with each light having their own color combos.

35

Thanks, I’m happy that my mad ramblings can help others out there.

I am curious what you mean by this…

The blueprint should already work pretty well for lights without color transitions (I have 3 of these myself) you would just need to bring down the Max Color Distance to a low value like 1 or 5.

Lights that do support color transitions should still set Max Color Distance to a higher value.

36

And so we came the full circle and it’s automation again :smiley: Thanks for the update!

edit: works great, since I am lazy, I just changed the old script to trigger this automation as I didn’t want to go thru wherever I been triggering the script and changing it to automation, I presume this should not cause any issues ?

edit2: nvm, realized that’s what the toggle is, so just went thru wherever it called script.turn_on/off and changed it to the helper input_boolean I created

Really like the version 2 of the blueprint, great work!

37

Hmm…I was using the color loop blueprint from @C.G.B.Spender without any issues and now I wanted to give this one a try because it was mentioned to be suggested to do so.
So what I did was:

  • Created a Toggle Helper
  • Created an automation with this blueprint which takes the Toggle Helper for enabling/disabling the color loop
  • Created an automation for my physical light switch button which on “button hold” enables the Toggle Helper and on “button release” disables the Toggle Helper

It basically works. When I press the physical light switch button, the color loop starts.
But: Compared to the color loop bluepwint from C.G.B. Spender, when releasing the physical light switch button, the color loop does not stop exactly at the time of button release but instead it continues to loop for about a second or so. Therefore, most of the time, it is not possible to choose the color of choice, because mostly it jumps to the next color and then stops to loop. Seems like there’s a delay occurring somewhere.

Any ideas what the problem could be?
Thank you in advance!

Here’s the code for the color loop blueprint automation:


alias: test_color_loop
description: ""
use_blueprint:
  path: mdolnik/color_loop.yaml
  input:
    light: light.tvroom
    helper_toggle: input_boolean.test_helper
    max_color_distance: 180
    transition:
      hours: 0
      minutes: 0
      seconds: 4
    color_1:
      - 255
      - 0
      - 0
    color_2:
      - 255
      - 104
      - 0
    color_3:
      - 255
      - 237
      - 0
    color_4:
      - 101
      - 255
      - 0
    color_5:
      - 0
      - 128
      - 0
    color_6:
      - 0
      - 255
      - 203
    color_7:
      - 7
      - 200
      - 255
    color_8:
      - 0
      - 51
      - 255
    color_9:
      - 115
      - 0
      - 255
    color_10:
      - 255
      - 7
      - 249
    color_11:
      - 255
      - 2
      - 150
    max_changes_per_second: 1
38

I don’t think it’s a problem per se, more of a symptom of how this blueprint does things. My blueprint has 20-something hardcoded colors it rotates each second, which can be detrimental to performance in some scenarios, with this blueprint I use 3 colors with 1s delay and still get the full rainbow spectrum.

I think the delay is happening because when you stop it, the command to rotate through the color spectrum to the next defined color was sent out, and it’s already happening, and it stops at the next step which is when it reaches the defined color. This is just my understanding.

If the ability to stop at certain color is important to you and you didn’t suffer any adverse performance effects from using my old blueprint just return to that one, until someone more knowledgeable can make this one work like you want (if possible).

edit: for reference this is what I use from this blueprint:

alias: bp Color Loop 2
description: ""
use_blueprint:
  path: mdolnik/color_loop.yaml
  input:
    light: light.lightstrip
    transition:
      hours: 0
      minutes: 0
      seconds: 30
    max_color_distance: 45
    color_1:
      - 255
      - 0
      - 0
    color_2:
      - 0
      - 255
      - 0
    color_3:
      - 0
      - 0
      - 255
    max_changes_per_second: 1
    helper_toggle: input_boolean.color_loop_control
mode: single

edit2: I think the transition is what’s delaying it, but if you put that to 1sec it’ll effectively work as my old bp did (I think :smiley:)

39

Hmm…I tried to change transition to 1 sec but the behavior did not change in any way.

40

Have been searching for something to make my exterior lights transition through red to orange during the Halloween month. I think I’ve found my answer.

I’m currently transitioning with just two colors - a deep red and a dark/burnt orange. Working on the timing to make it smooth and like a heart beat or breathing, but pretty darn happy with the 10 mins of config I’ve done so far.

Thanks for a great blueprint!

1 Like