O Home Assistant não precisa de um número de concorrência para toda a casa; cada automação precisa de sobreposição suficiente para a sua frequência de acionamento e duração das ações, sem violar a ordem.
Dez divisões e duzentas entidades não implicam dez ou duzentas execuções de automações em paralelo. A quantidade útil é específica de cada fluxo de trabalho: com que frequência pode ser acionado, quanto tempo uma execução permanece ativa, se as execuções posteriores substituem as anteriores e quanto trabalho paralelo o dispositivo ou serviço de destino consegue aceitar. Comece com um quando a ordem for importante e adicione concorrência apenas quando o trabalho realmente sobreposto for independente e sensível a prazos.
Estime a Sobreposição Necessária a Partir da Frequência de Acionamento e da Duração da Execução
Uma primeira estimativa de planeamento é a taxa de chegada multiplicada pela duração média ativa. Se uma automação for acionada uma vez a cada dez segundos e normalmente terminar num segundo, a sua necessidade típica de sobreposição é muito inferior a um. Se os picos produzirem cinco acionamentos por segundo enquanto cada execução aguarda dois segundos, a necessidade simultânea pode aproximar-se de dez, a menos que o fluxo agregue, reinicie ou coloque esses eventos numa fila.
A discussão da comunidade sobre os modos de automação do Home Assistant mostra por que motivo a concorrência é uma escolha de comportamento, e não uma fórmula baseada no número de dispositivos. Único, reinício, em fila e paralelo representam respostas diferentes à pergunta «o que deve acontecer quando chega outro acionamento antes de esta execução terminar?»
Use a fórmula apenas como estimativa de carga de trabalho, não como recomendação de configuração. A ocorrência de picos, esperas prolongadas, confirmações dos dispositivos e tempos-limite de falha podem fazer com que as execuções mais lentas durem muito mais do que a média. Registe também a duração do percentil 95 ou a pior duração normal, porque a concorrência é consumida pelas execuções que permanecem ativas durante mais tempo.
A Ordem e a Idempotência Impõem um Limite Mais Rígido do que a CPU
Algumas ações para toda a casa são logicamente inseguras em paralelo, mesmo quando o servidor tem CPU de sobra. Estores motorizados, fechaduras, alterações graduais do volume multimédia, válvulas de rega e scripts com estado podem receber ações contraditórias se várias execuções independentes se sobrepuserem. Nestes casos, o comportamento em fila ou de reinício pode ser mais correto do que a execução paralela.
Uma explicação prática das automações do Home Assistant descreve a cadeia acionador-condição-ação como um modelo de controlo determinístico. A concorrência deve preservar esse determinismo, em vez de maximizar o número de cópias que o anfitrião consegue tecnicamente agendar.
Pergunte se duas execuções podem ser realizadas por qualquer ordem e ainda produzir o mesmo resultado seguro. Se não puderem, não aumente o paralelismo para corrigir a latência; encurte a execução, agregue as entradas ou serialize no destino. Mais concorrência não significa maior débito quando o próprio dispositivo de destino aceita apenas um comando relevante de cada vez.
Os Serviços a Jusante Definem o Limite Útil
Mesmo as execuções independentes acabam por convergir para recursos finitos: um coordenador Zigbee, um broker MQTT, uma API de fornecedor, um serviço de notificações, uma base de dados, um canal Wi-Fi ou um dispositivo físico. Uma análise independente da concorrência no Home Assistant observa que as instâncias das automações são tarefas e que as ações de serviço podem ficar suspensas devido a E/S externa; por isso, agendar mais execuções não faz com que o sistema a jusante as processe mais depressa. As execuções adicionais podem apenas criar novas tentativas, filas, limites de frequência ou tempos de conclusão mais longos.
A ZimaSpace descreve o mesmo limite no dimensionamento de workers orientado por eventos: a profundidade da fila pode justificar mais workers apenas até o caminho a jusante se tornar o recurso limitador. A concorrência das automações do Home Assistant deve parar no mesmo tipo de fronteira de serviço.
Para um pico de iluminação local, meça quantas chamadas de serviço simultâneas o coordenador consegue absorver sem confirmações atrasadas ou novas tentativas. Para notificações, respeite os limites de frequência do fornecedor. Para ações na nuvem, tenha em conta o comportamento dos tempos-limite. O máximo correto é o menor limite imposto pela correção, pela capacidade a jusante e pelo objetivo de latência — não o maior número que a CPU consegue iniciar.
Use Limiares em Vez de um Número Universal
Mantenha a concorrência em um para fluxos em que um acionamento mais recente substitui a intenção anterior ou em que a ordem tem de ser preservada. Use uma fila pequena quando todos os eventos tiverem de ser executados, mas o destino for serial. Use execuções paralelas apenas para ações independentes e idempotentes cujo serviço a jusante tenha margem medida. Aumente o limite um passo de cada vez, observando a idade da execução mais antiga e a latência de conclusão.
Um caso no fórum do Home Assistant sobre integrações na nuvem que tornavam o sistema mais lento mostra por que motivo as esperas externas prolongadas podem aumentar o trabalho ativo. É um forte alerta contra dimensionar o máximo apenas com base num comportamento de WAN saudável quando a mesma automação contém chamadas através da Internet.
Uma regra prática para parar é: nenhum evento obrigatório perdido, nenhuma fila com idade superior ao prazo da casa, nenhuma violação da ordem no destino e nenhum aumento da acumulação durante o pior pico normal. Se essas condições se mantiverem, mais concorrência não terá valor para o utilizador. Se falharem, encurte primeiro a fase lenta ou separe o trabalho independente; aumente o máximo apenas quando a sobreposição restante for genuinamente segura.
Faça um Teste de Pico Antes de Alterar o Limite
Crie um pico de eventos representativo, em vez de um ciclo infinito artificial. Registe o número de acionamentos, as execuções ativas, as execuções em fila, a idade da execução mais antiga, a duração das ações, a confirmação do dispositivo, a carga da CPU, o atraso do ciclo de eventos, se disponível, e os erros da integração de destino. Repita com uma definição de concorrência superior e outra inferior, mantendo o mesmo pico de entrada.
Um artigo recente sobre uma arquitetura local-first salienta que a fiabilidade do Home Assistant depende de manter os caminhos de controlo críticos limitados, em vez de adicionar complexidade em todo o lado. A concorrência é um desses limites: deve absorver a sobreposição normal sem transformar uma tempestade de eventos em contenção em toda a casa.
Escolha a definição mais baixa que conclua o trabalho obrigatório dentro do prazo e sobreviva ao pico sem uma fila crescente. Pode ser um, uma fila curta ou uma quantidade paralela moderada, dependendo do fluxo de trabalho. Volte a testar depois de adicionar chamadas à nuvem, atrasos prolongados ou novos sensores de alta frequência, porque essas alterações modificam a duração e a taxa de chegada, mesmo que o número de dispositivos permaneça igual.
Perguntas frequentes
O máximo predefinido de 10 é um objetivo de concorrência recomendado para todas as automações?
Não. Um limite predefinido é um mecanismo de segurança, não uma recomendação de dimensionamento. Muitas automações funcionam corretamente com uma execução, enquanto outras precisam de uma fila limitada menor ou maior, consoante a sua carga de trabalho e o sistema a jusante.
O modo paralelo torna o Home Assistant mais rápido?
Apenas quando as execuções são independentes e o ponto de estrangulamento consegue processá-las em simultâneo. Se o destino for serial, tiver limites de frequência ou depender da ordem, o modo paralelo pode aumentar a espera e os erros em vez de reduzir a latência.
Cada divisão deve ter a sua própria automação para reduzir a concorrência?
Não necessariamente. Dividir a lógica pode melhorar a gestão, mas também pode criar mais elementos independentes a escrever no mesmo dispositivo ou auxiliar. A estrutura deve seguir os limites de controlo e os requisitos de ordem, e não o objetivo de maximizar o número de automações.
Centro de Tecnologia e IA
Mais para Ler

As câmaras domésticas conseguem sincronizar eventos sem serviços de hora na nuvem?
Uma explicação baseada primeiro no mecanismo do tempo da câmara sem cloud, as suas contrapartidas na partilha de recursos, três perguntas frequentes sobre a...

Um serviço de IA local consegue detetar camadas de modelos corrompidas antes da inferência?
Uma explicação baseada primeiro no mecanismo da deteção de corrupção na camada do modelo, dos seus compromissos em termos de recursos partilhados, de três...

É possível restaurar um sistema RAG sem regenerar todos os embeddings?
Uma explicação, centrada no mecanismo, do restauro de RAG sem re-embedding, das suas contrapartidas em recursos partilhados, de três perguntas frequentes sobre a expansão...

