Les scénarios

Configurateur>>Scénarios>>Actions>>Liste 1ière Partie/2ième Partie/3ième Partie/4ième Partie>>Variables


CETTE PAGE FAIT PARTIE D'UNE DOCUMENTATION.

ELLE EVOLUE EN PERMANENCE ET NE DOIT PAS ETRE DUPLIQUEE. FAITES Y PLUTOT REFERENCE !


Les scénarios permettent de rendre automatique l'exécution d'une suite de commandes/actions en fonction d'événements déclencheurs appelés STIMULI. Un scénario est donc essentiellement un couple [événement, actions engendrées par l'apparition de cet évènement].

Un exemple de scénario avec sa structure est donné ici.

ZIBASE gère 125 scénarios au maximum.


Visibilité

 

Un scénario possède un nom (label), une icône associée, et  une certaine visibilité (exemple ici):

- Par ZIBASE. S'il n'est pas visible, il est dit "Suspendu" et ZIBASE ne pourra pas l'exécuter.

- Par utilisateur via PC/smartphone/tablette. S'il est visible, l'icône sera représentée et son exécution pourra être lancé directement par l'utilisateur.

- Par l'interface informatique ZAPI (ZiBASE API), auquel cas, le label du scenario pourra servir pour le lancer, sinon seul son numéro interne sera utilisable. Cette option doit être cliquée à minima et n'est ordinairement pas très utile.


Stimuli

 

Les STIMULI sont de différentes natures, propres à l'environnement domestique ou non (exemple ici):

- Le démarrage de ZIBASE, ou son redémarrage suite à la prise en compte d'une nouvelle configuration domotique,

- Un événement lié au temps, c'est à dire par exemple une date, un jour de la semaine, un timer périodique, le lever ou le coucher du soleil. Les différentes possibilités sont exposées ici,

- Un signal provenant d'un périphérique:  detecteur, capteur, télécommande, et même certains actionneurs.

- Une liste d'IDs. Cette liste est constituée d'un ou plusieurs mots clés appelés IDs (IDentifiants).  Ils apparaissent ordinairement dans le suivi d'activité en fin de ligne après ":"

- L'intervention de l'utilisateur à partir d'un PC/smartphone/tablette, mais ce cas est en réalité traité par la visibilité. Ce cas n'est pas soumis aux critères, lesquels ne peuvent donc pas réaliser de filtrage. Il en est de même si le scénario est lancé à l'initiative d'un autre scénario.

Un stimulus est un événement qui peut toujours être daté avec son apparition:  Il n'a pas de durée.  Ce n'est pas un état durable. Il déclenche le scénario à des moments précis dans le temps et lors de ses apparitions.


Critères  (optionnels)

 

A l'apparition du stimulus, des conditions (appelées aussi CRITERES)  peuvent être évaluées dynamiquement pour savoir si le scénario doit être effectivement lancé. Ces conditions réalisent donc un filtrage des STIMULI.

Les conditions se basent sur l'état du système et de son environnement, et donc un ensemble d'états élémentaires qui a la possibilité d'être testé. La majorité de ces états est puisée dans le fichier http://<zibase-ip>/sensors.xml. Contrairement à un événement, un état s'inscrit sur une durée. Sa comparaison à une valeur fait que que le résultat est VRAI ou FAUX.

Le scénario est lancé seulement si les conditions spécifiées sont vraies. La condition peut être simple ou multiple, auquel cas, les sous-conditions sont reliées par un opérateur logique (ET/OU/XOR) et évaluées les unes après les autres. Voir exemple ici.

Il peut être nécessaire d'avoir des priorités dans l'évaluation des conditions, ce qui revient à avoir des niveaux de parenthèses. Des blocs de conditions, évalués indépendamment et qui correspondent donc à un niveau de parenthèses, peuvent ainsi être reliés à nouveau par des opérateurs logiques. Voir exemple ici avec 3 blocs.


Actions

 

Les actions sont exécutées (en séquence) si :

- Le scénario n'est pas suspendu (ou si le scénario n'a pas son propre compteur de tickets égal à 0 )

- un stimulus est arrivé,

- Les critères éventuels ont été satisfaits.


Temps d'exécution des scénarios:

