> 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/fr/faq-and-troubleshooting/iot-logic/how-to-implement-event-driven-scheduling-using-unix-time-in-iot-logic.md).

# Comment mettre en œuvre un ordonnancement piloté par les événements à l’aide du temps Unix dans IoT Logic

Dans cette section, configurez un temporisateur dans IoT Logic pour contrôler l’activation des sorties sur les appareils. Cela fonctionne comme un ordonnanceur en utilisant l’heure Unix pour le contrôle temporel.

<figure><img src="/files/020d9e6d279d9efbb6e5840a238462ecc82b77fb" alt=""><figcaption></figcaption></figure>

Tout d’abord, la logique de l’ordonnanceur a été construite sur la base de l’heure Unix, car c’est le seul paramètre fiable et cohérent sur lequel nous pouvons toujours compter. Le deuxième élément clé est l’horodatage des paquets valides reçus par la plateforme Navixy.\
Il est important de noter que cette logique exige que l’appareil envoie en continu des paquets de données valides à la plateforme. La fréquence elle-même n’est pas critique ; en revanche, si aucun message entrant n’est reçu, il devient impossible d’évaluer le temps ou de déclencher des actions planifiées.

\
Passons maintenant au nœud de calcul des attributs logiques mis en œuvre.\
Ce nœud récupère :

* L’heure actuelle de l’événement (current\_time) du dernier paquet
* L’heure précédente de l’événement (prev\_time) du paquet précédent

Les deux valeurs sont converties de millisecondes en secondes.<br>

Il est important de noter que **genTime** est fourni en heure Unix (millisecondes) et doit être divisé par 1000 pour obtenir l’heure Unix en secondes, qui est le format utilisé pour tous les calculs.

\
À partir de ces valeurs, le système calcule :

* current\_sod (secondes de la journée)
* prev\_sod (secondes de la journée pour le paquet précédent)

Cela se fait à l’aide de l’opération du module, qui extrait le nombre de secondes écoulées depuis minuit, convertissant ainsi l’heure Unix en une référence d’heure dans la journée.

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

Un décalage horaire peut être observé dans ces formules. Ce décalage est déterminé par le fuseau horaire UTC dans lequel les calculs sont effectués.

Dans le scénario de test, les calculs ont été effectués en UTC -6, ce qui a entraîné une différence de 6 heures. Convertie en secondes, cela équivaut à :\
6 heures × 60 min × 60 s = 21 600 secondes.

{% code overflow="wrap" %}

```
current_sod = (current_time - offset_time) % 86400
prev_sod = (prev_time - offset_time) % 86400
```

{% endcode %}

\
À l’aide de ces valeurs, le système détecte les transitions temporelles, et non des états continus.

\
Par exemple :

* Condition de mise sous tension (par exemple, 20 h) :Le système vérifie quand l’heure franchit le seuil :

  <pre data-overflow="wrap"><code>prev_sod &#x3C; 72000 AND current_sod >= 72000
  </code></pre>
* Condition de mise hors tension (par exemple, 5 h) :

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

Cela garantit que l’action est déclenchée une seule fois au moment de la transition, et non en continu pendant toute la fenêtre temporelle.

\
Une fois la logique satisfaite, le nœud d’action déclenchera la commande de sortie pour modifier l’état de sortie.\
Certaines limitations peuvent apparaître tout au long de ce flux, et il est important de les mettre en évidence afin qu’elles puissent être prises en compte :<br>

* **Dépend des données entrantes :**

Si l’appareil cesse d’envoyer des données, aucune action n’est déclenchée. C’est pourquoi une surveillance continue de l’unité est requise. Si l’appareil est déconnecté, bloqué ou en Mode "veille" sans envoi de données valides, le changement d’état n’est jamais détecté.<br>

* **Aucune garantie d’heure d’exécution exacte :**

Les actions sont exécutées lorsque le paquet de données suivant arrive après que le seuil a été atteint, et non exactement à l’heure planifiée. Par exemple, si l’appareil transmet toutes les 5 minutes et que le dernier paquet a été reçu à 20:58, le message suivant arrivera à 21:03. À ce moment-là, la logique sera satisfaite et l’action (par exemple, l’activation de la sortie) sera déclenchée.<br>

* **Gestion du fuseau horaire requise :**

Comme l’heure Unix est en UTC, un décalage doit être appliqué pour l’aligner sur l’heure locale souhaitée.<br>

* **Aucun état persistant de planification :**

Le système ne stocke pas les heures de déclenchement futures ; il s’appuie entièrement sur des comparaisons en temps réel entre des paquets entrants consécutifs.

Cette solution simule un ordonnanceur dans un système piloté par événements en utilisant des horodatages Unix et en détectant les transitions temporelles entre des paquets de données consécutifs. Bien qu’il ne s’agisse pas d’un véritable ordonnanceur, elle offre un moyen fiable et évolutif de mettre en œuvre une automatisation basée sur le temps sans nécessiter de prise en charge native de la planification.


---

# 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/fr/faq-and-troubleshooting/iot-logic/how-to-implement-event-driven-scheduling-using-unix-time-in-iot-logic.md?ask=<question>&goal=<endgoal>
```

`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.
