Lever/coucher du soleil - ouverture/fermeture des volets

[Eric Panetta]

Bonjour à tous,

Voici mon deuxième post en tant que nouvel utilisateur de knxweb/linknx. Donc toutes mes excuses dans le cas où mes questions seraient dignes de noobs...

J'a créé deux scénarios qui permettent d'ouvrir/fermer automatiquement mes volets au lever/coucher du soleil, si je suis absent. Dans ce cas, cela m'envoie un mail pour me prévenir... Pour l'instant en période de tests, lorsque la condition est fausse (autrement dit, si je suis présent à la maison), je souhaite tout de même recevoir un mail, pour m'assurer que la règle a bien été évaluée...

Ce qui est bizarre, c'est que ce matin, j'ai reçu les deux mails... Autrement dit, la règle a exécuté les actions "if-true" ET "if-false"... Ce qui est plus que bizarre...

Donc soit j'ai mal compris comment faire les règles (ou j'ai un souci dans mon timer), soit j'ai un bug d'install/configuration... Toute aide serait la bienvenue !

Je vous mets une capture d'écran de ma règle, ce qui sera parlant :

[Anthony PENHARD]

Salut,

il n'y a aucune questions de "noobs"
il faut bien démarré un jour tout le monde est passé par là et il a surement des endroits/moments (j'ai) pas été clair ...

alors c'est "normal" les 2 mails vu ta rule

le "soucis" viens du type d'action les "if-true et if-false" qui fait ça :
sur le principe lors de l'heure de "sunrise" + 15 minutes avec le trigger cela vérifie la rule et donc si Présence "on" va ouvrir les volets

puis une seconde plus tard l'heure change et donc la rule est réévaluer et comme maintenant vaut "false" envoi e mail "non automatique"

si tu met les actions "on-true et on-false" cela n’exécutera que quand "sunrise +15m" arrive cela test la rule et là envoi les action true ou false et après c'est fini

PS pourquoi as-tu mis des delay dans tes actions ça ne sert a rien surtout 1 à 6 ce sont des millisecondes de différences ??

@+

Anthony.

--
Vous recevez ce message, car vous êtes abonné au groupe Google Groupes "Eibd / Linknx / KnxWeb".
Visitez ce groupe à l'adresse https://groups.google.com/group/eibd-linknx-knxweb.

[Eric Panetta]

Salut,

Merci pour ta réponse rapide...

J'avais effectivement lu le wiki de linknx et j'ai vu qu'il y avait les actions if-true/false et on-true/false, mais j'avoue que je n'avais pas saisi la différence entre les deux...

Donc, si je comprends bien : là je dois utiliser "on-true/false" car, comme ma règle met "du temps" à s'exécuter, en cours d'exécution la condition d'entrée change et donc la règle est réévaluée... En utilisant l'action "on-true/false", si les conditions changent "en cours d'exécution de la règle", la règle n'est pas rééxécutée... C'est ça ?

Pour le délai pour mes volets, c'est simplement que la première fois que je l'ai testée, il n'y a qu'une partie de mes volets qui ont été ouverts, j'ai supposé que c'était parce que toutes mes trames KNX partaient en même temps ou presque, et qu'il y avait conflit, et donc certaines instructions n'étaient jamais reçues... Donc j'ai décalé de 1 seconde (c'est bien des secondes :) ) entre chaque ordre...

En réalité, j'ai une scène (dans mes modules KNX) qui ouvre ou ferme tous mes volets en même temps. Mais je ne sais pas pourquoi, j'ai un de mes modules KNX qui se vautre de temps en temps, et fait n'importe quoi... Ce n'est pas systématique, mais parfois je crois que tous mes volets sont ouverts et en fait non... Du coup, n'ayant pas eu le temps de trouver l'origine du souci, je préfère envoyer un ordre direct à chaque volet...

[Anthony PENHARD]

Salut,

Donc, si je comprends bien : là je dois utiliser "on-true/false" car, comme ma règle met "du temps" à s'exécuter, en cours d'exécution la condition d'entrée change et donc la règle est réévaluée... En utilisant l'action "on-true/false", si les conditions changent "en cours d'exécution de la règle", la règle n'est pas rééxécutée... C'est ça ?

en fait les actions "on-true/false" ne sont éxecutée que sur changement d'état des condition dans ton cas que à l'heure précise du lever du soleil + 15m et plus ensuite

