Help with RGB light automation

Why this

   - service: light.turn_on
     data:
       entity_id: light.led_strip_rgb
       rgb_color: [255, 0, 0]
       brightness: 255
       transition: 50        

… work, and the following didn’t?

  - service: light.turn_on
    data_template:
      entity_id: light.led_strip_rgb
      brightness: 255
      transition: 50            
      rgb_color: >-
        [{{ states('input_number.led_strip_r') | int }},{{ states('input_number.led_strip_g') | int }},{{ states('input_number.led_strip_b') | int }}]

The result of the rgb_color template is correct if passed with the template editor.

Based on this post, try this:

      rgb_color: >-
        [{{ "states('input_number.led_strip_r') | int }}", "{{ states('input_number.led_strip_g') | int }}", "{{ states('input_number.led_strip_b') | int }}"]

You may not even need to use the int filter.

Looking at the log i found the following error:

Invalid data for call_service at pos 2: None for dictionary value @ data['rgb_color']

But as specified here Lights rgb_color is a valid attribut of light.turn_on service

I believe the complaint is that the value for rgb_color is None.

None for dictionary value @ data['rgb_color']

For testing the value of the template I just created this quivalent:

  - service: mqtt.publish
    data_template:
      topic: "DIODER/CMD/RGB"
      payload: >-
        [{{ states('input_number.led_strip_r') | int }},{{ states('input_number.led_strip_g') | int }},{{ states('input_number.led_strip_b') | int }}]

… well, the content is perfect formed.

1 Like

I believe the issue was what I had originally suspected. This is understood to be a python list:

       rgb_color: [255, 0, 0]

The output of a template is always a string. Therefore the product of this template may look like a list but it is actually a string:

      rgb_color: >-
        [{{ states('input_number.led_strip_r') | int }},{{ states('input_number.led_strip_g') | int }},{{ states('input_number.led_strip_b') | int }}]

So what’s happening is that a string is being supplied to the rgb_color option when it is expecting a list.

In your MQTT publishing example, the content may indeed be perfectly formed but it’s a string which is precisely what the payload option accepts.

@123, okay!. this could be the problem. Now… how to “convert” the output to a list?

Working on it …

I’m having trouble emulating the actual light, to test the template, so maybe I’ll just let you perform the test. Try this:

      rgb_color:
        - "{{ states('input_number.led_strip_r') | int }}"
        - "{{ states('input_number.led_strip_g') | int }}"
        - "{{ states('input_number.led_strip_b') | int }}"
1 Like

its as @123 says,

this works fine:

        rgb_color: ['{{ (range(0, 255)|random) }}',
                    '{{ (range(0, 255)|random) }}',
                    '{{ (range(0, 255)|random) }}']
        brightness: '{{ (range(50, 250)|random) }}'
        transition: '{{ (range(1, 3)|random) }}'

not sure if the rgb template I use is yaml identical to the list @123 provides, there are many variations boiling down to the same.

Of course mine is random, so set it to your specific needs, per color_template.
Hope this helps

Solutions I’ve seen include what Marius provided:

rgb_color: ['{{ bla }}', '{{ bla }}', '{{ bla }}']

or this one:

rgb_color:
  - '{{ bla }}'
  - '{{ bla }'
  - '{{ bla }}'

The moment you start doing this with rgb_color it fails:

rgb_color: >
  ['{{ bla }}', .... etc

The last example is no longer handled as a list but as a string.

2 Likes

I found a solution that each of you had actually already found …

  - service: light.turn_on
    data_template:
      entity_id: light.led_strip_rgb
      rgb_color: 
        - "{{ states('input_number.led_strip_r') | int }}"
        - "{{ states('input_number.led_strip_g') | int }}"
        - "{{ states('input_number.led_strip_b') | int }}"

Many thanks! guys!

When I format it this way and trigger my automation, it causes my esp32 running esphome with the sk6812 leds to crash. I have to pull power and restart. This behavior is consistent. I’d just rather save problems like this for my 40 hour a week job. :rofl:

EDIT: Wait…it’s crashing all together - just ignore me

Thanks. Even after 5 years, this helps me.

Only that nowadays, the “date_template” is not needed anymore. It’s simply “data”.