[SOLVED] Template light ON/OFF problems with scripts

Configuration
, , , ,
1

Hi all!

Could anybody help me, what is my mistake in the below described situation?

I have a ‘template light’ definition in my configuration.yaml:

# ----- CUPBOARD LIGHT - ALTERNATIVE -----
# To allow custom lit/dim effects on the 'composite' device (3 sub-lights)
# -----
      cupboard_light:
        unique_id: '0192382f-7fe7-7748-be55-a26258ac70bf' # UUIDv7
        friendly_name: 'CUPBOARD LIGHT'
        value_template: "{{ states('light.cupboard_light_original') }}"
        level_template: "{{ state_attr('light.cupboard_light_original', 'brightness') }}"
        icon_template: >-
          {% if is_state('light.cupboard_light_original', 'on') %}
            hue:bulb-group-lightstrip
          {% else %}
            hue:bulb-group-lightstrip
          {% endif %}
        turn_on:
          service: script.toggle_the_cupboard_light
        turn_off:
          service: script.toggle_the_cupboard_light

…where the corresponding toggle script is created from the GUI…

alias: Toggle the CUPBOARD LIGHT
sequence:
  - alias: v2
    if:
      - condition: state
        entity_id: light.cupboard_light
        state: "off"
    then:
      - data:
          brightness_pct: 100
        target:
          entity_id:
            - light.cupboard_light_original_left
        action: light.turn_on
      - delay:
          hours: 0
          minutes: 0
          seconds: 0
          milliseconds: 750
      - data:
          brightness_pct: 100
        target:
          entity_id:
            - light.cupboard_light_original_middle
        action: light.turn_on
      - delay:
          hours: 0
          minutes: 0
          seconds: 0
          milliseconds: 750
      - data:
          brightness_pct: 100
        target:
          entity_id:
            - light.cupboard_light_original_right
        action: light.turn_on
    else:
      - data: {}
        target:
          entity_id:
            - light.cupboard_light_original_right
        action: light.turn_off
      - delay:
          hours: 0
          minutes: 0
          seconds: 0
          milliseconds: 750
      - data: {}
        target:
          entity_id:
            - light.cupboard_light_original_middle
        action: light.turn_off
      - delay:
          hours: 0
          minutes: 0
          seconds: 0
          milliseconds: 750
      - data: {}
        target:
          entity_id:
            - light.cupboard_light_original_left
        action: light.turn_off

My problem is, that with directly use the script, it works fine. If I run it, it works, toggle the state of the corresponding (composite) lamp/light. But using it in the above mentioned ‘template light’, with that I get always error message that:

Action script.toggle_the_cupboard_light uses action light.turn_off which was not found.

I simply do not understand it, and spent lot of time to correct, without success. As I said, the script works, itself… my first superficial tip was that because the light is defined in the configuration.yaml while the script in through GUI, maybe HA initialized the light before the scripts, we understandable error… but I was wrong as the error message does mention that the light.turn_on and light.turn_off actions are missing, which are funny as they are core services.

Did anybody meet with such problems? If you do not have any tips, I will drop a Github bug report, but really in just the last case…

Thanks for your help/effort in advance (and Wish You a Merry Christmas :slight_smile: )!

2

Hello Tamás Tóth,

I’m, thinking about the actual problem, but not coming up with anything yet there. Still thinking.

I was distracted by the script. I don’t know if the delay is for effect, but you could put the delay back in here if you need/want it and still shorted this up by half using this. However using this you could cut that script much more.
Just offering the code if you want to use it…

alias: Toggle the CUPBOARD LIGHT
sequence:
  variables:
    lights:
      - light.cupboard_light_original_left
      - light.cupboard_light_original_middle
      - light.cupboard_light_original_right
    state: '{{ light.cupboard_light.state }}'
    actn: '{{ "light.turn_" ~ state }}'

  - alias: v3 Proposed
    action: '{{ actn }}'
      target:
        entity_id: '{{ lights }}'
3

