Kabum Smart700 Hack Melhoria no WiFi do Robô

Kabum Smart700 Hack é uma solução de hack afim de melhorar um problema crônico do robô aspirador que após alguns ciclos perde a capacidade de se reconectar com o WiFi a menos que seja reiniciado.

1 Sobre o Smart 700 da Kabum

O robô aspirador Kabum Smart700 se destaca por oferecer recursos avançados como navegação por LiDAR 360°, mapeamento inteligente e funções combinadas de aspiração e passagem de pano por um custo relativamente baixo.

O sistema de passagem de pano e de aspiração são feitos por módulos distintos que são trocados de forma manual pelo usuário, porém o mais comum usado em automações é justamente o de aspiração. No entanto, devido ao problema crônico de reconexão WiFi a automação via Alexa ou outros meios acabam caindo por terra, pois não tem como enviar comando para o robô iniciar o seu ciclo.

2 O problema real de Wi-Fi no Kabum Smart 700

Antes de qualquer tentativa de solução, é fundamental compreender que o problema enfrentado pelo Kabum Smart 700 não está relacionado diretamente à qualidade do sinal Wi-Fi disponível no ambiente, mas sim à forma como o robô lida internamente com eventos de perda de conectividade durante seus ciclos de operação.

2.1 Comportamento observado durante os ciclos de limpeza

Durante o uso contínuo do robô, foi possível observar um padrão de falha muito específico que se repete independentemente da qualidade da rede sem fio disponível.

2.2 O limite crítico de três perdas de conexão

Após três ciclos distintos em que ocorre perda temporária de Wi-Fi, o robô entra em um estado no qual não consegue mais se reconectar à rede, mesmo estando fisicamente próximo ao roteador.

2.3 Por que o robô não se recupera sozinho

Esse comportamento indica claramente um problema de lógica interna, possivelmente relacionado ao gerenciamento de estados do módulo Wi-Fi e não a uma limitação física de alcance ou interferência. Ou seja, por mais que outros métodos sejam aplicados como por exemplo repetidores Wi-Fi, esse problema ainda não será resolvido de fato.

3 Conceito do Kabum Smart700 Hack

Diante da impossibilidade de corrigir o problema de reconexão Wi-Fi por meio de firmware oficial ou ajustes de rede, surgiu a necessidade de uma abordagem alternativa baseada em hardware. O Kabum Smart700 Hack foi concebido para atuar como um mecanismo externo de supervisão, funcionando de forma semelhante a um watchdog de conectividade, capaz de forçar a reinicialização do robô quando um estado inválido é identificado.

A atuação do sistema não ocorre de forma indiscriminada. O estado de reinício é acionado apenas quando duas condições são atendidas simultaneamente: a ausência de conectividade Wi-Fi e o robô estar em processo de retorno ou busca pela base de carregamento. Esse critério garante que a ação corretiva aconteça no momento mais seguro e previsível do ciclo de operação, evitando interferências durante a limpeza ativa.

A solução não modifica o firmware original nem interfere diretamente na lógica interna do robô. Em vez disso, ela observa os sinais elétricos dos próprios LEDs de indicação de estado, que refletem com consistência as diferentes fases de funcionamento do equipamento. A partir dessa leitura, o sistema identifica quando o robô entra em um estado de conectividade inválido e, utilizando os botões físicos como interface de controle, executa a sequência necessária para restaurar o funcionamento normal da automação.

4 Escolha do microcontrolador para realizar o hack

Antes de chegar à solução final do Kabum Smart700 Hack, a primeira abordagem considerada foi utilizar microcontroladores simples da família PIC, amplamente conhecidos, baratos e muito comuns em aplicações embarcadas de pequeno porte, além de serem econômicos eletricamente.

A ideia inicial fazia sentido do ponto de vista teórico: usar um microcontrolador pequeno apenas para observar alguns sinais e acionar botões de forma automatizada. No entanto, conforme o entendimento do comportamento real do robô foi avançando, ficou claro que o problema não era tão trivial quanto parecia inicialmente, e que essa escolha traria limitações importantes que comprometeriam o projeto como um todo.

O comportamento do Kabum Smash 700 não se resume a estados binários simples. Ele envolve sinais analógicos, variações de PWM, flutuações de tensão dependentes do estado de operação e transições suaves entre estados. Isso fez com que a abordagem baseada em microcontroladores muito simples começasse a perder sentido rapidamente, pois o nível de observação necessário era maior do que o inicialmente previsto.

