Automações
Repetição Until
Repetição Until é uma estrutura que executa um bloco e continua até a condição de término tornar-se verdadeira. Um exemplo é tentar obter confirmação de uma válvula a cada 5 s, encerrando ao confirmar ou após 12 ciclos. Evoluiu das estruturas repeat-until de linguagens como Pascal. Deve ser escolhida quando a condição expressa o objetivo final e a primeira execução precisa ocorrer. A limitação é o risco de insistência indevida; timeout, backoff e estado seguro são obrigatórios.
⚙ Definição Técnica
Repetição Until é uma estrutura de controle em que uma sequência é executada e, ao final de cada ciclo, uma condição de término é avaliada. Enquanto o objetivo não for satisfeito, o bloco repete. A forma ficou conhecida em linguagens como Pascal, lançado em 1970, por meio de REPEAT…UNTIL, e aparece em motores de automação com sintaxes próprias. Em muitos contextos, o corpo executa pelo menos uma vez; em outros, a plataforma implementa until como condição após a sequência repeat. A semântica deve ser confirmada. O mecanismo é adequado quando o número de tentativas é desconhecido e existe um estado final claramente verificável. O custo-benefício surge na simplicidade para reconciliação. A ressalva é que uma condição impossível, sensor indisponível ou atuador defeituoso mantém o laço indefinidamente sem proteções. Limite de ciclos, timeout, backoff, cancelamento e ação de falha são requisitos de projeto.
Tipos comuns de gatilhos
Until para confirmação de estado físico
A sequência envia comando, aguarda e verifica feedback até o estado ser confirmado. Exemplo: solicitar fechamento de válvula, esperar 3 s e repetir até o contato indicar fechada. O feedback deve ser independente do comando. Estado otimista retornado pela API não prova movimento. Defina máximo de 3–5 tentativas e tempo total. Repetir indefinidamente pode danificar motor ou mascarar obstrução. A ação final precisa colocar o sistema em estado seguro e gerar alerta. Para portões, portas e válvulas, use controladores certificados e proteções locais. A automação supervisora não substitui fim de curso, detecção de obstáculo ou circuito de segurança.
Until para aguardar disponibilidade de serviço
Após reinício, uma integração pode levar tempo para ficar online. O laço espera 5 s e reavalia até connected, com timeout de 2 min. Essa abordagem é simples, mas polling fixo pode gerar carga. Retentativa exponencial é melhor para serviços remotos. Se a plataforma oferece evento de disponibilidade, wait for trigger reduz. A condição deve distinguir autenticação inválida de inicialização. Erro 401 não será resolvido por esperar. Falhas permanentes devem interromper cedo. O laço precisa registrar último erro. A consequência prática é recuperação automática sem esconder configuração quebrada.
Until para atingir valor ou faixa
A automação aplica pulsos até temperatura, nível ou posição atingir limite. Exemplo: mover persiana em passos até iluminância superar 300 lux. O processo possui atraso e inércia. Medir imediatamente após ação gera overshoot. Inclua tempo de estabilização. Sensores têm ruído e precisão. Use histerese. Limite total de movimento. Em controle contínuo, PID ou controlador dedicado é mais adequado. Until funciona para ajustes discretos e lentos. Para aquecimento, não faça ciclos rápidos. Proteções do equipamento prevalecem. O laço deve parar em sensor unavailable, valor fora de plausibilidade ou perda de comunicação.
Until para processar lote até condição de conclusão
Um worker busca páginas de API até next_cursor ser nulo ou processed_count atingir objetivo. Cada ciclo chama endpoint, processa dados e atualiza cursor. A condição de término precisa usar resposta validada. APIs podem repetir cursor ou retornar página vazia temporariamente. Mantenha conjunto de cursores vistos para detectar ciclo. Limite páginas e bytes. Respeite rate limit. Se a execução falhar, persista cursor de forma transacional para retomar sem duplicar. Em casa inteligente, isso pode ocorrer ao sincronizar histórico, dispositivos ou registros. Para grandes lotes, um job dedicado é melhor que automação visual.
Until com ação inicial obrigatória
O bloco precisa executar antes de verificar, como enviar primeiro pedido e só então esperar confirmação. Essa é a diferença prática em relação ao While pré-condicional. Se a plataforma avalia until depois do ciclo, o comportamento é natural. Se não, modele explicitamente: ação inicial, depois While not condition. Teste. Um erro comum é migrar entre motores presumindo semântica idêntica. O trace deve mostrar a primeira execução. Para ações não idempotentes, garantir “ao menos uma vez” pode causar duplicidade em retomada após falha. Use chave de idempotência e estado de operação.
Considerações de Implementação
Objetivo impossível mantém a automação insistindo
Sensor quebrado, valor fora de alcance, credencial inválida ou atuador travado impedem a condição de término. Todo Until precisa de limite. Defina max cycles, timeout e condição de aborto. O valor deve considerar pior caso legítimo. Ao exceder, execute sequência de falha: desligar saídas, liberar recursos, notificar e registrar. Não apenas sair. Métricas de tentativas e duração ajudam. Um limite muito alto pode causar desgaste. Um muito baixo gera falso erro. Teste falhas deliberadamente.
Repetir ação não idempotente pode produzir dano ou duplicidade
Incrementar posição, alternar relé, criar registros e enviar mensagens acumulam efeito. Prefira comando absoluto e verificável. Set position 50% é mais seguro que move +10% repetido sem confirmação. APIs devem usar idempotency key. Notificações podem ser agrupadas. Em atuadores, respeite duty cycle. Motores têm limites térmicos. O laço deve separar tentativa de consulta de tentativa de comando. Muitas vezes, é melhor enviar uma vez e apenas consultar. Reenviar somente quando existe evidência de perda.
Backoff reduz carga e sincronização de clientes
Intervalo fixo de 1 s por minutos sobrecarrega. Use 1, 2, 4, 8 s com teto, ou perfil adequado. Adicione jitter quando muitos dispositivos reiniciam juntos. Para processo físico, intervalo deve refletir tempo de resposta, não fórmula genérica. Backoff aumenta tempo de recuperação, mas protege serviço. O laço pode calcular delay por índice. Registre. Em APIs que fornecem Retry-After, respeite. Um Until sem política de espera é incompleto.
Condição de término deve representar resultado, não apenas comando aceito
HTTP 202, ACK de rádio ou estado requested não significa ação física concluída. Use feedback real. Para luz simples, estado reportado pode bastar. Para válvula, contato ou fluxo. Para backup, arquivo validado. Para atualização, versão confirmada. A qualidade da condição determina a confiabilidade. Se não existe feedback, declare a limitação e encerre após confirmação de transporte, sem afirmar conclusão física. A automação precisa usar linguagem correta em logs e notificações.