Back to the problem, can you include a little more of the configuration.yaml,?
Specifically from where the template: key is down to this specific light?
Want to check that that syntax is healthy.

4

Dear @Sir_Goodenough !

Thanks for your effort, at the very end, I already found the reason, which was a totally different aspect of the composition.

So… basically it was a very sneaky problem, if not more, and while I really have to throw (and did it more times) lot of thanks for all the HA developers, this situation is far more… hmmm… disgusting, how it should be.

The reason was neither the ‘template light’ nor the corresponding script. The reason was something which I made before but HA does not handle it with enough transparency.

‘Scripts’ currently does not handled (yet) in the totally same way as for example ‘automations’. If you create one, it will stored in the scripts.yaml but instead of with a randomly generated eg. UUID like unique ID, with the entity ID as its unique ID…

toggle_the_cupboard_light:
  sequence:
  - data:
      brightness_pct: 100
    target:
      device_id: 117348c373cd68ad9eb9693327a95a3a
    action: light.toggle
    alias: v1
    enabled: false
  - alias: v2
    if:
    - condition: state
      entity_id: light.cupboard_light
      state: 'off'
    then:
    - data:
        brightness_pct: 100
      target:
        entity_id:
        - light.cupboard_light_original_left
      action: light.turn_on
    - delay:
        hours: 0
        minutes: 0
        seconds: 0
        milliseconds: 750
...
..
.

…where the really tricky part of it, that currently on the GUI you can rename not just the alias (human readable name) of it, but also the entity ID, which - for make it funny - will not stored in the scripts.yaml itself. From this point there could be sneaky problems. From the GUI you can refer to the script somewhere with its original ID (call it unique ID), but somewhere else with its given/renamed entity ID, while in the scripts.yaml you will see just the original. Somehow in the past I made some mistake and my scripts.yaml contained a toggle_the_cupboard_light and one another toggle_the_cupboard_light_2 scripts, where for the fun, the GUI referred to the second one with the name of the first one, and because this anomaly there were some inconsistency/corruption among my scripts. When I edited the toggle_the_cupboard_light script, the result had realized in the toggle_the_cupboard_light_2 script, while I always referred to it with toggle_the_cupboard_light as the GUI told me that.

I’m sure, sometime in the past I made some mistake, which led me to the problem, but with such ID handling on the scripts, which is described in the above referred Git issue, I think it is not so hard to do, with totally non-transparent, and unacceptable result.

I did not thought deeply about the whole possible flow yet, to re-modelling the problem, but if scripts uses its entity IDs as main unique ID, what can be changed from the GUI, but the result will be basically a specially ‘hidden solution’, as it turns out that the originally given entity ID is basically not the real entity ID, but its unique ID which will stay the same after you changed your entity ID from the GUI, could lead us into lot of problems, how the Git ticked had already described… maybe in the past I renamed the script in the scripts.yaml, which is bad, now I know, but… the whole think could not be realized if the scripts had handled in the same way as the automations. They get a really simply numerical unique IDs, when they born, and the entity ID is just a readable, secondary ID of them, with a simple free word string as their aliases… with such way nobody want to change their unique IDs, while the really entity ID could be changeable… this should not be handle with a special hidden solution, everything could be transparent, etc.

So at the end… it’s almost sure, that the main reason was my mistake, but a mistake which could be avoidable a proper ID handling in HA, and as the attached Git example shows it, this is not just mine, but other persons problem also.

For solving the problem, I had deleted all the relevant scripts form the GUI, also checked any garbage in the scripts.yaml, then recreated from the GUI, carefully given its ID and name, and at the had referred to it properly from the ‘template light’ in the configuration.yaml.

I think it is definitely have to change/clear/solve the unique ID/entity ID handling of the scripts in HA to a same one which we have with automations, which does not allow as to make unfollowable mistakes (which in my case generated lot of hours of unnecessary ‘debugging’ of an error).

5

I think all that said you had the wrong entity.

OK, happens t us all.

But consider my change to the code. it is much easier to follow and understand.

And why the 750ms delays? (curious)