4.1 Limitações de pinos e ADC

Apesar de compactos e eficientes para aplicações simples, os microcontroladores PIC da família 12F apresentam restrições significativas quando aplicados a um cenário que exige múltiplas leituras analógicas simultâneas. Embora o encapsulamento seja de 8 pinos, na prática apenas parte deles pode ser utilizada como GPIO configurável, sendo que alguns pinos possuem funções fixas ou limitações específicas, como pinos apenas de entrada ou compartilhados com funções críticas como o Master Clear.

Além disso, o número reduzido de canais ADC disponíveis se mostrou insuficiente para o que o projeto exigia. No Kabum Smart700 Hack, não era necessário apenas “ler um LED”, mas sim observar o comportamento de vários sinais analógicos ao mesmo tempo, correlacionando essas leituras para identificar estados específicos do robô. Com poucos canais ADC disponíveis, seria necessário multiplexar sinais ou abrir mão de leituras importantes, o que reduziria drasticamente a confiabilidade da lógica de controle.

4.2 Problemas de tensão e gravação

Outro ponto crítico identificado foi relacionado à tensão de operação e ao processo de gravação dos microcontroladores PIC. A família inicialmente considerada exige uma tensão mínima em torno de 4V5 para gravação, enquanto a placa do robô aspirador trabalha majoritariamente com níveis de 3V3. Essa diferença implicaria na necessidade de circuitos adicionais de conversão de nível e isolamento, tanto para proteger a placa do robô quanto para evitar que o gravador injetasse tensão indevida durante o processo de programação.

Além disso, seria necessário implementar proteções extras com diodos e resistores para garantir que o microcontrolador pudesse ser regravado sem a necessidade de removê-lo da placa ou sem risco de curto-circuito. Isso aumentaria significativamente a complexidade do hardware para resolver um problema que, conceitualmente, deveria ser simples. Em vez de facilitar o desenvolvimento, essa abordagem acabaria criando mais pontos de falha e tornando a manutenção do sistema mais trabalhosa.

4.3 A ausência de depuração como fator decisivo

O fator que definitivamente inviabilizou o uso de microcontroladores PIC neste projeto foi a ausência de uma interface de depuração prática e eficiente. Para desenvolver a lógica do Kabum Smart700 Hack, era indispensável acompanhar em tempo real os valores lidos pelo ADC, entender como esses valores variavam conforme o robô mudava de estado e ajustar limiares com precisão. Sem uma interface serial acessível, esse processo se tornaria um exercício de tentativa e erro extremamente demorado e impreciso.

A necessidade de analisar os níveis analógicos identificados pelo microcontrolador, copiar esses valores e aplicá-los diretamente na lógica de decisão tornou o debug um requisito essencial, e não apenas um conforto. Trabalhar sem essa visibilidade significaria ajustar o sistema “no escuro”, algo inviável em um projeto onde pequenas variações elétricas fazem toda a diferença no comportamento final. Foi exatamente essa limitação que deixou claro que, apesar de funcionais em outros contextos, os microcontroladores PIC não eram a ferramenta adequada para resolver o problema específico do Kabum Smash 700.

5 A escolha do ESP32-C3 como controlador auxiliar

A escolha do ESP32-C3 como controlador auxiliar no Kabum Smart700 Hack não foi motivada por conveniência ou preferência pessoal por uma plataforma popular, mas sim por uma necessidade técnica muito clara que surgiu durante as primeiras tentativas de resolver o problema do robô aspirador.

Desde o início, ficou evidente que o problema não poderia ser tratado como uma simples lógica digital, onde sinais são interpretados apenas como ligado ou desligado. O comportamento do Kabum Smash 700 envolve LEDs controlados por PWM, flutuações elétricas dependentes do estado de operação e transições que não são abruptas. Isso exigia um microcontrolador capaz de observar o sistema de forma analógica, contínua e com possibilidade real de depuração em tempo de execução.

Além de tudo isso a placa do ESP32C3 era pequena o suficiente e continha uma circuitaria mínima para funcionamento adequado, contando inclusive con regulador de tensão de 5V para 3V3 que foi essencial para o projeto.

6 Análise do hardware interno do Kabum Smash 700

Para que o Kabum Smart700 Hack funcionasse de forma confiável, foi indispensável compreender como o robô aspirador sinaliza seus estados internos do ponto de vista elétrico. O robô não expõe diretamente informações de estado de forma lógica ou digital acessível, mas utiliza LEDs e botões como única interface de feedback visual e controle manual. Isso exigiu uma análise detalhada da placa interna para identificar onde esses sinais poderiam ser lidos e manipulados de forma segura.