A l'instar d'un événement, l'exécution d'un scénario n'a en théorie pas de durée et doit être considérée comme infiniment rapide. En pratique, Le temps d'exécution est de l'ordre de la centaine de millisecondes mais sera allongé par des opérations entrées/sorties Radio ou Internet/IP  susceptibles d'être beaucoup plus coûteuses en temps. Il en est de même pour l'écriture de variables sauvegardées en mémoire non volatile.

Par exemple,  vis-à-vis d'Internet,  des appels HTTP peuvent avoir été réalisés (on attend alors la fin de l'appel HTTP). Des traces synchrones peuvent avoir été laissées (listing de variables dans le configurateur).

L'émission de trames radio prend du temps et peut être retardée par le canal radio* :
1) Dont la probabilité d'être toujours occupé est grande. Ainsi si une trame est reçue sur un protocole où classiquement l'échange d'informations  est constituée une salve de 3 trames de 0,5s identiques et séparées d'une seconde. La première trame sera très vite envoyée au moteur domotique et celui ci rendra sa réponse en 0,1s  (qui sera pour l'exemple une commande d'actionneur A). Mais le processus chargé de l'émission de la réponse attendra "1s+Epsilon"  après la fin de la 3ième trame de la salve avant de songer à émettre la commande de l'actionneur A.

2) Effectivement occupé. ZIBASE dispose d'un mécanisme de LBT ("Listen Before Talk") qui écoute le canal radio avant d'y faire une émission.

Les 2 mesures ci-dessus visent à sécuriser le fonctionnement de l'installation domotique, mais ceci se fait au détriment de la rapidité. En pratique, sans ces mesures, il est possible d'obtenir 100% d'échec car les trames entrantes et sortantes se trouvant systématiquement en collision, le moteur domotique s'appliquant à créer cette collision par une trop grande célérité.

* Les protocoles ZWAVE et ENOCEAN ont des temps de transmission de trames très courts, ce qui leur confèrent une rapidité mais aussi une fragilité vis à vis des autres protocoles (lors de collisions) . Dans le cas de ZWAVE, le maillage d'un nombre important de noeuds augmente la sécurité de transmission, mais provoquent aussi des ralentissements très considérables, d'autant plus si ce maillage n'est pas optimisé.


Particularités :

- Les scénarios sont exécutés en séquence de manière indivisible et cela quelque en soit la source de déclenchement . Les actions d'un scénario A ne peuvent donc s'entremêler dans leur exécution avec celles d'un scénario B.

- Si un scénario A appelle un scenario B, la totalité des actions de A sera exécutée avant celle de B.

- Techniquement, afin de maximiser l'efficacité du moteur de scénarios, celui-ci fonctionne autant que possible de manière asynchrone, c'est à dire qu'il envoie ses résultats dans des files d'attente qui seront vidées à leur rythme par d'autres processus.

 

Remarques :

Il n'est pas toujours aisé de mettre au point des scénarios. Arrive un stade où le "debug" est nécessaire.


il est important de comprendre organiquement comment fonctionne le moteur de scénarios:

- Saisir essentiellement  la différence entre un évènement (STIMULI) et un état annexe du système (servant dans le filtrage par les CRITERES).

- Saisir le phénomène de "cause à effet". La cause est l'apparition d'un stimulus filtré par des conditions/critères, l'effet est l'exécution de commandes/actions.


L'objectif n'étant pas faire apprendre un langage informatique à l'utilisateur, la syntaxe de l'interpréteur de commandes a donc été masquée par une présentation graphique" par actions" où l'utilisateur doit seulement spécifier des arguments (sans se soucier d'une syntaxe générale).

Au niveau de l'approche générale, il n'est pas recherché une vision graphique de haut niveau et abstraite avec des ambiguïtés sémantiques (syndrome de "simple de loin mais loin d'être simple") où justement on ne comprend pas le fonctionnement interne, car on ne sait plus "ce qui filtre" ni "ce qui déclenche". L'utilisateur n'a alors plus les clefs pour comprendre ce qui se passe au juste :  Si cela ne marche pas du premier coup, il n'a plus de recours pour comprendre pourquoi.

ZIBASE n'est jamais muette, elle possède un suivi d'activité très vivant où les principaux événements apparaissent en temps réel. Ceci permet d'avoir une approche dichotomique dans la résolution de problèmes.