Porque é que o trabalho em segundo plano do Home Assistant aumenta após uma alteração de configuração ou integração?

O trabalho em segundo plano do Home Assistant pode aumentar após uma alteração de configuração ou integração, porque uma única edição visível pode desencadear várias operações de ciclo de vida ocultas. Uma integração pode ser descarregada e configurada novamente, as entidades podem desaparecer e regressar, as mensagens de descoberta podem ser reproduzidas, as entradas do registo podem mudar, as atualizações de estado podem sobrecarregar o Recorder e os painéis ou automatizações podem reagir ao estado reconstruído.

É por isso que um breve pico de CPU, I/O ou eventos após uma alteração não é automaticamente uma regressão de desempenho. A questão útil é saber se o trabalho é limitado e regressa à linha de base anterior, ou se um ciclo de recarregamento, uma descoberta repetida, uma fonte de estado ruidosa ou uma integração com falhas continua a recriá-lo.

Recarregar uma integração recria mais do que uma ligação

O recarregamento de uma entrada de configuração descarrega uma integração e configura-a novamente. Isto pode fechar sessões de rede, remover entidades do ambiente de execução ativo, voltar a ligar dispositivos, reconstruir coordenadores e republicar o estado inicial.

As orientações atuais do Home Assistant indicam que o recarregamento descarrega brevemente uma integração e torna as respetivas entidades indisponíveis enquanto a configuração é executada novamente. O utilizador vê uma única ação no menu, mas o sistema executa uma transição do ciclo de vida para cada entidade e serviço pertencente a essa entrada.

Meça o pico desde o início do recarregamento até a disponibilidade das entidades e a taxa de eventos estabilizarem. É esperado um pico único; um padrão repetido de descarregamento/configuração indica um problema de configuração ou integração.

Uma lógica de recarregamento incorreta pode multiplicar o trabalho

As integrações personalizadas podem ser recarregadas acidentalmente com mais frequência do que o previsto. Uma única alteração de opções não deve causar dois ciclos de configuração sobrepostos nem criar uma condição de corrida entre um listener e o recarregamento do fluxo de configuração.

O Home Assistant descontinuou um desses padrões em 2026 porque combinar listeners de entradas de configuração com métodos de recarregamento pode recarregar uma integração duas vezes ou criar uma condição de corrida.

Se o trabalho em segundo plano nunca regressar à linha de base após uma alteração, inspecione as integrações personalizadas e os registos para detetar ciclos repetidos de configuração, descarregamento, reconexão ou exceções antes de adicionar CPU. Um ciclo consome recursos, independentemente da velocidade do anfitrião.

A descoberta MQTT pode criar um pico de reconstrução

Os dispositivos geridos por MQTT acrescentam outra fonte de trabalho. Quando o MQTT é recarregado ou volta a ligar-se, as configurações de descoberta e as mensagens de estado podem ser processadas novamente, criando entidades, atualizando a disponibilidade e restaurando estados num período concentrado.

O comportamento MQTT do Home Assistant avisa explicitamente que muitas mensagens de descoberta retidas podem criar uma carga elevada de I/O quando são reproduzidas em conjunto. Isto faz com que o número e o momento das mensagens de descoberta façam parte da carga de trabalho após a alteração.

Não reenvie repetidamente todos os payloads de descoberta com um temporizador curto apenas para garantir a recuperação. Utilize IDs únicos estáveis, comportamento de nascimento/estado, configurações retidas apenas quando adequado e distribua os grandes picos de redescoberta quando o publicador o permitir.

Featured

ZimaCube 2 NAS Pessoal Cloud para Casa

ZimaCube2

$799.00 - $2,499.00

Buy Now

A reconstrução do estado pode alimentar o Recorder e as automatizações dependentes

Cada entidade que regressa pode publicar um estado. Essas atualizações podem ser registadas, apresentadas, consumidas por modelos e avaliadas por automatizações. Assim, o pico de trabalho em segundo plano pode continuar depois de a própria integração indicar que está pronta.

Um caso da comunidade MQTT ilustra o limite da reconstrução do estado: a retenção do payload de descoberta determina se as entidades podem ser recriadas automaticamente depois de o Home Assistant regressar.

Acompanhe a taxa de alterações de estado e as gravações na base de dados juntamente com a CPU. Se a fase de configuração terminar rapidamente, mas o Recorder continuar ocupado, a fase dispendiosa passou da configuração da integração para a persistência e os consumidores a jusante.

Compare o pico de uma alteração com a linha de base em estado estável

A explicação da ZimaSpace sobre picos de carga orientados por eventos versus o estado estável em inatividade fornece a comparação adequada: a procura transitória deve ser medida pelo enfileiramento e pelo tempo de recuperação, não confundida com os requisitos de recursos da linha de base.

Uma alteração saudável no Home Assistant estabiliza-se. As entidades regressam, a taxa de eventos normaliza, o Recorder recupera e a CPU e o armazenamento regressam ao intervalo habitual. Diagnostique a fase que não estabiliza, em vez de tratar cada pico após uma alteração como motivo para atualizar o servidor.