Essa análise revelou que os LEDs do robô não são acionados diretamente pelo microcontrolador principal, mas sim por meio de transistores que fazem o chaveamento da corrente. Isso muda completamente a forma correta de leitura desses sinais, pois medir diretamente no LED pode resultar em leituras imprecisas ou inconsistentes.

6.1 Estrutura dos botões e LEDs

O Kabum Smash 700 possui três botões físicos e conjuntos de LEDs bicolores que indicam estados como ligado, Wi-Fi conectado, carregamento e finalização de ciclo. Esses LEDs trabalham com duas cores principais, verde e vermelho, e utilizam PWM para criar combinações intermediárias, como tons amarelados. Esse comportamento não é apenas estético, mas carrega informação de estado, o que torna sua leitura essencial para o hack.

Cada LED é controlado por um estágio de potência, geralmente um MOSFET, que recebe o sinal do microcontrolador principal do robô. Isso significa que o sinal relevante não está no LED em si, mas no ponto onde o MOSFET é acionado.

6.2 Leitura correta dos sinais PWM

Para obter leituras confiáveis, a medição foi realizada diretamente no dreno dos MOSFETs responsáveis pelo chaveamento dos LEDs. Esse ponto fornece uma representação mais fiel do sinal PWM gerado pelo robô, permitindo que o ADC do ESP32-C3 capture variações de tensão com maior precisão. Essa abordagem foi fundamental para diferenciar estados que, visualmente, podem parecer iguais, mas eletricamente apresentam padrões distintos de PWM.

6.2 Mapeamento dos pontos elétricos do Kabum Smart700

• 1. Alimentação da placa (linha principal):
  • Ponto retirado dos capacitores da fonte do robô;
  • Tensão aproximada: 15V;
  • Utilizado como entrada do regulador externo 15 V → 5 V;
  • Saída de 5V ligada ao VIN do ESP32-C3.
• 2. LED interno da USB:
  • Pisca por ~1 minuto após energização;
  • Nenhuma função útil identificada, precisa de investigação mais aprofundada;
  • Não utilizado na lógica do projeto.
• 3. Botão de Wi-Fi (modo AP):
  • Usado apenas para configuração de rede;
  • Não participa do funcionamento normal;
  • Não utilizado no hack.
• 4. LED Wi-Fi (cor verde):
  • Indica estado do Wi-Fi;
  • Monitorado via ADC;
  • ESP32-C3: A3;
  • Função: detectar Wi-Fi ativo ou inativo.
• 5. Botão Power (liga/desliga):
  • Controla o estado geral da placa;
  • Opera em ≈15–16V;
  • Não pode ser ligado direto ao ESP32;
  • ESP32-C3: saída digital digitalOutPins[0];
  • Acionamento via transistor NPN (BC817).
• 6. LED Power (cor verde):
  • Indica placa energizada / presença no dock;
  • Monitorado via ADC;
  • ESP32-C3: A0.
• 7. LED Charging (cor vermelha):
  • Indica transições internas e desligamento;
  • Monitorado via ADC;
  • ESP32-C3: A2.
• 8. LED Charging (cor verde):
  • Apresenta oscilação PWM durante carga;
  • Sinal principal para detectar carregamento;
  • Monitorado via ADC;
  • ESP32-C3: A1.
• 9. Botão de retorno ao carregador:
  • Simula o comando físico de retorno à base;
  • ESP32-C3: saída digital digitalOutPins[1];
  • Ligação direta com resistor de 100 Ω em série.

7 Definição dos sinais essenciais para o controle

Embora o robô possua diversos LEDs e botões, nem todos são necessários para implementar a lógica do Kabum Smart700 Hack. Um dos passos mais importantes do projeto foi reduzir a complexidade, selecionando apenas os sinais que realmente carregam informações críticas para a tomada de decisão.

7.1 LEDs utilizados no Kabum Smart700 Hack

A solução final utiliza apenas os LEDs relacionados ao botão de power (verde), ao status de Wi-Fi (verde) e ao carregamento da bateria (verde e vermelho). Esses LEDs, quando analisados em conjunto, fornecem informações suficientes para determinar se o robô está limpando, se finalizou o ciclo, se está tentando retornar à base ou se já está em processo de carregamento.