alors que les actions "if-true/false" cela va s'exécuter lors du lever mais aussi lorsque la date est dépasser car là la condition change d'état

c'est pas simple a expliquer le fonctionnement ...

 

Pour le délai pour mes volets, c'est simplement que la première fois que je l'ai testée, il n'y a qu'une partie de mes volets qui ont été ouverts, j'ai supposé que c'était parce que toutes mes trames KNX partaient en même temps ou presque, et qu'il y avait conflit, et donc certaines instructions n'étaient jamais reçues... Donc j'ai décalé de 1 seconde (c'est bien des secondes :) ) entre chaque ordre...

là cela peut être normal que tous ne se soit pas ouvert si tu n'as pas fait toute la config dans ETS pour tes modules volets

il faut bien gérer les retour d'état et aussi les temps de monté/descente "réel"

je pense que linknx devait avoir le "mauvais" état sur les objects de commande d'ouverture si tu envoi "off" sur une object et que linknx a déjà cette valeur en "memoire" alors par défaut la valeur n'est pas envoyé sur le bus

pour forcer linknx a envoyé même si identique il faut ajouter le flag "f" à l'object (fait le sur tous tes objects de commande volet comme ça tu sera tranquille)

et donc lors de l'exectution d'une rule par exemple renverra la commande même si linknx a en mémoire cette valeur

et je ne sais plus si c'est 1 secondes par défaut ou ms moi dans le doute je met toujours 1s ou 1ms ...

 

En réalité, j'ai une scène (dans mes modules KNX) qui ouvre ou ferme tous mes volets en même temps. Mais je ne sais pas pourquoi, j'ai un de mes modules KNX qui se vautre de temps en temps, et fait n'importe quoi... Ce n'est pas systématique, mais parfois je crois que tous mes volets sont ouverts et en fait non... Du coup, n'ayant pas eu le temps de trouver l'origine du souci, je préfère envoyer un ordre direct à chaque volet...

peut-être dû a ce que je disais plus haut la config des retour d'état et de commande des volets

@+

Anthony.

 

[Eric Panetta]

Salut,

Merci pour ta réponse. J'ai pris le temps de faire des tests et d'essayer de comprendre enfin la différence entre if-true/false et on-true/false d'après les exemples du Wiki de linknx... D'où ma réponse "tardive"

 

en fait les actions "on-true/false" ne sont éxecutée que sur changement d'état des condition dans ton cas que à l'heure précise du lever du soleil + 15m et plus ensuite

alors que les actions "if-true/false" cela va s'exécuter lors du lever mais aussi lorsque la date est dépasser car là la condition change d'état

c'est pas simple a expliquer le fonctionnement ...

Donc (en espérant que cela puisse servir à d'autres), de ce que j'ai compris du Wiki de linknx, les actions if-true/false seront toujours exécutées. Par exemple, si le résultat est "toujours" true, à chaque itération du test, l'action "true" est effectuée. Par contre, les on-true/false ne sont exécutées que quand le résultat du test change. Si le test est 1000 fois true et ensuite mille fois false, l'action on-true n'est exécutée que la première fois des 1000 tests true, et l'action on-false n'est exécutée que la première fois que le résultat passe à false (et les 999 autres fois d'affilée où c'est faux, il ne se passe rien).

Si je prends un exemple : supposons qu'un test soit exécuté toutes les minutes, qui envoie un message "l'heure est paire" si elle est paire et "l'heure est impaire" si non. Si les actions sont positionnées sur "if-true/false", un message sera envoyé toutes les minutes disant "l'heure est paire/impaire" en fonction du résultat. Si par contre l'action est définie sur "on-true/false", il n'y aura qu'un seul message qui sera envoyé, au changement d'heure. A 14 heures, un message "heure paire" sera envoyé, puis plus rien jusqu'à 15 heures où un message "heure impaire" est envoyé, et ainsi de suite... J'ai bon ?

Du coup, ce n'est pas cela qui va me donner une solution pour ma problématique. Le problème étant que le "trigger" est exécuté à chaque changement de valeur, et donc ma condition est forcément réévaluée 1 minute après le lever/coucher du soleil, et à ce moment elle sera forcément fausse, et donc l'action "fausse" sera effectuée.

La solution serait que linknx puisse gérer des triggers de manière plus fine : pas uniquement à "tous les changements d'état", mais aussi les "front montant" et "front descendant", ne déclencher le trigger que quand on passe à "on" ou que quand on passe à "off". Est-ce qu'il y a un endroit où on peut faire une feature request pour linknx ? ;-)

Et tant qu'on est dans les feature requests, je me rends aussi compte que les interfaces de gestion des rules dans knxweb ne sont pas aussi fines que ne le permettent les règles XML de linknx... En XML (ce qui est d'ailleurs fait dans les exemples du Wiki linknx), on peut cumuler des actions if-true, if-false, on-true et on-false dans la même règle. Alors, je n'ai pas de cas d'usage précis dans lesquels il est intéressant de cumuler une partie de ces actions, mais knxweb ne permet que de faire des combo if-true/if-false et on-true/on-false, mais pas de mixer... Je pense que le besoin est limité, et surtout pas urgent, mais ça pourrait être quelque chose à rajouter à l'occasion dans la to do list... ;-)

