When changing light intensity on an LED light using PWM (Either internal LEDC or external chip such as SX1509) a routine is run that uses the "default_transition_length:" value for that LED light to make this transition in LED intensity fade smoothly up and down.
When another process requires time (reading temperature sensor, updating I2C/SPI display, etc.) hiccups can be introduced into this fading. When this LED is a 5m LED strip the introduced choppiness/hiccupping is very visible and distracting.
Once fading is done LEDC itself works fine, it's purely the transitions that suffer from this issue.
Once interrupting processes try to run at the same time gaps and jumps are visible in the logs of the fade routine if you make it show each step in the logs like this for instance:
- platform: template
name: "LED5 readout"
id: LED5_value
internal: true
update_interval: 16ms
filters:
delta: 0.8
lambda: |-
if (id(LED5).current_values.is_on()) {
return (int(id(LED5).current_values.get_brightness() * 100));
}
else {
return 0;
}
p.s. This method has since been refined in a more efficient display lamba but it has no influence on the issue.
Additional information
On a prior design (My QuinLED-An-Penta) I had to switch from the AHT21 temperature sensor to the SHT31. It seems the AHT21 integration caused these hiccups while the SHT31 integration does not! But this makes it very hard to add features to a board design when an additional feature can influence the primary function of dimming LED lights.
In my opinion it would be better if this "crucial" or "primary" function (fading up/down) can't be interrupted by a secondary non-critical time related function (such as reading a temperature sensor, that can wait a few seconds while the other task is running).
Talked on Discord to @kbx81 about this issue and he verified my findings. His comment was "to use a timer interrupt to refresh LED intensities during fades/transitions".
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
The problem
When changing light intensity on an LED light using PWM (Either internal LEDC or external chip such as SX1509) a routine is run that uses the "default_transition_length:" value for that LED light to make this transition in LED intensity fade smoothly up and down.
When another process requires time (reading temperature sensor, updating I2C/SPI display, etc.) hiccups can be introduced into this fading. When this LED is a 5m LED strip the introduced choppiness/hiccupping is very visible and distracting.
Once fading is done LEDC itself works fine, it's purely the transitions that suffer from this issue.
Which version of ESPHome has the issue?
All up to 2022.5.1 at least
What type of installation are you using?
Home Assistant Add-on
Which version of Home Assistant has the issue?
Any
What platform are you using?
ESP32
Board
QuinLED-An-Quad, QuinLED-An-Deca, QuinLED-An-Penta
Component causing the issue
LEDc PWM fade transition routine
Example YAML snippet
Anything in the logs that might be useful for us?
Additional information
On a prior design (My QuinLED-An-Penta) I had to switch from the AHT21 temperature sensor to the SHT31. It seems the AHT21 integration caused these hiccups while the SHT31 integration does not! But this makes it very hard to add features to a board design when an additional feature can influence the primary function of dimming LED lights.
In my opinion it would be better if this "crucial" or "primary" function (fading up/down) can't be interrupted by a secondary non-critical time related function (such as reading a temperature sensor, that can wait a few seconds while the other task is running).
Talked on Discord to @kbx81 about this issue and he verified my findings. His comment was "to use a timer interrupt to refresh LED intensities during fades/transitions".
Prior I opened this as a feature request: https://github.com/esphome/feature-requests/issues/1900