Transition time when turning on doesn't work. Turning off does work, but is jitterery (not smooth)

[cooljimy84]

The problem

when setting transition: 10 and turning on the light in home assistant the light waits 9 seconds (totally off) then go to the set brightness in the last 1 second.

service: light.turn_on target: entity_id:

• light.esp5_led_strip data: transition: 10 rgbw_color:
• 255
• 255
• 255
• 255 brightness_pct: 100

transition time off works as expected, but has stutters and is not a smooth ramp down.

I did have this open [https://github.com/esphome/issues/issues/1558]

Which version of ESPHome has the issue?

2021.8.2

What type of installation are you using?

Docker

Which version of Home Assistant has the issue?

2021.8.8

What platform are you using?

ESP8266

Board

nodemcu

Component causing the issue

neopixelbus

Example YAML snippet

esphome:
  name: esp5
  platform: ESP8266
  board: nodemcuv2

status_led:
  pin:
    number: GPIO2
    inverted: true

# Above the hallway door
wifi:
  ssid: 'WIFI'
  password: 'PASSWORD'
  fast_connect: true

mqtt:
  broker: 'IP'
  username: 'USERNAME'
  password: 'PASSWORD'
  reboot_timeout: 4min

# Enable logging
logger:
  level: INFO

ota:
  password: 'PASSWORD'

text_sensor:
  - platform: version
    name: "ESPHome Version ESP5"
    hide_timestamp: true

sensor:
  - platform: uptime
    name: ESP5 Uptime Sensor
    update_interval: 360s
  - platform: wifi_signal
    name: "WiFi Signal ESP5"
    update_interval: 360s

switch:
  - platform: restart
    name: "ESP5 Restart"

e131:
  method: multicast

light:
  - platform: neopixelbus
    type: GRBW
    pin: GPIO3
    num_leds: 59
    name: "ESP5 LED Strip"
    id: mylight
    color_correct: [100%, 100%, 100%, 50%]
    default_transition_length: 0.5s

Anything in the logs that might be useful for us?

[08:34:45][D][light:038]: 'ESP5 LED Strip' Setting:
[08:34:45][D][light:049]:   State: ON
[08:34:45][D][light:053]:   Brightness: 100%
[08:34:45][D][light:057]:   Color brightness: 100%
[08:34:45][D][light:061]:   Red: 100%, Green: 100%, Blue: 100%
[08:34:45][D][light:065]:   White: 100%
[08:34:45][D][light:087]:   Transition length: 10.0s

Additional information

No response

[cooljimy84]

I have also upgraded and tested a fastled_clockless set of LEDs and this has both the same issues. The behaviour continues if i set default_transition_length in the config and just turn the light on.

version 1.13.6 behaves as expected on both on and off.

[probot-esphome[bot]]

Hey there @esphome/core, mind taking a look at this issue as it has been labeled with an integration (light) you are listed as a code owner for? Thanks! _{^{(message by CodeOwnersMention)}}

[cooljimy84]

Just tried 1.14.0b1 and the transition time isn't working (though more like the old ticket where i set 10 seconds and it take 3 seconds https://github.com//issues/1558 ) Hope this helps.

[oxan]

Can you try with gamma_correct: 1.0?

[cooljimy84]

Off is now very smooth turning off. Turning on seems to go straight to 1% brightness and stay there for a few seconds then quickly ramps up.

For example, If i set transition time to 20 seconds 100% brightness 255, 255, 255, 255 color 2 seconds after hitting call service, the leds turn on at 1% brightness. 10-11 seconds after hitting call service, the leds ramp up smoothly to 100% brightness.

[oxan]

Seems the fix to make the transition not run fast made it run slow ;-)

Thinking a bit more thoroughly about it than last time, it seems the whole (addressable) transition logic is dubious at best.

[cooljimy84]

Thats a shame, as i saw the posts about using it and ended up creating a lamda effect that turns each LED off one by, rather than fading the whole stripe.

[squirtbrnr]

I'm running 2021.9.2 and still having this issue on a neopixelbus light. transition is ignored until the very last second, then the light uses the default transition. In HA, the reported supported features of the light under the states page in developer tools does not show transition as a supported mode for some reason. I was using 1.14 (EDIT: I actually don't remember but it was 1.13, 1.14, 1.16, and/or 1.19) and transition was working fine until I update to the latest ESPHome. I have another light that uses 3 outputs (1 for each RGB color) and it does not have any issues with transition.

