Problema de reboot no ESP8266 – Suspeito sobrecarga do efeito Rainbow em WS2812b

Olá, pessoal!

Estou enfrentando um problema com alguns ESP8266 (D1 Mini) que uso para controlar LEDs WS2812b via ESPHome. Em determinados dispositivos, após alguns minutos de funcionamento, eles reiniciam do nada.

O que já foi testado:

  • As fontes de alimentação são robustas (5V, 30A) e funcionam bem com outros dispositivos.
  • Outros ESPs com configurações semelhantes (mesma versão do ESPHome) não apresentam o problema, mas nestes dois dispositivos específicos uso o efeito Rainbow (entre outros efeitos) – e suspeito que ele esteja sobrecarregando a CPU do ESP8266.
  • Ativei o modo debug e capturei o momento do reboot. A seguir, coloco um trecho relevante do log.

Trecho relevante do log:

[13:45:57][D][sensor:093]: 'Heap Free': Sending state 18584.00000 B with 0 decimals of accuracy
...
[13:46:02][D][sensor:093]: 'Heap Free': Sending state 18584.00000 B with 0 decimals of accuracy
WARNING painel-tv-suite @ 192.168.20.42: Connection error occurred: [Errno 104] Connection reset by peer
INFO Processing unexpected disconnect from ESPHome API for painel-tv-suite @ 192.168.20.42
WARNING Disconnected from API
...
Reset: Hardware Watchdog
Fatal exception:4 flag:1 (Hardware Watchdog) epc1:0x401037f9 epc2:0x00000000 epc3:0x00000000

Percebe-se que o dispositivo está reiniciando por Hardware Watchdog – isso geralmente acontece quando o loop principal fica bloqueado por muito tempo, sem dar tempo ao watchdog de ser “alimentado”. Minha suspeita é que o efeito Rainbow esteja consumindo muita CPU (por forçar o cálculo e atualização dos LEDs em modo bit‑bang) e, quando muitos LEDs estão ativos, o processador não consegue atender ao watchdog.

Código do ESPHome da suíte (sem informações pessoais):

substitutions:
  project_name: "painel_tv_suite"
  friendly_name: "Painel TV Suíte"

esphome:
  name: ${project_name}
  friendly_name: "${friendly_name}"
  platform: ESP8266
  board: d1_mini

wifi:
  ssid: !secret wifi_ssid
  password: !secret wifi_password
  ap:
    ssid: "${friendly_name} Fallback Hotspot"
    password: "********"

logger:
api:
ota:
  - platform: esphome
    password: "********"

captive_portal:
web_server:

light:
  - platform: neopixelbus
    variant: WS2812
    pin: D1
    num_leds: 69
    type: GRB
    id: led_sofa
    name: "Led do sofá"
    icon: hass:led-strip-variant
    effects:
      - random:
      - addressable_rainbow:
          name: "Rainbow"
          speed: 3
          width: 69
      - addressable_rainbow:
          name: "Rainbow Fast"
          speed: 10
          width: 69
      - addressable_rainbow:
          name: "Rainbow Ultra"
          speed: 30
          width: 69
      - addressable_color_wipe:
      - addressable_scan:
          name: "Scan"
          move_interval: 10ms
      - addressable_twinkle:
      - addressable_random_twinkle:
      - addressable_fireworks:
      - random:
          name: "RGB transition slow"
          transition_length: 5s
          update_interval: 30s
      - random:
          name: "RGB transition fast"
          transition_length: 5s
          update_interval: 10s

  - platform: neopixelbus
    variant: WS2812
    pin: D2
    num_leds: 71
    type: GRB
    id: led_aereo_inferior
    name: "Led aereo inferior"
    icon: hass:led-strip-variant
    effects:
      - random:
      - addressable_rainbow:
          name: "Rainbow"
          speed: 3
          width: 71
      - addressable_rainbow:
          name: "Rainbow Fast"
          speed: 10
          width: 71
      - addressable_rainbow:
          name: "Rainbow Ultra"
          speed: 30
          width: 71
      - addressable_color_wipe:
      - addressable_scan:
          name: "Scan"
          move_interval: 10ms
      - addressable_twinkle:
      - addressable_random_twinkle:
      - addressable_fireworks:
      - random:
          name: "RGB transition slow"
          transition_length: 5s
          update_interval: 30s
      - random:
          name: "RGB transition fast"
          transition_length: 5s
          update_interval: 10s

  - platform: neopixelbus
    variant: WS2812
    pin: D4
    num_leds: 71
    type: GRB
    id: led_aereo_superior
    name: "Led aereo superior"
    icon: hass:led-strip-variant
    effects:
      - random:
      - addressable_rainbow:
          name: "Rainbow"
          speed: 3
          width: 71
      - addressable_rainbow:
          name: "Rainbow Fast"
          speed: 10
          width: 71
      - addressable_rainbow:
          name: "Rainbow Ultra"
          speed: 30
          width: 71
      - addressable_color_wipe:
      - addressable_scan:
          name: "Scan"
          move_interval: 10ms
      - addressable_twinkle:
      - addressable_random_twinkle:
      - addressable_fireworks:
      - random:
          name: "RGB transition slow"
          transition_length: 5s
          update_interval: 30s
      - random:
          name: "RGB transition fast"
          transition_length: 5s
          update_interval: 10s

  - platform: partition
    name: "Led corredor inferior"
    icon: hass:led-strip-variant
    segments:
      - id: led_corredor
        from: 0
        to: 18
    effects:
      - random:
      - addressable_rainbow:
          name: "Rainbow"
          speed: 3
          width: 19
      - addressable_rainbow:
          name: "Rainbow Fast"
          speed: 10
          width: 19
      - addressable_rainbow:
          name: "Rainbow Ultra"
          speed: 30
          width: 19
      - addressable_color_wipe:
      - addressable_scan:
          name: "Scan"
          move_interval: 10ms
      - addressable_twinkle:
      - addressable_random_twinkle:
      - addressable_fireworks:
      - random:
          name: "RGB transition slow"
          transition_length: 5s
          update_interval: 30s
      - random:
          name: "RGB transition fast"
          transition_length: 5s
          update_interval: 10s

  - platform: partition
    name: "Led corredor superior"
    icon: hass:led-strip-variant
    segments:
      - id: led_corredor
        from: 19
        to: 37
    effects:
      - random:
      - addressable_rainbow:
          name: "Rainbow"
          speed: 3
          width: 19
      - addressable_rainbow:
          name: "Rainbow Fast"
          speed: 10
          width: 19
      - addressable_rainbow:
          name: "Rainbow Ultra"
          speed: 30
          width: 19
      - addressable_color_wipe:
      - addressable_scan:
          name: "Scan"
          move_interval: 10ms
      - addressable_twinkle:
      - addressable_random_twinkle:
      - addressable_fireworks:
      - random:
          name: "RGB transition slow"
          transition_length: 5s
          update_interval: 30s
      - random:
          name: "RGB transition fast"
          transition_length: 5s
          update_interval: 10s

  - platform: neopixelbus
    variant: WS2812
    pin: D7
    num_leds: 38
    internal: true
    type: GRB
    id: led_corredor
    name: "Led corredor"
    icon: hass:led-strip-variant

Contexto e Problema:
Após analisar os logs, percebi que o dispositivo reinicia (reset por Hardware Watchdog) logo após os LEDs ficarem em funcionamento. O log indica:

  • Antes do reboot, o ESP8266 apresenta mensagens de “Heap Free” e “Loop Time” normais.
  • Por volta de 13:46:02, ocorre a desconexão da API e uma mensagem de reset por Hardware Watchdog, seguida de “Fatal exception:4 flag:1 (Hardware Watchdog)”.

Minha hipótese é que o efeito Rainbow (um dos efeitos addressable_rainbow) pode estar exigindo processamento demais do ESP8266 quando aplicado a uma fita com muitos LEDs, ocasionando bloqueio do loop principal e, consequentemente, acionamento do watchdog.

Estou buscando alternativas, como implementar o efeito Rainbow via lambda ou outras otimizações, para reduzir o uso da CPU e evitar esses reinícios.

Gostaria de saber se alguém já passou por situação semelhante ou tem sugestões de como otimizar o efeito para que o ESP8266 não fique sobrecarregado.

Neste momento não posso mudar para ESP32, preciso utilizar os 8266.

Agradeço desde já a ajuda e sugestões!

desabilitar o captive_portal e o webserver não vai te salvar um pouquinho de CPU?

1 Like

Desabilita o log tbm:

logger:
  level: WARN
  baud_rate: 0

1 Like

Bom dia pessoal! Agradeço as respostas. O problema estava no uso dos pinos errados, como bit bang, eu mudei para apenas usar um deste e os outros dois no GPIO1 e GPIO2 (UART), resolvendo as reinicializações. Conforme o Walber falou, ele de fato começou a piscar um pouco no pino TX, era justamente o logger atualizando, colocando baud_rate 0 resolveu o problema. Obrigado!