là cela peut être normal que tous ne se soit pas ouvert si tu n'as pas fait toute la config dans ETS pour tes modules volets

il faut bien gérer les retour d'état et aussi les temps de monté/descente "réel"

je pense que linknx devait avoir le "mauvais" état sur les objects de commande d'ouverture si tu envoi "off" sur une object et que linknx a déjà cette valeur en "memoire" alors par défaut la valeur n'est pas envoyé sur le bus

pour forcer linknx a envoyé même si identique il faut ajouter le flag "f" à l'object (fait le sur tous tes objects de commande volet comme ça tu sera tranquille)

et donc lors de l'exectution d'une rule par exemple renverra la commande même si linknx a en mémoire cette valeur

Intéressant... C'est vrai que j'ai appris comment utiliser ETS sur le tas, et j'ai toujours laissé les flags des objets à leurs valeurs par défaut... J'essayerai d'affiner cela à l'occasion, en espérant que cela règle mes 2-3 petits soucis...

Par contre, en attendant, pour tester, au lieu d'envoyer la commande on/off sur les volets, j'ai testé en commandant leur valeur absolue en pourcentage (et là je suis sûr que linknx a les bonnes valeurs en mémoire, j'ai vérifié avant d'exécuter la règle).

Et si j'envoie les commandes en même temps, il n'y a que 2/3 volets qui réagissent. Si je décale l'ordre d'une seconde à chaque fois, tous les volets répondent à l'ordre... Je continue à pencher pour une "saturation" des messages sur le bus...

 

et je ne sais plus si c'est 1 secondes par défaut ou ms moi dans le doute je met toujours 1s ou 1ms ...

En fait, je crois qu'il y a un "bug" d'affichage sur les règles v2. J'ai bien mis "1s", et linknx.xml est juste. Mais les règles v2 affichent la valeur, mais pas l'unité. Dans les règles v1, lorsque je vais dans les propriétés des actions, j'ai bien l'unité "s", mais pas dans les règles v2... 

A+

Eric

[Anthony PENHARD]

Salut,

> La solution serait que linknx puisse gérer des triggers de manière plus fine : pas uniquement à "tous les changements d'état", mais aussi les "front montant" et "front descendant",
> ne déclencher le trigger que quand on passe à "on" ou que quand on passe à "off".

c'est bien le cas la rule n'est déclenché que sur changement d'état
quand tu as les action "On-true/false"

> Est-ce qu'il y a un endroit où on peut faire une feature request pour linknx ? ;-)

oui c'est possible sur git : https://github.com/linknx/linknx

> Et tant qu'on est dans les feature requests, je me rends aussi compte que les interfaces de gestion des rules dans knxweb ne sont pas aussi fines que ne le permettent les règles XML de linknx...
> En XML (ce qui est d'ailleurs fait dans les exemples du Wiki linknx), on peut cumuler des actions if-true, if-false, on-true et on-false dans la même règle. Alors, je n'ai pas de cas d'usage précis
> dans lesquels il est intéressant de cumuler une partie de ces actions, mais knxweb ne permet que de faire des combo if-true/if-false et on-true/on-false, mais pas de mixer... Je pense que le
> besoin est limité, et surtout pas urgent, mais ça pourrait être quelque chose à rajouter à l'occasion dans la to do list... ;-)

je n'ai jamais testé les
types On et If ensemble après dans la même rule c'est pas super
logique mais pourquoi pas

@+
Anthony.