Light platform configuration in ESPHome yaml:

  - platform: neopixelbus
    id: kitchen_server_cabinet_under
    name: "Kitchen Server Cabinet Under"
    variant: SK6812
    pin: GPIO23
    num_leds: 120
    type: GRBW
    method: ESP32_I2S_1
    gamma_correct: 2.8
    default_transition_length: 1s
    color_correct: [100%, 100%, 100%]
    effects:

[cooljimy84]

Just retested with 2021.9.2 version as well, same issue.

[squirtbrnr]

Just updated to 2021.10.3 and still experiencing this issue. The transition time is treated more as a delay.

[oxan]

Could any of you try esphome/esphome#2786 by adding this to your YAML (probably needs 2021.11):

external_components:
  - source: github://pr#2786
    components: [ light, fastled_base, neopixelbus ]

[cooljimy84]

i get the following error after pulling latest docker image.

chippie@chippie-ThinkPad-T480:~/ESPHome$ sudo docker run --rm --net=host -v "${PWD}":/config -it esphome/esphome ESP5.yaml run
WARNING Calling ESPHome with the configuration before the command is deprecated and will be removed in the future. 
WARNING Please instead use:
WARNING    esphome run ESP5.yaml
INFO Reading configuration ESP5.yaml...
INFO Cloning https://github.com/esphome/esphome.git@pull/2786/head
INFO Fetching pull/2786/head
Failed config

external_components: [source ESP5.yaml:7]
  - [source ESP5.yaml:7]
    source: github://pr#2786
    components:  [source ESP5.yaml:8]
      - light

      Could not find __init__.py file for component fastled. Please check the component is defined by this source (search path: .esphome/external_components/45bafb59/esphome/components/fastled/__init__.py).
      - [source ESP5.yaml:8]
        fastled
      - neopixelbus

[oxan]

Sorry, my bad, fastled should be fastled_base.

[cooljimy84]

Ninja edit there ! :)

seems it requires a variant (rather then using the default)

WARNING Calling ESPHome with the configuration before the command is deprecated and will be removed in the future. 
WARNING Please instead use:
WARNING    esphome run ESP5.yaml
INFO Reading configuration ESP5.yaml...
Failed config

light.neopixelbus: [source ESP5.yaml:78]

  'variant' is a required option for [light.neopixelbus].

[oxan]

seems it requires a variant (rather then using the default)

Um yes, that's an unrelated change. Just add variant: 800KBPS.

[cooljimy84]

Testing shows it totally ignores the on time, always takes one second to turn on.

Turning off does take the transition time, and is less "jerky" but still seems to fade the colour channels at different speeds

If i change the default transition in the config it has the same results as above. It's hard to describe the colour thing, i can do a video and upload if that would be any help ?

[oxan]

Testing shows it totally ignores the on time, always takes one second to turn on.

That seems weird, it definitely has effect for me. What gamma_correct, color_correct and transition length values are you using?

but still seems to fade the colour channels at different speeds

I think this is due to different color LEDs having different characteristics, and driving them with the same value doesn't produce the same amount of light.

It's hard to describe the colour thing, i can do a video and upload if that would be any help ?

Yeah, that could be helpful, though color issues are often hard to identify on video.

[cooljimy84]

I've got two strips the same length (from the same roll) one that i will run 1.13 (that is the release before i started seeing issues) on and one that i will run 2021.11 on, 'll also upload the config files for each, and try to reflect the gamma/colour correct changes in both configs.

I'm really appreciative that you keep looking at this, it's gotta be one of the more frustrating bugs/issues. I'll drop a link once i've done the vid (prob 12+ hours before i can do it)

[cooljimy84]

I just closed a diffrent bug as my testing for this one shows that 1.20 and below doesn't seem to respect RGBW values and still drives the RGB when set to just white, this make is appear brighter.

Gonna try again tomorrow for the transistion video as i got side track on this other bug. https://github.com/esphome/issues/issues/2526

I think they might be closely related.

[cooljimy84]

transition on still waits till the last second, then turns on. i.e. if you set transition time on of 10 seconds, the leds stay off till the 9th second then turn on.

transition off is still a little jerky (not as smooth a ramp down as 1.13, which appears smooth to the naked eye) If i set it to 30s transition off from 255, 255, 255, 255 then it smoothly fades down for the first 13 seconds then seems to stop fading for 12 seconds then in the last 5 seconds it flickers down brightness (almost like its turning off between each brightness change, kinda)

Filming is proving hard as my camera doesn't seem to lock settings so shows the PWM far to much to be helpful.

[oxan]

Can you try it with this and share the logs (at DEBUG level)?

external_components:
  - source: github://oxan/esphome@addressable-transition-log
    components: [ light, fastled_base, neopixelbus ]

[cooljimy84]

Getting the following error

