Automações
Resposta de Ação
Dentro da família de mecanismos de encadeamento, a resposta de ação é o conjunto de dados retornado por um serviço após execução. Desde APIs REST com HTTP 200 até ações modernas do Home Assistant que expõem response_variable, o recurso resolve a passagem de resultados sem consulta adicional. Pode carregar previsão, lista, status ou identificador. O problema é que sucesso de transporte não garante conteúdo válido; schema, timeout, tamanho, privacidade e compatibilidade de versão precisam ser tratados.
⚙ Definição Técnica
Resposta de ação é o valor ou objeto estruturado produzido por uma ação, chamada de serviço, script, API ou componente e disponibilizado às etapas seguintes da mesma execução. O mecanismo pertence à família de passagem de dados entre operações e resolve o problema de encadear decisões sem consultar novamente a fonte. Em APIs HTTP, a resposta combina status, cabeçalhos e corpo; em Home Assistant, determinadas ações suportam response_variable; em scripts, return ou saída equivalente; em Node-RED, a mensagem modificada segue pelo fluxo. O consumidor precisa conhecer schema, tipos, unidade e semântica. Uma ação considerada executada pode retornar dados vazios, parciais ou atrasados. O retorno também pode conter informação sensível. Por isso, validação, timeout, limite de tamanho, redaction e compatibilidade de versão são requisitos. A resposta não deve ser confundida com mudança de estado assíncrona do dispositivo. Um serviço pode aceitar o comando e retornar antes da conclusão física.
Tipos comuns de gatilhos
Resposta síncrona de consulta
A ação solicita dados e recebe resultado no mesmo fluxo: previsão meteorológica, lista de eventos, preço de energia, histórico ou estado detalhado. O retorno pode ser JSON. A automação extrai campos. HTTP 200 indica sucesso da requisição, não qualidade dos dados. Valide schema, presença, tipo, faixa e timestamp. Uma lista vazia pode ser resultado válido ou falha do provedor. O contrato precisa definir. Para valores com unidade, normalize. A consulta deve ter timeout. Se falhar, use fallback ou interrompa. Cache reduz chamadas. Dados antigos precisam de política. A vantagem é disponibilizar informação contextual sem criar entidade persistente. Se o dado é usado por várias regras, uma integração ou sensor é melhor.
Resposta de ação de serviço interno
Um script ou serviço retorna status, identificador, contagem ou objeto. Exemplo: script de seleção de cena retorna quais dispositivos foram alterados e quais falharam. A automação chama e usa response_variable. Isso cria contrato interno. Nome de campos, versão e significado devem ser documentados. Mudanças precisam ser compatíveis. Um script pode retornar success true mesmo com falhas parciais; inclua arrays succeeded e failed. Para segurança, não retorne tokens. O chamador deve verificar. Se a plataforma não garante resposta para todas as ações, use apenas serviços documentados. Traces devem mostrar retorno com redaction.
Resposta assíncrona com identificador de operação
A ação inicia trabalho longo e retorna operation_id, job_id ou HTTP 202. A conclusão virá por polling, webhook ou evento. O retorno não é resultado final. A automação armazena o ID, aguarda e correlaciona. O identificador precisa ser único e imprevisível quando exposto. Defina TTL. Se a execução reinicia, pode perder. Persistência ou reconciliador ajuda. Não mantenha conexão por minutos. Em atualização de firmware, backup ou processamento de vídeo, esse padrão é comum. O fluxo deve distinguir accepted, running, succeeded e failed. Notificar sucesso logo após 202 é erro.
Resposta com múltiplos itens ou páginas
A ação devolve lista de dispositivos, eventos ou registros. A automação pode iterar. Tamanho precisa ser limitado. APIs usam paginação por cursor. Ignorar next_cursor produz dados incompletos. Carregar milhares de itens numa variável consome memória e aumenta trace. Filtre no servidor. Para cada item, valide. Ordem pode não ser garantida. Use ID. Se a resposta muda entre páginas, consistência precisa ser considerada. Para uso residencial, listas de calendário e dispositivos são comuns. Quando o volume cresce, um componente dedicado é mais adequado que templates complexos.
Resposta de comando com confirmação parcial
Uma ação de grupo pode retornar resultados por dispositivo. Exemplo: 8 luzes comandadas, 7 confirmadas e 1 offline. O fluxo precisa decidir se segue, repete ou alerta. Um booleano global esconde. O contrato deve separar aceitação do comando, ACK de protocolo e estado físico. Em Zigbee, grupo pode não fornecer confirmação individual. Em APIs de nuvem, o servidor aceita e atualiza depois. A automação deve conhecer a interoperabilidade. Para função crítica, sensores independentes. Para conforto, melhor esforço pode bastar. O retorno precisa ser descrito com linguagem precisa.
Considerações de Implementação
Schema ausente ou alterado quebra templates posteriores
Ações de integrações podem mudar campos entre versões. A automação precisa verificar is defined, tipos e versionamento. Defaults devem ser seguros. Um campo ausente não deve virar zero se isso libera ação. Use JSON Schema quando possível. Crie testes com exemplos. Se a resposta possui version, selecione parser. Em contratos internos, mantenha compatibilidade ou migre consumidores. Logs de erro devem indicar caminho e valor sem vazar dados. Tratar tudo como dicionário é insuficiente: listas, strings e null aparecem.
Resposta grande ou sensível não deve ser copiada indiscriminadamente
Corpos podem conter localização, calendário, imagens, tokens, credenciais ou dados pessoais. Evite armazenar no trace completo. Extraia campos necessários. Defina limite de bytes. Redija cabeçalhos Authorization e cookies. Backups e logs herdam risco. Uma resposta de câmera pode ser binária e inadequada a variável. Use arquivo ou URL protegida. A retenção deve ser mínima. O fato de o dado estar no motor local não elimina acesso por administradores, add-ons e exportações.
Transporte bem-sucedido não equivale a resultado de negócio
HTTP 200 pode conter erro no corpo. HTTP 202 apenas aceita. Um script pode executar sem exceção e retornar failed. A automação deve avaliar níveis: transporte, validação, negócio e efeito físico. Cada um possui status. Em notificação, diga “comando enviado” ou “confirmado” corretamente. A resposta precisa carregar erro estruturado, não apenas texto. Códigos ajudam. Retentativa depende da classe: 429 e 503 podem ser temporários; 400, permanente. A política deve seguir contrato.
Variável de resposta possui escopo e tempo de vida
Em muitos motores, existe apenas na execução atual. Não sobrevive a reinício nem fica disponível a outra automação. Para compartilhar ou persistir, grave em entidade, banco ou helper apropriado. Isso adiciona estado e privacidade. Em paralelo, cada instância precisa de variável isolada. Nomes iguais não devem colidir. Capture antes de lançar tarefas assíncronas se o escopo muda. O trace precisa associar ao run_id. Conhecer escopo evita depender de dado que desaparece.