A leitura via ADC permite interpretar esses sinais de forma muito mais precisa do que uma simples leitura digital. A intensidade do PWM, sua variação ao longo do tempo e a combinação entre cores fornecem uma assinatura elétrica única para cada estado do robô, possibilitando uma lógica de controle confiável.

7.3 Acionamento dos botões

Para fazer o acionamento dos botões são necessários apenas duas saídas digitais e um resistor de 100ohms para evitar problemas e conseguir também seja possível acionar manualmente. No entanto o botão do meio (power) não pode ser acionado apenas com essa configuração, é necessário um transistor para fazer o chaveamento para GND, pois ele trabalha com 16V e não na mesma tensão que os demais botões.

O que é importante entender é que esse botão controla diretamente toda alimentação da placa, então se puxar uns 5V por isso a tensão desse botão é tão alta se comparada com outros pontos da placa. O transistor entra como uma forma de proteger o microcontrolador e ao mesmo tempo conseguir acionar o botão, para isso usei um BC817 que é um transistor NPN SMD e soldei ele ao lado do botão e depois reforcei mecanicamente com cola quente.

8 Alimentação independente e o problema do auto-kill

No tópico anterior foi comentado que o botão alimenta todo circuito geral e isso foi um problema chatinho de se resolver, pois inicialmente eu havia colocado um resistor de 100ohms também para acionar o botão de power mas a placa entrava em um estado comportamento muito estranho e o acionamento só era possível em condições especificas e a manual não funcionava.

Porém outro erro cometido é que os 5V que eu estava pegando da placa era bem próximo do LED do power, em um capacitor e por isso qualquer acionamento de desligamento dava uma condição muito estranha visto que o próprio ESP32C3 aparentemente morria também, então para resolver isso foi adicionado um regulador de tensão linear externo 78M05.

A alimentação do chip foi feita com o barramento de 16V que já foi mencionado anteriormente, optei por soldar exatamente em um capacitor cerâmico SMD por conta da sua superfície de contato ser melhor que os eletrolíticos. A saída do regulador 78M05 foi conectado no VIN da placa do ESP32C3 e dessa forma o ESP32 fica ligado direto, veja como ficou a montagem:

8.1 O ESP32C3 não vai consumir muito?

Essa era uma pergunta que me fiz des do inicio, visto que a ideia de usar um PIC era justamente para também economizar energia, mas depois de analizar bem o cenário de funcionamento do robô, isso é um tipo de preocupação grande demais para o real cenário de funcionamento do robô, pois ela passa boa parte do tempo no carregador então isso não seria algo que de fato iria destruir a bateria do robô, mas de fato se torna um consumo a mais.

9 A lógica do Kabum Smart700 Hack

A lógica do Kabum Smart700 Hack foi desenhada para resolver um problema bem específico sem “brigar” com o funcionamento normal do robô. O objetivo nunca foi controlar o robô o tempo todo, nem criar um modo alternativo de operação. A ideia foi agir como um supervisor externo que observa sinais já existentes (LEDs e botões), entende em que fase o robô está e só interfere quando o robô entra naquele estado anômalo onde o Wi-Fi não volta.

O ponto mais importante é que esse tipo de problema não deve ser tratado como “Wi-Fi caiu, então reinicia”. Queda de Wi-Fi durante a limpeza pode ser normal, pode ser zona de sombra, pode ser interferência momentânea. Se você reinicia toda vez que o Wi-Fi oscila, você cria um robô instável, que reinicia no meio do trabalho e vira um gerador de frustração. Por isso a lógica foi construída com um princípio simples: reiniciar apenas quando existe forte evidência de que o ciclo terminou e o robô está tentando voltar para a base, mas o Wi-Fi permanece inativo.

9.1 Por que o reset acontece apenas quando o robô está procurando a base

A escolha de “procurando a base” como condição obrigatória não é por conveniência, é por segurança e previsibilidade. É nesse momento que o robô está mudando de modo (saindo do ciclo ativo e entrando no retorno), e isso tem três vantagens práticas:

1. Você não interrompe a limpeza em andamento.
2. Você pega o robô numa fase em que ele naturalmente vai ficar “andando” até achar a base, então um reinício tende a ser menos perceptível.
3. O comportamento de LEDs nessa fase é mais característico (muito mais fácil de detectar sem ambiguidade).

Na prática, essa decisão transforma o projeto num “WDT contextual”: não é um watchdog do sinal Wi-Fi puro, é um watchdog do Wi-Fi dentro de um contexto operacional específico.

