Light delay after AC power on

[czAtlantis]

Hi, I have multiple lights YLXD032 and I decided to "ESPhome" some of them. Due to limitations with single core ESP32 I decided to desolder the ESP32 and replace with general dual core model. It is working fine but if I switch the light with regular AC switch, it now takes considerable time to actually light up. I would say over 1 second. With the stock ESP32 it was moreless instant.

I understand that these lights are meant to be powered all the time and control them using data commands but in some rooms I would like to have them controlled using regular wall switches - and yet I want to have ESPhome in them as the stock firmware is shit.

I am sorry for not understanding it more deeply so I ask here:

• is it because the dualcore ESP32? I didn't try to flash the original one
• is it some limitation of ESPhome (takes long time to boot up)
• • In this case I am quite amazed that Yeelight produced firmware that is so quick to boot
• do you have any tips how to improve the startup delay?

Here is a video comparing those two lights. First stock firmware and second ESPhome
https://user-images.githubusercontent.com/106582464/172583555-0ec7f183-c8d5-423c-9f7d-26e090b6a78d.mp4
(listen for the switches clicks)

[syssi]

1. IMO the single and dual core ESP32 shouldn't make a difference here. Having more cores is always better ;-)
2. Do you use the restore_mode or how do make sure to turn the light on on boot? I could try something like this:

esphome:
  name: "${name}"
  on_boot:
    then:
      - light.turn_on:
          id: ceiling

If you didn't tried the restore_mode you could give it another try with:

    lights:
      - name: ${name}
        id: ceiling
        restore_mode: ALWAYS_ON

[czAtlantis]

Hi, thanks for the quick reply. I have been using the "ALWAYS_ON" approach. Tested the "on_boot" but it didn't help - it was even bit (50-100ms I would say) slower (tested with 2 lights on the same switch).

[syssi]

Another idea: If I remember correctly every ESPHome light entity comes with a default transition length. Please set the default transition length to 0ms and try again:

    lights:
      - name: ${name}
        id: ceiling
        gamma_correct: 0
        default_transition_length: 0ms

May be the transition feels like a delayed turn on.

[czAtlantis]

Thanks for the tip but it has almost no effect - still takes at least 1 second to start. I tried to search what is typical esphome on ESP32 bootup time but I couldn't find anything about this matter

[syssi]

This is my last idea: Next to your your-yeelight-config.yaml you should find a .esphome/build/your-yeelight-config/src folder containing a main.cpp. This is the generated/assembled cpp file (based on the yaml). Just open the file and try to get a better understanding of the boot/setup process. It looks like the WiFi component is initialized as first step (may be the setup is blocking?). You could ask at the ESPHome support channel how to re-order the boot process. If you are able to move the output (PWM initialization) and light component to the top the mission is solved.

[B48D81EFCC]

Hey there,

I experience the same behavior with my yeelink.light.ceiling22. On AC on there is a noticeable delay until the light is turned on.
I did not replace the ESP module. I used the original integrated module.

[B48D81EFCC]

Another idea: If I remember correctly every ESPHome light entity comes with a default transition length. Please set the default transition length to 0ms and try again:

    lights:
      - name: ${name}
        id: ceiling
        gamma_correct: 0
        default_transition_length: 0ms

May be the transition feels like a delayed turn on.

HI again,

I fixed it. BUT:

    name: "${name} ceiling light"
    id: ceiling_light 
    default_transition_length: 0ms

had no effect. The delay was still there (and no transition)

This is working for me

    name: "${name} ceiling light"
    id: ceiling_light
    default_transition_length: 0s

[syssi]

Good job!

[B48D81EFCC]

Good job!

Thanks. Should I create a PR? Because the transition is not working, there is no fading. It is just a delay of 1s until the light is turned on.

[syssi]

Transitions are working in general. :-)

[stomko11]

@B48D81EFCC I am also noticing delay when I power device on from AC. I tried default transition 0s, but it does not seem to make any difference. Any idea?

light:
  - platform: monochromatic
    name: "${friendly_name} Nightlight"
    id: night_light
    output: output_nightlight
    gamma_correct: 0
    on_turn_on:
      - light.turn_off: ceiling_light
  - platform: cwww
    name: "${friendly_name}"
    id: ceiling_light
    cold_white: output_cold
    warm_white: output_warm
    cold_white_color_temperature: 6000 K
    warm_white_color_temperature: 2700 K
    gamma_correct: 0
    constant_brightness: true
    on_turn_on:
      - light.turn_off: night_light
    restore_mode: RESTORE_AND_ON
    default_transition_length: 0s

[B48D81EFCC]

Hi @stomko11.
Unfortunately I still face the issue with the delay.
I did not tested / tried different solutions yet, because I got used to the delay 🙈

But since you have the issue as well, I will take this opportunity and start testing it again.
I am going to update to the latest esphome version etc.

