Antiburn function

[nagyrobi]

Antiburn function

[clydebarrow]

            on_...:
              then:
                - lvgl.pause:
                    show_snow: true

Will fill the screen with random pixels until LVGL is unpaused.
Would probably want to also dim the backlight.

[clydebarrow]

to just show the snow for a certain amount of time and white out after that

Just use the same mechanism as used to enter the paused state, e.g. in my L8:

time:
  - platform: sntp
    id: esptime
    timezone: Australia/Sydney
    on_time:
      - seconds: 0
        minutes: 30
        hours: 0
        then:
          - lvgl.pause:
              show_snow: true
    on_time:
      - seconds: 0
        minutes: 30
        hours: 2
        then:
          - lvgl.resume:

Combined with resume on touch, just in case I'm having a post-midnight snack:

touchscreen:
  - platform: ....
    id: my_touchscreen
    on_release:
      then:
        - if:
            condition: lvgl.is_paused
            then:
              - lvgl.resume:

CPU time etc used is not significant - it only updates one row of pixels per loop() interval, so likely running at 5% utilisation.

[nielsnl68]

This is very easy to do now:

esphome:
  on_boot:
    priority: 10
    then:
      - script.execute: my_script
  
touchscreen:
  - platform: ...
    ...
    on_touch:
      then:
        - script.execute: my_script

  # Define a PWM output on the ESP32
output:
  - platform: ledc
    pin: 16
    id: gpio_17_backlight_pwm
  
# Define a monochromatic, dimmable light for the backlight
light:
  - platform: monochromatic
    output: gpio_17_backlight_pwm
    name: Backlight
    id: back_light
    restore_mode: ALWAYS_OFF

script:
  - id: my_script
    mode: restart
    then:
      - light.turn_on: back_light
      - lvgl.resume
      - delay: 10min
      - light.turn_off: back_light
      - lvgl.pause

[nagyrobi]

How does that draw random RGB pixels?

[nagyrobi]

Not sure how complicated would be to extend this with something like

show_snow: 
  time: 600s
  end_color: 0xFFFFFF

to just show the snow for a certain amount of time and white out after that. A daily cycle of 10-15 minutes of snow is enough to train the pixels, not sure if this causes some CPU/BUS stress, power increase or not, might be worth having an option to stop after a while.

[nielsnl68]

I think that the option to turn off the screen after some small time prevent the screen from burning in, is it not?

[nagyrobi]

I think that the option to turn off the screen after some small time prevent the screen from burning in, is it not?

Not. For these panels, when you "turn off" the screen, in reality you just turn off the backlight. The pixels in the LCD panel layer are still showing the picture, you just don't see it because it's not being lit. Burn in happens at pixel level, it's independent of backlight (more influenced by ambient temperature).

Read
HASwitchPlate/openHASP#134 (comment) for more details.

[nagyrobi]

Inspected pixels a bit closer:

It looks like a randomization happens among 256 colors.

From pixel traning point of view, given that each pixel is composed of a Red, a Green and a Blue physical layer it would be more effective if we would randomize only these colors. Electronically that would mean that for example for Red pixel, Red layer is fully open, Green and blue are fully closed. Physically that would be more intense, as each pixel of each layer has to go in fully open and fully closed state at random times. Any other color means just partial opened levels of all the layers. Of course plain R, G, B is likely to occur statistically with 256 color randomization, but it's less effective.

I'd suggest to just randomize the pixels between plain R, G and B (or just R,G,B,White,Black).

[clydebarrow]

It looks like a randomization happens among 256 colors.

65536 colours actually.

Just white and black would drive all pixels from one extreme to another. But it wouldn't look as nice :-) And generating random numbers is easier than generating specific colours.

There is very little information I can find on what really happens with LCD burn-in, and what's the best strategy to avoid it - much of the discussion is somewhere between theory and speculation, so I don't think it's worth spending more time on for an unquantifiable benefit.

[nagyrobi]

somewhere between theory and speculation

I guess you didn't run into cases like this (see photos):
HASwitchPlate/openHASP#311

Not talking about oleds, which are very prone to burn-in (but at least for them indeed it's enough to just black out/turn off the screen)

[clydebarrow]

guess you didn't run into cases like this (see photos):

Just really reinforces my observations so far - the problem exists, in some LCDs at least, but nobody has any hard data on how to deal with it.

antiburn doesn't make any notisable difference. Even after repeated runs.

Only time seems to have a positive effect on this ghosting effect.
Left my screen on as test with uniform background (#008080) and after some 30 minutes ghosting has faded to be almost invisible.