Bonjour, suite au post : Déclenchement de scénario intempestif , j’ai eu le même problème, mais maintenant, si je redémare jeedom, tout les scénarios liés à des interrupteurs type single_click ou autre click s’active …, de même si je modifie des paramètres sur un appareil se trouvant sur le hub zigbee/tuya…
Ca peut etre aussi un vrai foutoir quand on a plein d’interrupteurs de ce type, et que demon ou le raspberry redémarre par exemple…
une solution?
merci
Pas de solution via le plugin, ce dernier interroge l’état des périphériques au démarrage et régulièrement et cette fonctionnalité ne peut être enlevée.
Le plus simple est lors d’un redémarrage, de positionner une variable à une valeur dans le scénario de démarrage (start) de faire une pause suffisante ou un « Dans » et de la positionner à une 2ème valeur.
Ensuite conditionner les autres scénarios au positionnement de cette 2ème valeur.
Désolé mais je n’ai pas tout compris… Quel autre valeur ou variable je pourrais mettre? Désolé mais je débute dans jeedom, et ces Interrupteur je bute grave dessus en cas de redémarrage de jeedom …
Un exemple s’il te plaît ?
la doc jeedom explique la notion de variable (positionner = affecter une variable)
ainsi que Dans
Ce que j’explique consite pour les scénarios qui posent problème à n’agir que si une variable a une certaine valeur par exemple 1
le scénario start met cette variable à 0 au démarrage, ce qui fait que le scénario saute les instructions qui ne doivent pas être exécutées, puis au bout d’un temps à déterminer la met à 1, ce qui autorise l’exécution des dite instructions
Ok, je vois à peut près, sinon ce que j’ai fais hier soir c’est de désactiver les scénarios qui pose problème au démarrage start, et de les réactiver… Solution valable? Et pour le démon, si il redémarre? Merci de votre aide mais ça va en aider d’autres dans l’avenir…
pareil, il faudra penser à mettre dans start les scenarios à désactiver.
le démarrage du demon ne doit pas poser de problème en enlevant la répétition des commandes
C’est a dire? que faut-il faire si il redémarre? merci
Salut valentinfr, j’ai exactement les mêmes problèmes que toi.
Pour ma part j’utilise un bloc à 4 switchs ZigBee, dont chacun gère 3 états ( single_click, double_click ou long_press).
J’utilisais ce switch avec SmartLife pour piloter des scénarios d’ouverture/fermeture de groupes de volets roulants.
Depuis mon passage à Jeedom et l’excellent plugin WifilightV2, je n’ai toujours pas pu retrouver l’exploitation de mon switch comme avec SmartLife.
Avec WifilightV2, à chaque sauvegarde de paramètres de n’importe quel équipement (du plugin) l’état est systématiquement intérrogé et idem au démarrage/redémarrage du Deamon.
Dans mon cas c’est 4 états de switch qui s’activent en même temps et donnent des ordres et contre ordres à mes volets roulants.
J’avais bien pensé à insérer une variable dans mes scénarios pour éviter ces désagréments, mais n’y suis pas arrivé puisque je voudrais que seul mon action d’appuyer sur un des switchs « valide » l’état de celui-ci et lance le scénario concerné.
Autre chose, mes volets Bubbendorf (moteurs MG + module LoraTap Tuya) fonctionnement en mode séquentiel (un appuis = montée ou descente automatique, un nouvel appuis stop le cycle).
Pour cette raison, j’ai du modifier la commande de chacun des états des switchs tel que :
Gestion de la répétition des valeurs = Toujours répéter
Ca ma permet de pour lancer un scénario d’ouverture de tous mes volets (single_click du dps_1_MODE) et de pouvoir l’arréter avec la même commande et ensuite de la relancer pour finalement ouvrir complètement mes volets. Ceci fonctionnait bien avec SmartLife, dommage qu’avec ce très bon plugin l’interrogation de l’état automatique et en dehors d’une action physique sur les switchs, posent problème.
Je me suis demandais s’il ne serait pas possible d’interdire l’intérrogation automatique de l’état d’un équipement par un filtrage ip tant que l’action n’est pas physique (j’appuis sur le switch) ?
voilà ce que j’aimerais éviter lors d’une sauvegarde ou redémarrage du Deamon :
[2021-02-11 10:27:08][DEBUG] : Receive from:192.168.x.xx (No learning mode) -(ip masque par moi)
[2021-02-11 10:27:08][DEBUG] : >> Receive after decode :{"dps":{"1":"single_click","2":"single_click","3":"single_click","4":"single_click","10":100},"cid":"5c0272fffea16b23"}
[2021-02-11 10:27:08][DEBUG] : Search if Zigbee device exists:
[2021-02-11 10:27:08][DEBUG] : found Zigbee:SwitchX4
[2021-02-11 10:27:08][DEBUG] : Dps1|dps_1_MODE:single_click Dps2|dps_2_MODE:single_click Dps3|dps_3_MODE:single_click Dps4|dps_4_MODE:single_click Dps10|dps_10_VALUE formula:#value# #value#:100 After:100
[2021-02-11 10:27:08][DEBUG] : No other states to update
là c’est quand j’appuis sur l’un des switchs :
[2021-02-11 10:30:37][DEBUG] : Receive from:192.168.x.xx (No learning mode) -(ip masque par moi)
[2021-02-11 10:30:37][DEBUG] : >> Receive after decode :{"dps":{"1":"single_click"},"cid":"5c0272fffea16b23","t":1613035837}
[2021-02-11 10:30:37][DEBUG] : Search if Zigbee device exists:
[2021-02-11 10:30:37][DEBUG] : found Zigbee:SwitchX4
[2021-02-11 10:30:37][DEBUG] : Dps1|dps_1_MODE:single_click
[2021-02-11 10:30:37][DEBUG] : No other states to update
c’est bien ce que fait la non répétition des commandes. je m’explique : lors de l’appui sur le bouton, ou lors de l’interrogation de l’état toutes les minutes, lors de la sauvegarde d’un périphérique ou lors du redémarrage du demon, le plugin modifie l’état de la télécommande en écrivant dans le xxxGet. Si la valeur avant écriture est l même qu’après, l’évènement de modification de l’état n’est pas généré et le scénario n’est pas déclenché.
Les soucis demeurent probablement lorsque plusieurs télécommandes son utilisées et lors du démarrage (mais ça c’est le fonctionnement de Jeedom).
Donc mettre l’option de répétition de la commande à jamais pour toutes les télécommandes mais aussi pour les éventuels virtuels.
Notez que j’utilise une télécommande lora tap ( click, single-click et double-click) et qui me posait ce souci, depuis j’ai mis les répétitions à Jamais, je n’ai plus aucun souci lors de la sauvegarde d’un périphérique.
Donc regardez déjà ce qui déclenche le scénario, via les logs lors de la sauvegarde d’un équipement et pistez pour que cet évènement n’arrive pas.
bernardfr.caron, je suis d’accord avec vous et vous remercie pour ces précisions.
Du coup en remettant les répétitions à « jamais » j’élimine le problème cité, mais je ne plus plus faire plusieurs fois la même action (single_click pour lancer l’ouverture de tous mes volets et à nouveau single_click pour les stopper).
Vous parliez d’une variable comme autre solution, comme valentinfr je débute sur Jeedom et depuis plus d’un mois, je n’ai toujours pas réussi à mettre en place une logique de scénario pour que seul mes actions lancent mes scénarios basés par exemple sur l’évènement #[Switchs Volets][SwitchX4][dps_1_MODE]# pour le switch 1.
on ne peut avoir le beurre et l’argent du beurre
je crois que ces inters peuvent faire double clic et long clic, en tous cas les miens le font.
oui effectivement.
Les miens ont en plus le double_click
Solution 1: créer un scénario qui démarre avec le démarrage de jeedom (tu mets comme évènement : #start#
Dans ce scénario tu fait cela avec tous les scénario problématique :
-
STOP scénario 1
-
inactiver scénario 1
-
STOP scénario 2
-
inactiver scénario 2
-
sleep 3 minutes
-
réactiver tout
ça va charger le démarrage, mais pas tres grave / ponctuel, et infaillible…
Solution 2:
Avec le pluging « Monitoring » tu as la valeur « démarrer depuis »
Au début des scriptes avec problème tu test
Si #[jeedoom][Démarré depuis]# =! « 0 jour(s) et 00h00 » (j’ai jamais essayé cette écriture - mais tu vois l’idée…)
sleep 180
STOP
Ça semble être la solution que j’ai testé depuis, mais après viens le démon ! Je ne connais pas sa stabilité comme je débute sur jeedom, mais si il redémarre, c’est la cata aussi, tout les scénarios liés à des interrupteurs vont faire la fête…
D’ou le fait de faire un « sleep » assez long (pour que tout le reste est le temps de se mettre en place) !
Tu peux même en faire un de 10 minutes, car tu redémarres normalement très peu souvent…
le demon peut redémarrer à tout moment contrôlé en cela par le core Jeedom.
Le seul moyen est d’enlever la répétition des commandes
Effectivement le problème est surtout lié au redémarrage du Deamon, ce qui arrive lorsqu’on sauvegarde un équipement.
Comme le dit bernardfr.caron, il semble qu’il n’y ait pas d’autre choix que de supprimer le répétition de commandes pour chacun des switchs liés à un scenario dont le déclenchement se fait sur un évènement lié à son état.
Du coup, en solutionnant le problème de cette manière ça limite aussi l’utilisation, puisque c’était vraiment bien de pouvoir, dans mon cas, relancer plusieurs fois la même commande (lancer l’ouverture des volets avec siingle_click, puis interompre l’ouverture en relançant single_click pour arréter les volets à l’ouverture voulue, puis plus tard relancer single_click pour finalement ouvrir les volets complètement.
Ce qui était possible avec SmartLife (mais en dépendant d’une connexion internet), n’ai pas possible avec Jeedom (vive le fonctionnement en local). J’imagine que les dev Jeedom, peuvent peut-être trouver une solution pratique à ce problème.
Tout a fait le même cas que moi mais pour des lampes, de ce fait, jeedom deviens caduque…
Pour l’histoire des répétitions, j’ai mi sur toujours…, Après, si le démon ne redémarre pas et qu’on ne touche pas à la config des Switch, et qu’on a désactivé les scénarios au démarrage, ça fonctionne impec…
dans la beta j’ai ajouté un compteur qui s’incrémente à chaque fois que le demon redémarre.
et voici le scenario qui permet de savoir que l’évènement (ici clickGet_1) a été produit à l’intérieur du demon lorsqu’il redémarre :
- Nom du scénario : test
- Mode du scénario : all
- Evènement : #[Salon][Telco3][ClickGet_1]#
CODE
(code) $demonCount = config::byKey( 'demonCount', 'wifilightV2');
$tags =$scenario->getTags();
$tags['#count#'] = $demonCount;
$scenario->setTags($tags);
ACTION
(variable) Affectation de la variable : count à #count#
SI variable(count,0) == variable(precount,0)
ALORS
comment
SINON
(variable) Affectation de la variable : precount à variable(count,0)
comment
l’algo atterrit dans le sinon si la variable count est différente de precount et donc que c’est lors du démarrage du demon que l’évènement a été déclenché.
A tester en beta donc.