[stomko11]

OK. One of the things I had to change was restore mode - but that was due to remembering which color temperature to start with.
I was also thinking - is it possible that delay would be shorter by using different board? Maybe Wemos D1 mini or so?
btw - I just tried to measure it with stopwatch, and it is 2 seconds until light turns on after powering it on with switch

edit:
It is slightly better after adding following:

esphome:
  name: ${device_name}
  on_boot:
    priority: 800
    then:
      - light.turn_on:
          id: ceiling_light
          brightness: 100%

[czAtlantis]

I just tried to measure it with stopwatch, and it is 2 seconds until light turns on after powering it on with switch

Do you have just the bare light in the code? Or are you setting up also bluetooth (for a remote control etc)? In my case the esp32_ble_tracker adds another second or so to the startup.

Btw when I had esphome on a light with esp8266 I don't remember having this issue - it started right away.
Testing the difference is pretty easy - just take one ESP32 board, one ESP8266 board, two LEDs and wire the input to those boards in parallel. And then connect power and see the delay. I could do this test but right now I don't have any space left on my work bench for such experiment so no promisses

[syssi]

@czAtlantis I like your pragmatic way of thinking.

[stomko11]

@czAtlantis only light.
When I set up new device in esphome and select ESP8266 board, and copy over same light config, I get following error:
Component output.ledc requires component esp32

[syssi]

This is the ESP8266 equivalent:

output:
  - platform: esp8266_pwm
    pin: D1
    frequency: 1000 Hz
    id: pwm_output

# Example usage in a light
light:
  - platform: monochromatic
    output: pwm_output
    name: "Kitchen Light"

[stomko11]

I will give it a try using Wemos D1 mini.

[syssi]

I've update my YLXD76YL (Yeelight with stock single core ESP32) to ESPHome 2023.2.4 and applied this configuration:

substitutions:
  name: unused-yeelight

esphome:
  name: ${name}

esp32:
  board: esp32doit-devkit-v1
  framework:
    type: esp-idf
    sdkconfig_options:
      CONFIG_FREERTOS_UNICORE: y
      CONFIG_ESP_PHY_CALIBRATION_AND_DATA_STORAGE: n
    advanced:
      ignore_efuse_mac_crc: true

wifi:
  ssid: !secret wifi_ssid_back
  password: !secret wifi_password_back

<<: !include common/api.yaml
<<: !include common/ota.yaml

logger:
  level: INFO
  baud_rate: 0

text_sensor:
  - !include common/text_sensors/esphome_version.yaml

binary_sensor:
  - !include common/binary_sensors/status.yaml

sensor:
  - !include common/sensors/uptime.yaml
  - platform: adc
    pin: GPIO35
    name: "${name} power supply"
    attenuation: 11db

output:
  - platform: ledc
    pin: GPIO19
    id: output_warm
    power_supply: power
  - platform: ledc
    pin: GPIO21
    id: output_cold
    power_supply: power
  - platform: ledc
    pin: GPIO23
    id: output_nightlight
    power_supply: power

power_supply:
  - id: power
    pin: GPIO22
    enable_time: 0s
    keep_on_time: 2s

light:
  - platform: monochromatic
    name: "${name} night light"
    id: night_light
    output: output_nightlight
    restore_mode: RESTORE_DEFAULT_ON
    default_transition_length: 0s
    gamma_correct: 0
    on_turn_on:
      - light.turn_off: ceiling_light
  - platform: cwww
    name: "${name} ceiling light"
    id: ceiling_light
    cold_white: output_cold
    warm_white: output_warm
    cold_white_color_temperature: 6500 K
    warm_white_color_temperature: 2700 K
    constant_brightness: true
    gamma_correct: 0
    restore_mode: RESTORE_DEFAULT_ON
    default_transition_length: 0s
    on_turn_on:
      - light.turn_off: night_light

Please keep in mind this is a device with a power supply GPIO. The delay on AC power on is around 0,5 seconds.

[stomko11]

@syssi What does it mean it has power supply GPIO?

[syssi]

At some yeelights (hardware revisions) the power supply can be controlled individually from the LED driver board. If you drive the LEDs (by PWM) without turning on GPIO22 my lamp won't turn on / you won't see light. ESPHome using the power_supply component cares about turning the power supply on before driving the LEDs.

[stomko11]

@B48D81EFCC just FYI, as advised here and also in other thread, I have replaced my esp32 with esp8266 (wemos D1 mini) - now it is almost instant. I still do struggle with some initial light set, which is instantly replaced by desired color, but this isn't as unpleasant as 1s delay or flicker i experienced when I used GPIO0 (which is pulled high on boot) - big thanks to @syssi for guidance. My config so far is described in the other thread #10 (comment)

[B48D81EFCC]

Hi @stomko11 and thanks a lot.
Interesting that an esp8266 (slower) has better results as a esp32 in this situation.