> 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 une planification pilotée par événements à l’aide du temps Unix dans IoT Logic Dans cette section, nous allons configurer une minuterie dans IoT Logic pour contrôler l’activation des sorties sur les appareils. Celle-ci fonctionnera comme un ordonnanceur en utilisant l’heure Unix pour un contrôle basé sur le temps.
Tout d’abord, la logique de l’ordonnanceur a été construite sur la base de l’heure Unix, puisqu’il s’agit du 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.\ 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 ; toutefois, 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 de l’attribut logique mis en œuvre.\ Ce nœud récupère : * L’heure de l’événement actuelle (current\_time) à partir du dernier paquet * L’heure de l’événement précédente (prev\_time) à partir du paquet antérieur Les deux valeurs sont converties de millisecondes en secondes.
Il est important de noter que **genTime** est fourni en heure Unix (millisecondes) et doit être divisé par 1000 afin d’obtenir l’heure Unix en secondes, qui est le format que nous utiliserons pour tous les calculs. \ À partir de ces valeurs, le système calcule : * current\_sod (secondes écoulées dans la journée) * prev\_sod (secondes écoulées dans 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 horaire de la journée. 
time % 86400
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. Une fois convertie en secondes, cela équivaut à :\ 6 heures × 60 min × 60 sec = 21 600 secondes. {% code overflow="wrap" %} ``` current_sod = (current_time - offset_time) % 86400 prev_sod = (prev_time - offset_time) % 86400 ``` {% endcode %} \ En utilisant ces valeurs, le système détecte les transitions de temps, et non les états continus. \ Par exemple : * Condition d’activation (par ex. : 20 h) : Le système vérifie quand l’heure franchit le seuil : 
prev_sod < 72000 AND current_sod >= 72000
* Condition de désactivation (par ex. : 5 h) : 
prev_sod < 18000 AND current_sod >= 18000
Cela garantit que l’action n’est déclenchée qu’une seule fois au moment de la transition, au lieu de l’être en continu pendant toute la plage horaire. \ 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 souligner afin qu’elles puissent être prises en compte :
* **Dépendant des données entrantes :** Si l’appareil cesse d’envoyer des données, aucune action ne sera déclenchée. C’est pourquoi une surveillance continue de l’unité est requise. Si l’appareil est déconnecté, brouillé ou en mode veille sans envoyer de données valides, le changement d’état ne sera jamais détecté.
* **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 ex. l’activation de la sortie) sera déclenchée.
* **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.
* **Aucun état de planification persistant :** 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 de temps entre des paquets de données consécutifs. Bien qu’il ne s’agisse pas d’un véritable ordonnanceur, elle offre une méthode fiable et évolutive pour 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: ``` 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= ``` The question should be specific, self-contained, and written in natural language. 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.