Automações
Execução em Fila
Como uma fila de atendimento com ordem preservada, a execução em fila mantém novas instâncias aguardando até a anterior terminar. Em automação, formaliza o processamento serial de eventos e pode usar política FIFO, limite máximo e timeout. Um motor como Home Assistant oferece modo queued; brokers seguem princípios semelhantes. Uma fila de 20 itens reduz condições de corrida, mas aumenta latência. Para conformidade operacional, deve existir política para excesso, expiração e falha, evitando executar comandos obsoletos horas depois.
⚙ Definição Técnica
Execução em fila é um modo de processamento no qual cada nova instância é aceita e colocada em uma estrutura de espera enquanto outra execução do mesmo fluxo permanece ativa. O atendimento ocorre de forma serial, normalmente em ordem FIFO, embora outras políticas possam existir. A analogia técnica é uma fila de mensagens com um consumidor único: cada item preserva contexto próprio, aguarda sua vez e é removido após conclusão, falha ou descarte. O objetivo é impedir sobreposição sobre recursos compartilhados e preservar ordem. O custo é latência acumulada. Se uma execução dura 30 s e dez itens aguardam, o último pode começar vários minutos depois. A implantação deve definir capacidade máxima, timeout, expiração, persistência, comportamento em reinício e tratamento de erro. Em Home Assistant, o modo queued serializa execuções e possui max; em Node-RED e sistemas de mensageria, a mesma ideia pode ser implementada com filas, delay nodes ou workers.
Tipos comuns de gatilhos
Fila FIFO para preservar ordem de eventos
First In, First Out processa na ordem de chegada. É adequada quando a sequência tem significado: abrir, ajustar, fechar; iniciar, atualizar, finalizar; registrar eventos. Uma fechadura recebendo lock e depois unlock precisa respeitar a ordem, mas também precisa considerar atualidade. Se o comando unlock fica 5 min na fila, pode ser perigoso. Portanto, FIFO não basta. Itens devem possuir timestamp e TTL. Alguns eventos podem ser coalescidos. Estados desejados podem substituir anteriores. Para iluminação, on seguido de off pode ser reduzido ao último estado se nenhum efeito intermediário importa. Para auditoria, eventos devem permanecer. A política depende da função. A fila preserva ordem mecânica; a lógica decide relevância.
Fila por recurso compartilhado
Cada dispositivo ou grupo possui fila independente. Comandos para a mesma cortina são serializados; comandos para cortinas diferentes podem ocorrer em paralelo. Isso evita bloqueio global. A chave de particionamento pode ser device_id, área ou recurso lógico. O consumidor precisa impedir que duas filas apontem para o mesmo atuador real. Integrações que agrupam canais em um único gateway podem compartilhar limitação, exigindo fila por gateway. A documentação do protocolo ajuda. KNX, Modbus, Zigbee e APIs possuem capacidades diferentes. Uma fila por recurso melhora throughput e reduz corrida, mas aumenta estrutura. Monitoramento deve mostrar profundidade por chave.
Fila com capacidade máxima
A estrutura aceita até N itens, como 10, 20 ou 100. Ao atingir o limite, a política pode rejeitar o novo, descartar o mais antigo, substituir item equivalente ou bloquear o produtor. Não existe escolha universal. Alertas críticos não devem ser descartados silenciosamente. Telemetria repetitiva pode usar drop oldest. Comandos de estado podem coalescer. Em Home Assistant, max limita execuções ativas e enfileiradas conforme modo. A plataforma pode apenas registrar warning ao exceder. Para operação confiável, acompanhe o contador e trate a origem. Uma fila cheia indica consumidor lento, falha externa ou tempestade de eventos. Aumentar o limite apenas adia o problema.
Fila persistente através de reinício
Alguns sistemas armazenam itens em disco ou broker para retomar após falha. Isso melhora entrega, mas pode executar ações antigas. Um evento de movimento não deve acender luz duas horas depois. Um comando de fechamento de válvula pode continuar relevante. Cada item precisa de tipo, prioridade e validade. Persistência exige integridade, segurança e controle de duplicidade. Se a ação foi executada e o ACK não foi gravado antes da queda, o item pode reaparecer. Idempotência é necessária. Filas persistentes também contêm dados pessoais. Criptografia, retenção e acesso devem ser definidos. Em ambientes residenciais, muitas filas do motor são voláteis; não se deve presumir retomada.
Fila com prioridade
Eventos recebem prioridade e podem ultrapassar itens normais. Emergência, desligamento de segurança ou alarme podem ser processados antes de atualizações de conforto. A introdução de prioridade quebra FIFO global e pode causar starvation. Itens de baixa prioridade nunca avançam se a fila recebe urgências contínuas. Use poucas classes, como crítica, alta e normal, e envelhecimento para elevar itens antigos. A prioridade precisa ser atribuída por fonte confiável. Um payload externo não deve declarar critical sem validação. A automação de segurança deve possuir caminho dedicado quando necessário, em vez de depender de uma fila congestionada por funções não críticas.
Considerações de Implementação
A fila pode transformar evento válido em ação obsoleta
Espera longa muda o contexto. Um sensor detecta presença, mas a pessoa já saiu quando o item executa. Um preço dinâmico muda. Uma porta fecha. Cada evento precisa de TTL ou revalidação. Antes da ação, consulte o estado atual e confirme que a intenção permanece. O snapshot do gatilho ainda serve para auditoria. Para comandos de estado, use versão ou timestamp. Para eventos transitórios, descarte após segundos ou minutos. O erro comum é acreditar que preservar entrega sempre melhora confiabilidade. Entrega tardia pode ser pior que descarte explícito.
Uma falha longa bloqueia todos os itens seguintes
Se a execução espera indefinidamente por API, dispositivo ou condição, a fila para. Todo passo externo precisa de timeout. Em falha, decida: repetir, enviar para DLQ, pular ou interromper. Retentativas com backoff não devem ocupar o consumidor por horas se outras ações são urgentes. Pode-se liberar e reagendar. Circuit breaker evita insistir em serviço indisponível. Métricas de idade do item mais antigo e tempo de processamento detectam bloqueio. Profundidade sozinha não mostra. Um item preso é um incidente operacional.
Serialização reduz corrida, mas não garante transação
Cada execução pode conter várias ações. Se a primeira conclui e a segunda falha, o estado fica parcial. A fila apenas impede sobreposição. Para consistência, use compensação, reconciliação ou operações atômicas do serviço. Em um cenário, luz liga e cortina falha; o item termina com erro. O próximo precisa saber se deve continuar. A política deve ser explícita. Logs devem registrar etapas concluídas. Repetir o item inteiro pode duplicar ações não idempotentes. Granularidade da fila e das ações influencia recuperação.
Profundidade, idade e taxa precisam ser observadas
Três métricas descrevem saúde: quantidade de itens, idade do mais antigo e taxa de entrada/saída. Uma fila com 100 itens de 1 ms pode estar saudável; cinco itens de 10 min, não. Dashboards e alertas devem usar percentis de espera e processamento. Registre rejeições, expirações e retries. Em residência, uma entidade diagnóstica pode mostrar backlog. O usuário não precisa ver detalhes técnicos, mas deve receber aviso quando funções estão atrasadas. Sem observabilidade, a fila mascara lentidão até virar comportamento aparentemente aleatório.