Describe the bug
With brightness cycled to off (short button press to the 0.0 level), the LEDs still blink faintly about every 10 seconds — noticeable in a dark room. When off, the light should stay completely dark.
Suspected cause (from reading the firmware)
The 10-second cadence exactly matches the Zigbee + BLE sensor push in main.c (zigbee_update_sensors() / ble_bthome_update() every 10 s).
led_task in led.c rewrites an identical frame to the WS2812-type pixels (IN-PI15) every 20 ms, so the data line is permanently active. When the radio TX burst coincides with one of those frames (current spike on the 3.3 V rail; DFS is also enabled via esp_pm_configure in main.c), the frame gets corrupted and the pixels briefly latch a random color before the next 20 ms refresh clears it — a visible blink even at intensity 0.
Possibly related: #54 (brightness appearing to change on its own could be the same corrupted-frame latching).
Hardware / firmware
- AirCube on USB power
- Firmware built from current
master behavior (LED task logic unchanged since v1.5.x)
Proposed fix
Only write to the strip when the frame actually changes, keep a brief repeat window after changes so a corrupted transition write self-heals, refresh slowly (1 Hz) while lit as a safety net, and keep the data line fully idle once settled at off. PR incoming from my fork.
🤖 Generated with Claude Code
Describe the bug
With brightness cycled to off (short button press to the 0.0 level), the LEDs still blink faintly about every 10 seconds — noticeable in a dark room. When off, the light should stay completely dark.
Suspected cause (from reading the firmware)
The 10-second cadence exactly matches the Zigbee + BLE sensor push in
main.c(zigbee_update_sensors()/ble_bthome_update()every 10 s).led_taskinled.crewrites an identical frame to the WS2812-type pixels (IN-PI15) every 20 ms, so the data line is permanently active. When the radio TX burst coincides with one of those frames (current spike on the 3.3 V rail; DFS is also enabled viaesp_pm_configureinmain.c), the frame gets corrupted and the pixels briefly latch a random color before the next 20 ms refresh clears it — a visible blink even at intensity 0.Possibly related: #54 (brightness appearing to change on its own could be the same corrupted-frame latching).
Hardware / firmware
masterbehavior (LED task logic unchanged since v1.5.x)Proposed fix
Only write to the strip when the frame actually changes, keep a brief repeat window after changes so a corrupted transition write self-heals, refresh slowly (1 Hz) while lit as a safety net, and keep the data line fully idle once settled at off. PR incoming from my fork.
🤖 Generated with Claude Code