9.2 Estados que precisam existir antes de qualquer decisão

Para tomar uma decisão confiável, você precisa transformar leituras analógicas (PWM, variações e ruído) em estados binários e coerentes. A biblioteca Smart700 faz exatamente isso ao manter quatro estados internos:

• WiFi() → Wi-Fi ativo/inativo (interpretado pelo LED do Wi-Fi).
• searchingForCharger() → robô em busca de base (padrão elétrico do estado de retorno).
• charging() → robô efetivamente carregando (detecção por oscilação com presença no dock).
• shutdown() → placa desligada (para evitar agir quando o robô está realmente off).

O seu código principal não fica “adivinhando” nada. Ele só toma decisões com base nesses quatro sinais já estabilizados.

9.3 Por que criar uma biblioteca para controlar o robô

A decisão de criar uma biblioteca (Smart700.h) não foi estética, foi arquitetura. Ela separa o projeto em duas camadas bem claras:

1. Camada de interpretação elétrica: ler ADC, filtrar, detectar padrões, estabilizar estados.
2. Camada de política/decisão: quando reiniciar, quando mandar voltar à base, quando bloquear repetição.

Se você mistura tudo no .ino, três coisas acontecem inevitavelmente: o loop vira um “monstro”, você perde rastreabilidade do que está falhando e cada ajuste de limiar vira risco de quebrar outras condições. Com a biblioteca, qualquer ajuste de thresholds e lógica de detecção fica centralizado e testável via debug.

Além disso, a biblioteca encapsula o comportamento como um “driver” do robô: ela oferece uma API simples (tick(), restart(), goToCharger(), getters de estado), e o arquivo principal só orquestra quando usar isso.

10 Explicando o código por partes e o motivo de cada decisão

Antes de mais nada, é importante que você tenha acesso todo código e projeto para isso basta clicar aqui para ter acesso ao repositório do GitHub

10.1 O loop principal e o bloqueio awaitingCharging

O trecho mais importante do .ino é este:

static bool awaitingCharging = false;

if (!smart700.shutdown() &&
    smart700.searchingForCharger() &&
    !smart700.WiFi() &&
    !smart700.charging() &&
    !awaitingCharging) {

  smart700.restart();
  awaitingCharging = true;

} else if ((awaitingCharging && smart700.charging()) || smart700.shutdown()) {
  awaitingCharging = false;
}

smart700.tick();
delay(1000);

Essa condição define exatamente a filosofia do projeto:

• !shutdown() impede ações quando a placa do robô está realmente desligada.
• searchingForCharger() garante que o reset só acontece no momento correto do ciclo (retorno).
• !WiFi() confirma o sintoma real (Wi-Fi continua inativo no momento crítico).
• !charging() evita reset quando ele já chegou na base.
• !awaitingCharging impede “loop de resets” caso o padrão de LEDs continue enganando por alguns segundos.

O awaitingCharging funciona como um travamento lógico temporário (flag): depois de um reset, é assumido que o robô precisa de um tempo para estabilizar e chegar ao carregador. Durante esse período, o sistema não pode “se assustar” com leituras transitórias e reiniciar de novo.

O desbloqueio foi pensado para ocorrer quando:

• ele finalmente entra em charging() (missão concluída), ou
• o robô desligou (não há por que insistir).

10.2 O papel do tick() e por que ele vem depois da decisão

O tick() é o ponto importante é que renova os estados internos a cada ciclo a cada um segundo, assim todas as funções da biblioteca trabalham com base nesse tempo, com exceção das de reset e de ida para a base de carregamento.

10.3 Como cada detector funciona dentro da biblioteca

10.3.1 Detecção de Wi-Fi e por que existe “zona intermediária”

if (a3 < 300) zone = 0;
else if (a3 > 2000) zone = 1;
else zone = -1;

Aqui foi criado uma zona “indefinida” para ignorar leituras que caem numa região ambígua. Isso reduz falsos positivos, principalmente quando o PWM está variando ou quando há ruído do sistema.

Em seguida, você exigiu estabilidade mínima:

if (zone == lastZone && zone != -1) stableCount++;
else { stableCount = 1; lastZone = zone; }

if (stableCount >= 2) { ... }

Isso impede troca de estado por um único pico de leitura. Na prática, você está dizendo: “só acredito que mudou se eu enxergar o mesmo comportamento por pelo menos dois ciclos válidos”.

