Bonjour,
Je créé ce poste pour donner mon point de vue sur le futur des automatisations dans le plugin Light Group. Ce poste vous permet de donner votre avis afin que nous puissions construire ensemble des automatismes plus puissant.
Tout d’abord un petit état des lieux:
- La gestion d’instance d’automatisme en tâche
Il est possible de définir depuis le plugin des automatismes. Ces automatismes peuvent être affecté à des lumières créant ainsi des couples d’automatisme-lumière.
Lorsque toutes les conditions d’un automatisme sont positive, une instance d’automatisme est créée pour chacun des couples automatisme-lumière.
Une instance d’automatisme est donc considérée comme active lorsque toutes les conditions de déclenchement sont positives.
Une instance d’automatisme s’arrête et devient non active si elle était active et qu’au moins une des conditions de déclenchement est négative.
Un même couple d’automatisme-lumière peut créer plusieurs instances d’automatismes avec la règle que chaque nouvelle instance vient remplacée l’ancienne.
Un petit exemple:
J’ai définis un automatisme de présence lumineuse avec deux capteurs de présence. Lorsque l’automatisme s’arrête, la lumière reste allumée 30 secondes L’un des capteurs passe à 1
→ L’instance d’automatisme devient active
Le capteur auparavant à 1 passe à 0 et tous les capteurs sont donc à 0
→ la lumière reste allumée car nous restons dans le temps tampon. A la fin des 30 secondes, la lumière s’éteindra et l’automatisme deviendra inactif
Le deuxième capteur passe à 1:
→ Une nouvelle instance d’automatisme est créée et vient remplacer l’ancienne. la lumière reste allumée. L’ancienne instance d’automatisme est invalidée et n’éteindra plus la lumière passée les 30 secondes.
- La priorisation des couples lumière-automatisme
Il est possible d’affecter plusieurs automatismes à une même lumière créant ainsi plusieurs couples de lumière-automatismes. Nous pouvons donc nous retrouver dans le cas suivant:
→ Toutes les conditions de A sont positives
->L’instance A s’active (la lumière s’allume)
→ Toutes les conditions de B sont positives
→ L’instance B s’active (la lumière s’allume)
→ Une des conditions de B est négative
→ L’instance B se désactive (la lumière s’éteint)
Cependant nous pourrions vouloir que tant que A est actif, B ne puisse pas s’activer. Afin que la lumière ne s’éteigne pas alors que A est toujours actif.
Pour répondre à ce problème, il sera bientôt possible de prioriser les automatismes entre eux. Cette priorisation sera comprise entre 1 et 1000 et sera unique pour chaque instance.
Reprenons l’exemple ci dessus avec A une priorisation de 500 et B une priorisation de 200.
→ L’instance A s’active
→ Toutes les conditions de B sont positives
→ B possède une priorité inférieure à A
→ B ne s’active pas
Maintenant vient un autre cas toujours avec A et B, A priorisation 500, B priorisation 200.
→ L’instance B s’active
→ Toutes les conditions de A sont positives
→ A possède une priorité supérieure à B
→ A s’active et B se désactive
→ Au moins une des conditions de A est négative
→ A se désactive
Pour ce cas la, la lumière s’éteint alors que les conditions de B sont toujours positives.
Je propose que la désactivation de A entraîne la réactivation de B ce qui nous donnerais
→ L’instance B s’active
→ Toutes les conditions de A sont positives
→ A possède une priorité supérieure à B
→ A s’active et B se désactive
→ Au moins une des conditions de A est négative
→ A se désactive et réactive B
→ Au moins une des conditions de B est négative
→ B se désactive
Que pensez vous de cette gestion de priorisation des instance de couple lumière-automatismes ?
Par défaut les instances auront une priorité de 500. Si jamais deux instances s’activent avec la même priorité, la gestion sera comme avant.
