> 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 événements à l'aide du temps Unix dans IoT Logic Planifiez des actions de sortie déclenchées par minuteur dans IoT Logic à l'aide d'horodatages Unix. Déclenchez les commandes de l'appareil à des moments précis avec la remontée continue des données de l'appareil activée. Dans cette section, configurez un minuteur dans IoT Logic pour contrôler l’activation des sorties sur les appareils. Cela fonctionne comme un ordonnanceur en utilisant le temps Unix pour un contrôle temporel.
Tout d’abord, la logique de l’ordonnanceur a été construite à partir du temps Unix, puisqu’il s’agit du seul paramètre fiable et cohérent sur lequel vous pouvez toujours vous appuyer. 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 ; toutefois, si aucun message entrant n’est reçu, il devient impossible d’évaluer le temps ou de déclencher des actions planifiées. \ À présent, passons au nœud de calcul de l’attribut logique implémenté.\ Ce nœud récupère : * L’heure de l’événement courant (\`current\_time\`) à partir du dernier paquet * L’heure de l’événement précédent (\`prev\_time\`) à partir du paquet précédent Les deux valeurs sont converties des millisecondes en secondes.
Il est important de noter que **genTime** est fourni en temps Unix (millisecondes) et doit être divisé par 1000 pour obtenir le temps Unix en secondes, qui est le format utilisé pour tous les calculs. \ À partir de ceux-ci, 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 modulo, qui extrait le nombre de secondes écoulées depuis minuit, convertissant ainsi efficacement le temps Unix en une référence d’heure 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. Converti en secondes, cela correspond à :\ 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 %} \ En utilisant ces valeurs, le système détecte les transitions temporelles, et non des états continus. \ Par exemple : * Condition d’activation ON (p. 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 OFF (p. ex. 5 h) : 
prev_sod < 18000 AND current_sod >= 18000
Cela garantit que l’action est déclenchée une seule fois au moment de la transition, plutôt que de manière continue 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 limites 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 :
* **Dépendant 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 envoyer de données valides, le changement d’état n’est jamais détecté.
* **Aucune garantie d’heure d’exécution exacte :** Les actions sont exécutées lorsque le prochain paquet de données arrive après que le seuil a été atteint, et non exactement à l’heure planifiée. Par exemple, si l’appareil envoie un message 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 (p. ex. l’activation de la sortie) sera déclenchée.
* **Gestion du fuseau horaire requise :** Puisque le temps Unix est en UTC, un décalage doit être appliqué pour l’aligner sur l’heure locale souhaitée.
* **Aucun état d’ordonnancement persistant :** Le système ne stocke pas les futurs temps de déclenchement ; 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 l’ordonnancement. --- # 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=&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.