10.3.2 Detecção de carregamento por oscilação, não por nível fixo

A detecção de carregamento foi a parte mais inteligente para robustez, porque carregamento real nem sempre é “um LED aceso”; muitas vezes é uma animação PWM e o comportamento elétrico é mais confiável quando você entende o padrão.

A lógica é:

• primeiro, exigir presença no dock (a0High). Sem isso, nada de carregamento.
• depois, contar alternâncias de a1 entre alto e baixo.
• após 4 oscilações válidas, considerar charging = true.

if (!a0High) { _charging = false; oscillationCount = 0; chargeState = UNKNOWN; return; }

if (oscillationCount >= 4) _charging = true;

O motivo disso funcionar melhor do que “a1 > X” é que o padrão de oscilação é bem difícil de existir por acaso. Você está detectando comportamento, não apenas valor.

10.3.3 Detecção de placa desligada com “assinatura” elétrica

bool match = (a2 > 2000) && between(a3,0,900) && between(a1,0,900) && between(a0,0,900);

if (match) shutdownStableCount++;
else shutdownStableCount = 0;

_shutdown = shutdownStableCount >= 3;

Aqui você fez duas escolhas importantes:

1. Usar uma combinação de canais, não um único pino. Isso reduz confusão entre estados.
2. Exigir 3 ciclos consecutivos. Isso evita interpretar transições rápidas como “off”.

Essa condição existe principalmente para segurança: se o robô está desligado, acionar botões pode ser inútil ou até piorar comportamento de alimentação.

10.3.4 Detecção de “procurando carregador” e por que tem estabilidade

bool match = (a1 < 500) && (a2 < 500);
_searchingForCharger = searchStableCount >= 3;

Esse detector representa exatamente o “gatilho de contexto” do sistema. Ele precisa ser simples o suficiente para ser confiável e estável. Ao exigir 3 ciclos, você diminui chance de entrar no estado por ruído momentâneo.

10.4 A sequência de reset e o motivo dos tempos

A função restart() faz uma sequência temporizada que simula o comportamento real de um usuário segurando e soltando o botão, com tempos suficientes para o robô:

1. reconhecer o comando de power
2. desligar completamente
3. reiniciar e estabilizar
4. receber o comando de “voltar pro carregador”

digitalWrite(digitalOutPins[0], 1);
delay(4000);
digitalWrite(digitalOutPins[0], 0);
delay(5000);
digitalWrite(digitalOutPins[0], 1);
delay(2000);
digitalWrite(digitalOutPins[0], 0);
delay(15000);

goToCharger();

Mesmo parecendo “muito delay”, aqui faz sentido porque o sistema não precisa ser assíncrono: ele é um supervisor de estado lento. Esses tempos também servem para garantir que não dispare comandos enquanto o robô ainda está bootando e sem responder a eventos.

Se um dia você quiser refinar, a evolução natural é substituir delays longos por espera baseada em estado (ex.: “aguardar até detectar LED power verde estável”). Mas para um primeiro sistema robusto, temporização é uma escolha pragmática e previsível.

10.4 Por que usar Watchdog do ESP32-C3 nesse projeto

O watchdog (esp_task_wdt) não está ali para “reiniciar o robô”. Ele protege o próprio supervisor. Como o uso dos delays grandes, existe sempre o risco de travar por algum motivo (bug, ruído, condição inesperada). Com o WDT ativo, dessa forma é garantido que, no pior caso, o ESP32-C3 reinicia e volta a monitorar em vez de ficar congelado.

esp_task_wdt_init(300, true);
esp_task_wdt_add(NULL);
...
esp_task_wdt_reset();

O valor 300s é coerente porque mão se trata de um sistema de tempo real. Então podemos tolerar estados longos, mas não quer que um travamento permanente deixe o robô “sem supervisor”.

11 O problema foi resolvido?

Desde quando deixei o robô aspirador com essa modificação implementada até a finalização deste post se passaram 7 dias e o robô funcionou perfeitamente todos os dias em sua rotina padrão e esse circuito manteve sempre a conectividade WiFi, o único ponto de desvantagem é que notei que após o reinício da placa o robô demora um pouco mais para encontrar a base de carregamento, mas mesmo assim acaba achando.

11.1 Demonstração de funcionamento

O vídeo a seguir é um trecho de um vídeo mais completo que fiz durante todo o processo de hacking, falando dos erros cometidos e etc, mas só esse trecho a seguir é o suficiente para compreender o funcionamento real do sistema.