Help needed with light transition

Configuration
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.

56

@Mutt, are you saying the transition time is controlled by the light controller and not from HA?

1 Like
57

Yep, once the instruction is given there is no more communication

HA only outputs at 1 second intervals and that wouldn’t work with a 0 to 100% transition as over 5 seconds you’d get 0, 20, 40, 60, 80 and 100% - you’d be at a disco

Also the network would easily get swamped if at 17:00 you wanted all your lights to smoothly transition to 60% over 10 seconds or similar

58

It’s 5 hours that I want to transition over, not seconds. I didn’t realise however that it was the controller that did the transitioning and not HA. That makes more sense as to why HA reports on the final level.

59

I was just using hyperbole to illustrate a point

1 Like
60

Okay,

  1. Can you confirm your lowest brightness (not percent) or the level you are happy with.
  2. Can you confirm that if you have a lamp on (whatever level) and you turn it on brightness: 0, it goes off
  3. Can you confirm your maximum brightness (you are happy with)
  4. Do you want maximum brightness for (say) 2 seconds (normal ramp up and normal ramp down) or do you want it held for (say) 80 secs (longer would require more code)
  5. I write for packages, do you use packages or are happy to cut and paste into your own configuration
  6. If we run the automation with say seconds: ‘/80’ this will run EVERY 80 seconds whether it’s inside your time frame or not, happy ? Alternative is more code AND if you restart HA the light may come on and stay on at the level it went off at, though we could have the input number initial: 0 (and I hate disabling automations).
  7. Most triggers (in time slot) will raise/lower level by 1/255, there will be the odd trigger that has 2/255 (not many but … ) do you wish to specify a default transition to lower the perceptive change (say 10 secs)
  8. Does your dimmer have a default transition value, and can you change it to say 10 secs.
  9. Do you need an override, say when you are cleaning the tank - set to 100% either on a timer (how long) or just whilst the input boolean override is on.