Como implementar o agendamento orientado por eventos usando o tempo Unix no IoT Logic
Nesta seção, configuraremos um temporizador no IoT Logic para controlar a ativação das saídas nos dispositivos. Isso funcionará como um agendador, utilizando o horário Unix para o controle baseado em tempo.
Primeiro, a lógica do agendador foi construída com base no horário Unix, pois ele é o único parâmetro confiável e consistente do qual podemos sempre depender. O segundo elemento-chave é o timestamp dos pacotes válidos recebidos pela plataforma. É importante observar que essa lógica exige que o dispositivo envie continuamente pacotes de dados válidos para a plataforma. A frequência em si não é crítica; no entanto, se nenhuma mensagem de entrada for recebida, torna-se impossível avaliar o tempo ou disparar quaisquer ações agendadas.
Agora, passando para o nó de cálculo do atributo de lógica implementado. Este nó recupera:
O horário do evento atual (current_time) do pacote mais recente
O horário do evento anterior (prev_time) do pacote anterior
Ambos os valores são convertidos de milissegundos para segundos.
É importante observar que genTime é fornecido em horário Unix (milissegundos) e deve ser dividido por 1000 para obter o horário Unix em segundos, que é o formato que usaremos em todos os cálculos.
A partir disso, o sistema calcula:
current_sod (segundos do dia)
prev_sod (segundos do dia para o pacote anterior)
Isso é feito usando a operação de módulo, que extrai o número de segundos decorridos desde a meia-noite, convertendo efetivamente o horário Unix em uma referência de hora do dia.
Pode ser observada uma defasagem de tempo nessas fórmulas. Essa defasagem é determinada pelo fuso horário UTC no qual os cálculos são realizados.
No cenário de teste, os cálculos foram realizados em UTC -6, resultando em uma diferença de 6 horas. Quando convertido para segundos, isso equivale a: 6 horas × 60 min × 60 seg = 21.600 segundos.
Usando esses valores, o sistema detecta transições de tempo, não estados contínuos.
Por exemplo:
Condição para LIGAR (por exemplo, 20h): O sistema verifica quando o tempo cruza o limite:
Condição para DESLIGAR (por exemplo, 5h):
Isso garante que a ação seja disparada apenas uma vez no momento da transição, e não continuamente durante toda a janela de tempo.
Uma vez que a lógica seja atendida, o nó de ação disparará o comando de saída para alterar o estado da saída. Algumas limitações podem surgir ao longo desse fluxo, e é importante destacá-las para que possam ser levadas em consideração:
Dependente dos dados de entrada:
Se o dispositivo parar de enviar dados, nenhuma ação será disparada. Por isso, é necessário o monitoramento contínuo da unidade. Se o dispositivo estiver desconectado, com bloqueio de sinal ou em modo de suspensão sem enviar dados válidos, a alteração de estado nunca será detectada.
Sem garantia de execução no horário exato:
As ações são executadas quando o próximo pacote de dados chega após o limite ser atingido, e não exatamente no horário agendado. Por exemplo, se o dispositivo envia relatórios a cada 5 minutos e o último pacote foi recebido às 20h58, a próxima mensagem chegará às 21h03. Nesse momento, a lógica será satisfeita e a ação (por exemplo, ativação da saída) será disparada.
É necessário tratar o fuso horário:
Como o horário Unix está em UTC, um deslocamento deve ser aplicado para alinhá-lo ao horário local desejado.
Sem estado persistente de agendamento:
O sistema não armazena horários futuros de disparo; ele depende totalmente de comparações em tempo real entre pacotes de entrada consecutivos.
Essa solução simula um agendador em um sistema orientado a eventos, usando timestamps Unix e detectando transições de tempo entre pacotes de dados consecutivos. Embora não seja um agendador verdadeiro, ela oferece uma forma confiável e escalável de implementar automação baseada em tempo sem exigir suporte nativo de agendamento.
Atualizado
Isto foi útil?