# 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 afin de contrôler l’activation des sorties sur les appareils. Celle-ci fonctionnera comme un planificateur en utilisant l’heure Unix pour le contrôle basé sur le temps.
Tout d’abord, la logique du planificateur a été construite sur la base de l’heure Unix, car 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 de logique mis en œuvre.\ Ce nœud récupère : * L’heure de l’événement actuelle (current\_time) du dernier paquet * L’heure de l’événement précédente (prev\_time) 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 de la journée) * prev\_sod (secondes de la journée pour le paquet précédent) Cela est fait à l’aide de l’opération modulaire, qui extrait le nombre de secondes écoulées depuis minuit, convertissant ainsi efficacement l’heure 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. 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 %} \ À l’aide de 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 est déclenchée une seule fois au moment de la transition, plutôt que de manière continue pendant toute la plage horaire. \ Une fois que la logique est satisfaite, le nœud d’action déclenchera la commande de sortie afin de modifier l’état de la 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épend 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. : 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 planificateur 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 planificateur, 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: 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/comment-mettre-en-oeuvre-une-planification-pilotee-par-evenements-a-laide-du-temps-unix-dans-iot-log.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.