Help needed with light transition

Configuration
36

I don’t know what on earth is goign on either, I literally copy an pasted it from the earlier post into hassio.

I’ve amended it again and this is now what it looks like:

- id: '1584046806268'
  alias: Marine Tank Dimmer
  description: ''
  trigger:
  - at: '12:00'
    platform: time
  condition: []
  action:
  - data:
      brightness: 30
    entity_id: light.0x680ae2fffeb18442_light
    service: light.turn_on
  - wait_template: "{{ is_state_attr('light.0x680ae2fffeb18442_light' , 'brightness' , 30) }}"
  - data:
      brightness: 255
      transition: 120
    entity_id: light.0x680ae2fffeb18442_light
    service: light.turn_on
  - wait_template: "{{ is_state_attr('light.0x680ae2fffeb18442_light' , 'brightness' , 255) }}"
  - data:
      brightness: 30
      transition: 120
    entity_id: light.0x680ae2fffeb18442_light
    service: light.turn_on
37

Still doesn’t work though!

38

I’ve edited it to the first step and this transitions ok:

- id: '1584046806268'
  alias: Marine Tank Dimmer
  description: ''
  trigger:
  - at: '12:00'
    platform: time
  condition: []
  action:
  - data:
      brightness: 255
      transition: 180
    entity_id: light.0x680ae2fffeb18442_light
    service: light.turn_on

It seems to this that doesn’t work:

- wait_template: "{{ is_state_attr('light.0x680ae2fffeb18442_light' , 'brightness' , 255) }}"

In thsi example, the light does not switch off after 3 minutes:

- id: '1584046806268'
  alias: Marine Tank Dimmer
  description: ''
  trigger:
  - at: '12:00'
    platform: time
  condition: []
  action:
  - data:
      brightness: 255
      transition: 180
    entity_id: light.0x680ae2fffeb18442_light
    service: light.turn_on
- wait_template: "{{ is_state_attr('light.0x680ae2fffeb18442_light' , 'brightness' , 255) }}"
  action:
    entity_id: light.0x680ae2fffeb18442_light
    service: light.turn_off
39

Manually trigger it and then have a look at the logs and see if there is an error.

40

As an experiment, set the light’s initial brightness to some low value (30) then run the simplified 3-minute example you just posted. I’m curious to see if the light’s starting state influences the first wait_template (probably not but if we’re poking at this thing, let’s see how it reacts to that).

41

What I have just done is set the brightness to 0 and then executed this automation. Upon execution the controller relay can be heard to urn on and then immediately turn off, suggesting the wait_template is not functioning correctly:

  action:
  - service: light.turn_on
    entity_id: light.0x680ae2fffeb18442_light
    data:
      brightness: 255
      transition: 180
  - wait_template: "{{ is_state_attr('light.0x680ae2fffeb18442_light' , 'brightness' , 255) }}"
  - service: light.turn_off
    entity_id: light.0x680ae2fffeb18442_light

This works:

  action:
  - data:
      brightness: 255
      transition: 180
    entity_id: light.0x680ae2fffeb18442_light
    service: light.turn_on
  - delay: 00:03:30
  - entity_id: light.0x680ae2fffeb18442_light
    service: light.turn_off
42

Still need to know if there’s an error, it might tell us if there’s an issue with the template.

43

When I look at the States page, all lights that are off have no brightness attribute. It only appears when a light is on. That’s the reason I wanted to see if the light’s initial state influenced the wait_template. It’s a long-shot but I thought it might be worthwhile to eliminate this possibility.

Definitely check the system log for any error messages related to the automation’s execution.

44

Indeed.

Possibly if we just replace the first wait_template with a delay to ensure the light is on before everything else (which, in the fairness, is what I suggested right at the start) then maybe it will work as intended.

45

@anon43302295, I tried this and the light comes on at 30 but never ramps up:

- id: '1584046806268'
  alias: Marine Tank Dimmer
  description: ''
  trigger:
  - at: '12:00'
    platform: time
  condition: []
  action:
  - data:
      brightness: 30
    entity_id: light.0x680ae2fffeb18442_light
    service: light.turn_on
  - delay: 00:00:30
  - data:
      brightness: 255
      transition: 60
    entity_id: light.0x680ae2fffeb18442_light
    service: light.turn_on
  - wait_template: "{{ is_state_attr('light.0x680ae2fffeb18442_light' , 'brightness' , 255) }}"
  - data:
      brightness: 30
      transition: 60
    entity_id: light.0x680ae2fffeb18442_light
    service: light.turn_on

