> For the complete documentation index, see [llms.txt](https://navixy.com/docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://navixy.com/docs/expert-center/pt-br/faq-and-troubleshooting/iot-logic/how-to-implement-event-driven-scheduling-using-unix-time-in-iot-logic.md).
# 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.
time % 86400
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.
{% code overflow="wrap" %}
```
current_sod = (current_time - offset_time) % 86400
prev_sod = (prev_time - offset_time) % 86400
```
{% endcode %}
\
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:
prev_sod < 72000 AND current_sod >= 72000
* Condição para DESLIGAR (por exemplo, 5h):
prev_sod < 18000 AND current_sod >= 18000
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.
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
GET https://navixy.com/docs/expert-center/pt-br/faq-and-troubleshooting/iot-logic/how-to-implement-event-driven-scheduling-using-unix-time-in-iot-logic.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.