INFO Reading configuration ESP5.yaml...
INFO Cloning https://github.com/oxan/esphome.git@addressable-transition-log
Failed config

external_components: [source ESP5.yaml:7]
  - [source ESP5.yaml:7]

    Remote branch addressable-transition-log not found in upstream origin.
    source: github://oxan/esphome@addressable-transition-log [source ESP5.yaml:7]
    components: 
      - light
      - fastled_base
      - neopixelbus

[oxan]

Sorry, should've been light/addressable-transition-log:

external_components:
  - source: github://oxan/esphome@light/addressable-transition-log
    components: [ light, fastled_base, neopixelbus ]

[cooljimy84]

debug fade on 10 seconds.log same behaviour as before

debug fade off 10 seconds.log same behaviour as before

Did you still want me to try getting a video as well ? I'm sure i can try locking the exposure and bits to help with the rolling shutter/flicker ?

[oxan]

The problem here is, as I suspected, the gamma correction which causes precision to be lost. I'll see if I can work out something to avoid that.

However, even if everything works as expected, with your settings (gamma correction of 2.8, 10 seconds transition) it would take more than two seconds for the transition to actually turn any lights on. This is caused by the 8-bit output power control of the LEDs, which is skewed towards the top of the illuminance range by gamma correction. For example at 20% of the transition, the light would be set to 10.4% (due to smoothing), which after gamma correction is equal to an output power of just 0.176%. With 8-bit range, the minimum step in output power we can apply is a bit more than 0.39% (100%/255), so that 0.176% gets rounded down to zero.

There's a few workarounds we can try to improve the experience somewhat (e.g. rounding up low output power values so that at least the light turns on immediately), but the harsh reality is that lights with such a limited range that also need a high gamma correction factor will never get a good-looking transition.

Did you still want me to try getting a video as well ? I'm sure i can try locking the exposure and bits to help with the rolling shutter/flicker ?

Nah, that's not necessary, I got information from the logs.

[cooljimy84]

That explains why all my lights turn off below around 10% (I've noticed this but always just ignored it)

The gamma correction is the one listed as default on the docs (and it also seems to be perfect balance for my mix of RGB RGBW RGBWW) but that makes sense.

Did you want me to try without setting the gamma in the config? or would that just use the default 2.8 anyway?

[oxan]

The gamma correction is the one listed as default on the docs (and it also seems to be perfect balance for my mix of RGB RGBW RGBWW) but that makes sense.

Yes, there's a reason it's the default, it's usually a good value. We should probably document the disadvantages of it, though.

Did you want me to try without setting the gamma in the config? or would that just use the default 2.8 anyway?

You can try gamma_correct: 1.0 to disable it.

[cooljimy84]

Yep, setting to 1.0 makes the light behave as expected on fade up and on fade down.

[squirtbrnr]

I just updated to esphome 2021.11.4. I did not add any of the lines mentioned above to my devices. I set the gamma correction to 1.0. Transition is much smoother, however, with a transition time of 10 seconds, the light turns on very dim and stays that way for about the first 5 seconds, then the last 5 seconds will slowly fade up to the values I set.

[w531t4]

i'm seeing similar behavior - neopixels. when gamma_correct set to 1.0, color_brightness: 100, brightness: 100, the transition occurs evenly across the specified interval. However, at gamma_correct: 1.0, color_brightness: 100, brightness: 50, a transition continues to occur evenly across the interval, except in the middle of the transition the led's turn off and flicker a bit.

[squirtbrnr]

I am still seeing this issue. When I switch back to gamma_correct: 1.0 I get a slightly smooth but not full transition from off to on. I set the RGBW light to the following:

        rgbw_color:
          - 255
          - 100
          - 0
          - 255
        transition: 1

However, it appears to ignore the transition time and it initially lights up red for the first 5 or so seconds, then fades on to the desired color (should be a very warm white). my esphome code has the default transition time.

[Pulcik]

I am experiencing same behavior. I am trying to mimic "Breathe" animation with Pulse effect. Animation from Bright to OFF is nicely smooth. But from OFF to Bright is jittery at start, then wait and then ramp up in last second. Gamma_correction is moving with this behavior, but not fixing it. I am testing on QTPY C3 with RMT LED Strip component, I know, it is new-ishm, but I have same experience from past with normal ESP32.

[Robert-K]

Running into the same issue here. I'm trying turn on several lights using the same call in homeassistant with a transition time of several minutes for a sunrise effect. My tuya-based lightbulbs correctly fade over several minutes, while the neopixel lights turn on in the last second :( I don't wanna change the default transition time, as that's what I want them to use when switching normally..