If the system log is the one found in Developer Tools, then there are no error messages regarding wait_templates or anything else related to the automation.

TBH, I think it would be simpler just to add delays between the actions as suggested by Dave.

46

Hang on many lights when turned on at a low value, who then get set to a higher brightness report reacing that brightness imediately even though they are still ramping up.
So I don’t think that wait template will work

47

The automation works using delays:

- id: '1584046806268'
  alias: Marine Tank Dimmer
  description: ''
  trigger:
  - at: '12:00'
    platform: time
  condition: []
  action:
  - data:
      brightness: 30
    entity_id: light.0x680ae2fffeb18442_light
    service: light.turn_on
  - delay: 00:00:30
  - data:
      brightness: 255
      transition: 60
    entity_id: light.0x680ae2fffeb18442_light
    service: light.turn_on
  - delay: 00:01:02
  - data:
      brightness: 30
      transition: 60
    entity_id: light.0x680ae2fffeb18442_light
    service: light.turn_on
48

so it’s back to plan A

OR

We could create an input number 0 - 255
Calculate the seconds offset from the start time (using sensor time to generate an update) and then change the number (both up ramp and down ramp). The number change will drive lamp to brightness and that way you have no wait timer.
And if you restart HA - No problem !

49

Sounds good to me, but beyond my skills :smiley:

50

Well, I’d kinda like to hear Marc and Teras’s views on it and maybe Dave’s too
I’m thinking the input number needs to be to 3dp (cos the fractions will add over time) but maybe not as we calculate elapsed seconds do the multiplication to say 6dp then int it

In the interim run with the delays

This will be hard coded so you are sure it starts at 12:00 peaks at 17:00 and off at 22:00 and the min is 30 max 255

If it broke and left the lights on would the fish survive 100% output for an extended period ?

51

I’ve found that the minimum value for the lights is 11, below such they do not turn on, so that would be a better starting point that 30.

The fish would survive extended lights on or lights off times and I would notice if there was any issues anyway.

TBH, I’m ok with the delays, it’s just that the wait_template and now the calculated offset seems a cleaner solution, but I’m happy to stay with delays if coding the alternative is troublesome.

52

30 ish is 11 % of 255 (well its 28, but I thought you said 12%, regardless we’ll sort that out)

So for better resolution we should do brightness rather than brightness_pct

53

I’ve just been playing with this for a good half an hour trying to get my head around it, and I think we’ve found a scenario that was never expected and, as you say, the brightness of the light is reflected as the end value of the transition throughout it. (ie if the light is currently 20% and you set a transition of 4 hours to 100%, the brightness will show as 100% immediately and throughout the duration of the 4 hours).

So, create an automation that triggers on a test input_boolean, and then actions:

Light on at 20%
Delay 5 seconds
Light up to 100% with transition
Wait template for brightness 255
Light back to 20 with transition.

then create a new view on lovelace with your input boolean at the top and a light card beneath it. Then hit the boolean.

You’ll see that the light brightness goes on correctly, then 5 seconds later the brightness ‘jumps’ up and back down instantly. This is, of course, because it’s jumping to 100%, fulfilling the wait_template and executing the next step, which is to return it to 20%.

If you then remove the wait template and the final action and restart the experiment, you will see tha after the 5 seconds delay the brightness ‘slider’ on the light card jumps immediately to 100%, in spite of the real-life bulb slowly gaining brightness at the expected rate.

So yeah, delay is the only option.

I’m trying to decide if this is a ‘bug’ or not though. If you set a transition of 4 hours from 0% - 100%, I would expect the brightness to gradually creep up, not to jump to 100% at second 1. That is to say I would think the brightness attribute should reflect the current actual brightness of the light, not the intended end result in 4 hours time.

But yeah.

Thanks for the headache guys :stuck_out_tongue_winking_eye:

1 Like
54

It seems more logical to me that the brightness attribute be that of the actual level, not the end level.

You know you love it really :smiley:

55

I think this is intended behaviour and not a fault with any integration.
If you set a transition then unplug HA the light will continue towards its goal.
Additionally, this won’t trigger any events during the process otherwise you’d get spammed with events.
Also the device ‘is reporting’ it’s goal so you know where it will be.
If you ‘need’ to know the current (but transitory level) then you’d need to lobby ALL the manufactures to add in another attribute for you to read.