> 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 Agendamento orientado a eventos usando tempo Unix no IoT Logic

Agende ações de saída baseadas em temporizador no IoT Logic usando timestamps Unix. Acione comandos de dispositivos em horários exatos com o envio contínuo de dados do dispositivo ativado.

Nesta seção, configure um timer no IoT Logic para controlar a ativação das saídas nos dispositivos. Isso funciona como um agendador usando o tempo Unix para controle baseado em tempo.

<figure><img src="https://1173629567-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FIgDb43gtyXcm1Av4h1np%2Fuploads%2Fgit-blob-43ae91462add262dec5bc06a902e2ecea27630c2%2Fimage.png?alt=media" alt=""><figcaption></figcaption></figure>

Primeiro, a lógica do agendador foi construída com base no tempo Unix, pois ele é o único parâmetro confiável e consistente em que sempre podemos nos apoiar. O segundo elemento-chave é o timestamp dos pacotes válidos recebidos pela plataforma Navixy.\
É 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 recebida, torna-se impossível avaliar o tempo ou acionar quaisquer ações agendadas.

\
Agora, passando para o nó de cálculo do atributo da lógica implementada.\
Esse nó recupera:

* O horário atual do evento (current\_time) do último pacote
* O horário anterior do evento (prev\_time) do pacote anterior

Ambos os valores são convertidos de milissegundos para segundos.<br>

É importante observar que **genTime** é fornecido em tempo Unix (milissegundos) e deve ser dividido por 1000 para obter o tempo Unix em segundos, que é o formato usado para todos os cálculos.

\
A partir disso, o sistema calcula:

* current\_sod (segundos do dia)
* prev\_sod (segundos do dia do 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 tempo Unix em uma referência de hora do dia.

<pre><code><strong>time % 86400
</strong></code></pre>

Um deslocamento de tempo pode ser observado nestas fórmulas. Esse deslocamento é determinado 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. Convertido para segundos, isso equivale a:\
6 horas × 60 min × 60 s = 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 a saída (por exemplo, 20h):O sistema verifica quando o tempo cruza o limite:

  <pre data-overflow="wrap"><code>prev_sod &#x3C; 72000 AND current_sod >= 72000
  </code></pre>
* Condição para desligar a saída (por exemplo, 5h):

  <pre data-overflow="wrap"><code>prev_sod &#x3C; 18000 AND current_sod >= 18000
  </code></pre>

Isso garante que a ação seja disparada apenas uma vez no momento da transição, em vez de continuamente durante toda a janela de tempo.

\
Quando a lógica é atendida, o nó de ação acionará o comando de saída para alterar o estado da saída.\
Podem surgir algumas limitações ao longo deste fluxo, e é importante destacá-las para que possam ser levadas em consideração:<br>

* **Dependente dos dados recebidos:**

Se o dispositivo parar de enviar dados, nenhuma ação é acionada. É por isso que é necessário o monitoramento contínuo da unidade. Se o dispositivo estiver desconectado, travado ou em modo de repouso sem enviar dados válidos, a mudança de estado nunca é detectada.<br>

* **Sem garantia de horário exato de execução:**

As ações são executadas quando o próximo pacote de dados chega depois que o limite é atingido, não exatamente no horário agendado. Por exemplo, se o dispositivo reporta a cada 5 minutos e o último pacote foi recebido às 20:58, a próxima mensagem chegará às 21:03. Nesse momento, a lógica será cumprida e a ação (por exemplo, a ativação da saída) será acionada.<br>

* **É necessário lidar com o fuso horário:**

Como o tempo Unix está em UTC, um deslocamento deve ser aplicado para alinhá-lo com o horário local desejado.<br>

* **Sem estado persistente de agendamento:**

O sistema não armazena horários futuros de disparo; ele depende inteiramente de comparações em tempo real entre pacotes consecutivos recebidos.

Esta solução simula um agendador em um sistema orientado por 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 maneira 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 by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
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=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

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.
