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 temporisateur 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 basé sur le temps.

Tout d'abord, la logique de l'ordonnanceur a été construite sur la base du temps Unix, car il s'agit du seul paramètre fiable et cohérent sur lequel nous pouvons toujours nous 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.

Passons maintenant au nœud de calcul de l'attribut logique mis en œuvre. Ce nœud récupère :

• Le temps d'événement actuel (current_time) du dernier paquet

• Le temps d'événement précédent (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 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 ces valeurs, le système calcule :

• current_sod (secondes de la journée)

• prev_sod (secondes de la journée du 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 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 converti en secondes, cela équivaut à : 6 heures × 60 min × 60 s = 21 600 secondes.

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

À l'aide de ces valeurs, le système détecte les transitions temporelles, et non des é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, plutôt que de manière continue pendant toute la fenêtre temporelle.

Une fois la logique satisfaite, le nœud d'action déclenche 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 :

• 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'exécution à l'heure 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 programmé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 (par ex. l'activation de la sortie) sera déclenchée.

• Gestion du fuseau horaire requise :

Comme 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 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 fournit 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.