Je rencontre une anomalie de fonctionnement très étrange.
J’ai un micro-module Ubiwizz 2 canaux qui me sert à commander le fil pilote d’un radiateur. 2 diodes 1N4007 montées à l’envers l’une de l’autre sur chacune des sorties de l’Ubiwizz et dont les autres extrémités sont rassemblées sur un domino me permettent d’obtenir les 4 états de base d’un fil pilote mais là n’est pas mon problème car je ne m’occupe pour l’instant que des modes Confort (les 2 actionneurs ouverts et donc pas de tension), et Eco (les 2 actionneurs fermés me donnant la pleine alternance ).
J’ai défini un compteur qui quand il prend la valeur 2 doit me faire passer en mode Eco (donc mettre les 2 actionneurs sur « On ») et en mode Confort à 3 (donc mettre les 2 actionneurs sur "Off’)
Mon souci est le suivant : j’ai 2 scénarios quasiment identiques pour passer en Eco ou en Confort en fonction de la valeur du-dit compteur (copies d’écran ci-dessous).
Le compteur « FP couloir » est bien testé dans chaque et ce sont bien les 2 actionneurs 1 et 2 de mon Ubiwizz (unique pour l’instant) qui sont pilotés dans résultat.
Quand mes radiateurs sont en mode Eco et que je passe la valeur du compteur à 3, les actionneurs reviennent bien à « Off » et le radiateur passe bien en « Confort ».
Par contre si je passe la valeur du compteur à 2, les actionneurs ne basculent pas à « On » et le radiateur reste en Eco.
Cela se produit aussi bien quand je fais changer la valeur manuellement dans les périphériques et quand ce changement de valeur se fait via un scénario qui pilote d’autres radiateurs via un X-FP. Le passage d’Eco en Confort marche, mais pas de Confort en Eco. Le compteur prend pourtant bien la bonne valeur.
D’où peut venir ce pb ? Je sèche un peu…
Je ne pense pas que le fait que le scénario du mode Eco soit avant celui du mode Confort ait une incidence quand même ?
Tout avis d’un expert des scénariis et des compteurs sera le bienvenu.
Non je n’ai pas encore essayé et comme je ne suis plus chez moi pendant 15 jours ça va être moins facile. Je vais toutefois essayer de simuler avec des entrées et des sorties virtuelles en prenant la main à distance.
Mais je ne crois pas trop à cette hypothèse. En effet, la condition sur un compteur est à vrai si la valeur du compteur est supérieure ou égale à la valeur indiquée. Dès lors, pourquoi, quand le compteur passe de 3 à 2, les actionneurs Enocean restent dans la configuration comme s’il valait toujours 3 ? S’il y avait un problème d’ordre des scénarii vu que les tests sur 0 et 1 sont avant (dans l’ordre des scènes) on devrait passer en configuration 0 (Arrêt). Or ce n’est pas le cas les actionneurs restent ouverts comme quand le compteur valait 3. Comme si le changement de valeur n’était pas pris en compte…
Par contre si je passe manuellement le compteur à 2 et les 2 actionneurs à « On », un scénario qui le fait passer à 3 est pris en compte et les actionneurs basculent à « Off ».
Cela pourrait peut-être fonctionner si je n’avais qu’à gérer 2 « On » et 2 « Off » simultanés. Mais il y a aussi les valeur 0 et 1 qui doivent donner 1 « On » et 1 « Off » dans un sens ou dans l’autre pour accéder aux états « Arrêt » et « Hors Gel ».
Cela dit pour avancer je pourrais toujours tester cela pour voir si la bascule se fait bien entre « Confort » et « Eco » et pas uniquement de « Eco » à « Confort » comme actuellement. Ca me fera avancer.
En attendant, je vais faire des tests avec des sorties virtuelles et 6 scénarii équivalents à ceux qui devraient piloter mes Enocean.
Je viens d’analyser finement ce qui se passe en utilisant des sorties virtuelles et un autre compteur non utilisé.
Voilà ma conclusion.
Quand on part de 0 et que l’on fixe (directement par Périphériques, pas via un scénario) la valeur d’un compteur à une valeur supérieure (que ce soit 1, 2 ou 3 dans mon cas), le scénario correspondant s’exécute bien, les sorties virtuelles prennent bien l’état attendu. Il en est de même quelque soit la valeur dont on part du moment que c’est vers une valeur supérieure.
Par contre si on redescend à une valeur inférieure (de 3 à 2, ou 1, ou de 2 à 1, ou 0, ou…), le scénario correspondant ne s’exécute pas. Comme si la baisse de la valeur d’un compteur n’était pas considéré comme un événement pour le scénario, alors que la hausse, si !
L’équipe de @gce pourra peut-être nous dire si c’est normal, ou s’il s’agit d’un bug à corriger dans le moteur de scénario.
Je peux éventuellement faire des tests complémentaires si besoin.
Merci de votre réponse et de votre aide.
En attendant je vais essayer une solution temporaire de secours consistant à utiliser les valeurs 1, 2, 3 et 4 et à faire passer le compteur à 0 avant de le faire passer à une autre valeur dans mes scénarios qui la fixent (en espérant que la mise à 0 soit bien effectuée avant et que ce double changement soit bien considéré comme un événement quand on a 2 blocs de « Résultat »).
Je penche plutôt sur un problème dans la définition des conditions ().
Pour illustrer mon propos, prenons cette règle très simple (un compteur, une sortie virtuelle):
Si C2==1 ON/OFF SVX
que l’on aimerait traduire par SVX est ON si et seulement si C2 >= 1. Et c’est presque vrai. Tant que l’on ne joue qu’avec le compteur, la sortie virtuelle suit bien la règle.
Imaginons que que nous sommes dans la situation où C2 == 3, donc SVX == ON. Si on passe manuellement SVX à OFF, nous sommes désynchronisés par rapport à la règle.
Un passage de C2==2 ne rétablit pas la situation car l’évaluation si C2==1 n’a pas changé d’état (elle était vraie lorsque C2 == 3, elle reste vraie si C2 ==2) et donc l’action qui y est associée n’est pas déclenchée.
Ne serait-ce pas ce qui se passe dans les scènes 55 et 56 ?
Je comprends ce que tu veux dire, mais en l’occurrence, je ne fais que jouer avec le compteur bien sûr. Si je modifie les valeurs des sorties virtuelles c’est éventuellement pour les remettre dans l’état correspondant à la valeur du compteur.
Mais ton analyse est parfaitement juste. Si on repasse le compteur à une valeur inférieure les conditions de comparaisons avec des valeurs inférieures n’auront pas changé et ne déclencheront pas les actions correspondantes.
Je ne vois donc pas de solution sur la base d’un compteur.
La solution la plus simple serait, je pense, de faire un widget HTML comprenant 4 boutons envoyant des ordres de commutation des actionneurs Enocean par des commandes HTTP en Javascript. Mais je ne sais pour l’instant pas bien comment faire.
Je pense que je vais m’orienter vers une solution à base de 4 sorties virtuelles qui quand on en mets une à « On » bascule les 3 autres à « Off » et fait basculer les actionneurs.
j’utilise moi aussi un compteur comme événement de scène pour le fil pilote & délestage.
Cpt = 10 → Arrêt
Cpt = 11 → HG
Cpt = 12 → Eco
Cpt = 13 → Confort -2
Cpt = 14 → Confort -1
Cpt = 15 → Confort
ainsi si je consomme trop d’élec je baisse la valeur du compteur pour faire mon délestage.
Sauf que ça fonctionne pas super. Je pensais que le compteur n’était pas tjrs vu comme un changement d’événements mais je n’ai pas terminé mon diagnostique.
Je n’aide pas beaucoup j’en convient mais je pense qu’il y a bien un souci avec les compteurs dans les scénarios. @Maxime_gce vous avez tjrs l’accès à mon IPX pour constater si besoin.
Comme décrit précédemment par @Teebex et moi, cela doit bien fonctionner quand le compteur augmente mais pas quand il diminue. En effet dans ce cas si on passe de ta valeur 15 à 14 par exemple, le test sur la valeur 14 ne sera pas considéré comme ayant changé d’état car 15 >= 14 et 14 >=14 aussi. Donc l’action correspondante ne s’exécute pas.
Pour cela il faudrait repasser par une valeur très inférieure, puis remonter pour déclencher l’action. Mais je n’ai pas trouvé comment faire. Je me suis donc rabattu sur un pilotage via des Sorties Virtuelles : 4 SV correspondent aux 4 états de base Arrêt, HG, Eco et Confort et des scénarii pilotes les actionneurs Enocean en fonction des changements d’état des SV. Il y a 2 scénarii par état sauf pour Confort où tout se fait avec un seul : l’un met à Off toutes les autres SV et le ou les actionneurs voulu, l’autre met à On le ou les actionneurs requis.
J’ai en plus 2 scénarii pour prendre en compte le cas où on mettrait à Off la seule SV à On et selon l’état d’une Entrée Virtuelle indiquant l’occupation ou non de la maison, je mets la SV Confort à On en cas de présence et celle Hors Gel en cas d’absence. Avec le scénario basculant en HG quand l’indicateur de présence passe à Off, cela me fait 10 scénarii pour piloter 1 radiateur.
Vivement que GCE implémente la commande d’un module Fil Pilote Encocean pour alléger tout cela.
Par contre je suis curieux de savoir comment tu pilotes les états Confort -1° et Confort -2° si, comme moi, tu commandes tes radiateurs à l’aide d’un micro module Ubiwizz avec 2 diodes en sortie…
J’ai créer 24 Plages horaires d’une heure pour la semaine et 24 autres pour le weekend.
Ainsi je fait une programmation horaire (par palier d’une heure) des modes de chauffages. En fait je met en événement seulement les heures de basculement de mode, c’est donc le compteur qui mémorise le mode de chauffage les heures qui suivent le changement. A cela je dois ajouter un délestage, j’ai une faible puissance souscrite, le compteur me permet ainsi d’associer les deux: Une valeur par mode de chauffage et la décrémentation pour le délestage.
Je vais voir si je peux essayer de faire un reset compteur entre chaque opérations pour ce retrouver à chaque fois en incrémentation comme tu le préconises. Même si je pense que le mieux serai que @GCE clarifie l’utilisation du compteur en scénario. Je ne vois pas trop l’intérêt du fonctionnement actuel mais peux être y en a t’il un.
Et pour piloter tes radiateurs tu utilises une extension X-FP donc, je suppose… C’est ce qui te donne accès aux -1° et -2°.
Tu dois pouvoir t’en sortir en ajoutant un scénario de passage à 0 de ton compteur sur la plage horaire où tu souhaites redescendre qui soit situé avant tes scénarii qui testent la valeur du compteur et le scénario de passage à la valeur voulue (inférieure à celle initiale) après.
Ainsi, vu que les scénarii sont exécutés a priori dans l’ordre, lors du passage dans la plage horaire, le compteur sera mis à 0, le scénario changeant le pilotage du radiateur n’exécutera rien, puis le compteur sera passé à sa valeur finale et au prochain tour de manège la commande sera bien prise en compte (la RAZ ne devrait pas être réeffectuée puisque la condition avait déjà été vue à « vrai » au tour d’avant).
Seul pb qui pourrait survenir à mon sens, mais ce serait bien le comble, c’est que l’horloge change de plage horaire entre le test pour la RAZ et celui pour la mise à la valeur finale. Je ne sais pas comment sont gérés les tests : faits au moment de l’exécution du scénario ou au début de chaque « tour de manège ».
Peut-être que l’équipe de @GCE pourra nous renseigner sur ce sujet…
Oui j’utilise un X-4FP, c’est vrai que je n’en avait pas fait mention ! c’est top pour le -2 & -1°C qui permettent des économies sans impacts sur le confort.
Je vais attendre les précisions de GCE avant de faire des modifs, peux être y’a t’il une utilisation plus adapté du compteur.
En plus j’ai l’affichage du widget X-4FP s’efface au bout de quelques temps (assez long quand même, je le constate lorsque je quite l’ordi et que j’y reviens plus tard), tout les icônes sont gris, aucun n’est vert. Je m’aperçois que cela fait de même pour le widget thermostat, la valeur ana deviens incohérente. Alors que pour les widgets que j’ai fait en javascript avec source de donnée pas de soucis.
Je pensais les problèmes liés. Si l’actualisation est liée au compteur cela me réglerai deux problèmes d’un coup
Ok. J’ai également un X-FP pour mes radiateurs équipés de fil pilote. Mais un certain nombre n’en a pas, je ne peux pas le passer et ma seule solution est donc de passer par Enocean. Un micro-module 2 canaux et 2 diodes font l’affaire pour les 4 fonctions de base en attendant que GCE implémente peut-être un jour le pilotage d’un module Fil Pilote Enocean (ça existe je leur ai indiqué le produit, j’en parle dans ce post)
Pour l’affichage, je rencontre le même souci que toi. J’en ignore la cause, mais en général simplement en rechargeant la page tout se remet correctement à jour. Visiblement le widget perd l’info correspondante. C’est un peu désagréable mais pas bien gênant pour ma part car je ne suis pas connecté en permanence dessus donc à chaque nouvelle ouverture ça se remet correctement.
Ce n’est donc certainement pas lié à l’utilisation d’un compteur…
Pour forcer l’évaluation des conditions dans tous les cas je tenterais d’y inclure une sortie virtuelle (VOx) avec un TA=0 et un TB= 5/10 sec (qq chose de plus grand que 3/10 de secondes).
L’idée serait
de mettre à On VOx à chaque changement de valeur du compteur (est-ce possible ?)
de modifier les conditions par Si CX >= constante et NON VOx …
Ainsi, à chaque changement de valeur du compteur, toutes les évaluations deviennent fausses le temps du TB puis sont réévaluées lorsque VOx redevient OFF.
Maintenant je ne mesure pas les conséquences de ma proposition iconoclaste…
A tester. Juste une question : pourquoi 5/10e de secondes ? 0,3 secondes c’est le temps que l’IPX mettrait à parcourir l’ensemble des scenarii ?
Pour l’instant j’ai pris la solution des 4 SV qui marche très bien (mais qui en consomme 4 par radiateur ou groupe de radiateurs). La tienne peut être plus économique de ce point de vue.
Merci @PatLeHibou, j’aime les gens qui veulent comprendre
J’ai lu dans le forum (mais où mon Dieu) qu’il était raisonnable d’estimer que les règles étaient évaluées 3 fois par seconde au moins, en fonction du nombre de règles et de leur contenu.
J’ai traversé le parcours donc si je rate quelque chose n’hésitez pas
Les compteurs fonctionnent avec un seuil (la valeur), l’événement passe à ON lorsque le compteur est supérieur ou égale au seuil et à OFF quand il est strictement inférieur.
Concrètement en passant de 3 à 2 votre scène avec un seuil à 2 reste à ON tout du long donc pas de ré-activation de la scène. Il faudrait passer à 1 puis à 2 pour relancer l’action.
Sur plus de 2 ordres il faudra faire attention à ne pas activer plusieurs scène :
ordre à 2-3-4-5, on veut activer la 5 → cpt à 5. On veut activer la 2, cpt à 0 puis à 2 → pas de soucis.
Par contre cpt à 5 on veut passer à 3, si on fait cpt = 0 puis cpt = 3 la scène 2 sera également réactivé ! Il faudrait faire 5-2-3.
Bref à étudier mais ce n’est pas la chose la plus naturel à faire avec le fonctionnement du moteur de scénario. Si @Kevin_GCE a un peu de temps à y consacrer il essaiera de regarder comment tout ça peut se combiner.
Sinon n’hésitez pas à investir dans un X-4FP Malheureusement je pense que dans votre cas l’utilisation de l’Enocean doit vouloir dire : « pas possible de passer du câble ! ».
Bon courage et n’hésitez pas à partager la solution quand vous l’aurez
Ma solution de secours ne peut pas marcher car on ne peut pas avoir 2 compteurs en résultat d’un scénario ! 
).
