Plans de déclenchement

Un plan de déclenchement organise moment de vérification, conditions et actions en règles réutilisables.

Structure d’un plan

Un plan peut contenir plusieurs déclencheurs, chacun avec conditions et actions. Les conditions se combinent par AND / OR. Le plan peut être activé ou désactivé et recevoir une période globale de validité.

Condition	Usage
CRON	Exécuter selon un calendrier
TIME_POINT	Exécuter à une heure quotidienne définie, éventuellement limitée aux dates du plan
TIME_PERIOD	Vérifier pendant une plage temporelle donnée
INTERVAL	Vérifier à intervalle fixe
DATA_CHANGE	Calculer la condition lors d’un changement de point, y compris partagé

Un script de condition de données renvoie un booléen. Traitez explicitement les absences ou utilisez d’abord tonumber, afin de ne pas les considérer comme des observations valides.

Actions et valeurs de retour

Les actions peuvent écrire des points inscriptibles, programmes horaires, variables agrégées ou équipements distants, mais aussi enregistrer une alarme, soumettre une observation d’alarme ou publier en MQTT.

Plan ou scénario	Retour du script
Plan EXPRESSION	Tableau d’actions indexé à partir de 1
Écriture d’un point MIXED	Valeur unique du point correspondant
Condition de changement de données	true / false

Exemple de mise à jour d’une variable agrégée d’exécution dans une action EXPRESSION :

return {buildGeneralWriteMap("Aggregation", "demo_state", "ready", false)}

Remplacez le point d’exemple par un point réellement configuré. La fonction construit seulement une action à exécuter, sans confirmer la réussite sur l’équipement.

Règles d’alarme

Une notification simple peut générer des enregistrements individuels. Pour un cycle de rétablissement et de traitement, utilisez les événements d’alarme en signalant continuellement ACTIVE, NORMAL ou UNKNOWN, et pas uniquement les anomalies.

Post-traitement et traces d’exécution

Les actions acceptent un post-traitement via needPostProcess / postProcessContent. La validation peut vérifier la structure de retour, mais l’expression est évaluée : vérifiez d’abord les effets de bord des scripts contenant des appels directs.

Les enregistrements de déclenchement permettent de vérifier conditions, résultats et erreurs. Pour le contrôle, consultez aussi les journaux de contrôle et relisez les points, afin de distinguer envoi et exécution réelle.

Équipements dynamiques et activation des plans

Les requêtes par préfixe, suffixe ou autres critères gèrent un nombre variable d’équipements. Les requêtes par lot renvoient une table indexée par dataKey, à parcourir avec pairs(). Vérifiez l’exhaustivité des dépendances des motifs construits dynamiquement. Les points concernés peuvent être déclarés dans le plan ; leur valeur courante apparaît dans le détail pour éclairer la stratégie.

Les plans désactivés, supprimés ou expirés déchargent leurs tâches d’exécution et vérifient l’état du plan parent avant exécution. Les commandes déjà envoyées doivent toujours être vérifiées sur l’équipement. Limitez au besoin la fréquence des stratégies pour réduire les envois répétés.

Consultez Référence des actions et Référence Lua pour les scripts, ou le Skill de plans de déclenchement pour la configuration par agent.