Je regarde dans la soirée mais aucun soucis sur ma prod depuis ce matin
1 « J'aime »
D’ailleurs, ce serait plutôt bien que la teams jeedom nous donne un outil équivalent pour corriger automatiquement ce problème. Cela fait plus de 4 ans que je développe mon jeedom et je n’ai vraiment pas envie de passer du temps à modifier des valeurs qui étaient en « automatique » par défaut depuis le début.
Ce problème est une correction de bug au contraire, donc tu ne le voyait pas avant. Tu a des équipements qui flood ton jeedom à renvoyer sans cesse des valeurs identiques, c’est surtout çà qu’il faudrait corriger …
2 « J'aime »
Merci, c’est très sympathique de votre part.
Certe mais ce bug était complètement transparent. Comme je l’ai dit mon jeedom a commencer il y a plus de 4 ans, 4436 commandes, 65 scénario, c’est très difficile de tout reprendre un par un.
Perso j’avais un truc radical :
Toutes les commandes (donc pas que les binaires) dont la config est « auto » (le truc par défaut) passent « à ne jamais répéter »
De toute façon, il y a chez moi très peu de cas ou je voulais une répétition … Dans ce cas, là je force la répétition
$cmds = cmd::all();
foreach($cmds as $cmd)
{
//"repeatEventManagement":"always"
$rep=$cmd->getConfiguration('repeatEventManagement','void');
if("$rep" == "auto" || "$rep" == "void") {
$cmd->setConfiguration('repeatEventManagement',"never");
$cmd->save();
$scenario->setLog('Changement de la valeur répétition à never pour '.$cmd->getHumanName().' '.$rep);
}
}
8 « J'aime »
En l’état, à mettre dans un nouveau scénario, bloc code.
exécuter le scénario, puis regarder le log.
$allCmds = cmd::all();
foreach ($allCmds as $cmd) {
if ($cmd->getType() != 'info' || $cmd->getSubType() != 'binary') continue;
$repeat = $cmd->getConfiguration('repeatEventManagement', -1);
if ($repeat == -1) continue;
$name = str_pad($cmd->getEqLogic()->getName().'/'.$cmd->getName(), 50, ' ');
$scenario->setLog($name.' -> '.$repeat);
/*
if ($repeat == 'auto') {
$cmd->setConfiguration('repeatEventManagement', 'never');
$cmd->save();
}
*/
}
Pour le reste, je ne suis pas fan d’automatiser çà sans savoir vraiment ce que vous faites sur chaque commande et si c’est bien la solution …
11 « J'aime »
Tu vas me manquer Naboleo… Même avant ce « soucis » je cherchais a faire ça. Mais là c’est encore plus utile. J’ai l’impression, que tu viens de sauver (une nouvelle fois) mon jeedom.
3 « J'aime »
pour info, grasse a ce poste, je vien de voire que mon probleme que dure depuis des mois vien de la.
2 « J'aime »
Pas évident à comprendre tout ça … surtout pour un ‹ ‹ simple utilisateur › › (à contrario des Beta-testeurs et développeurs dans ce post)
En tous cas, merci à @naboleo et @kiboost dont le code va surement soulager bcp de monde
Mais là j’avoue que que je me demande s’il ne faut pas rester un peu encore en 4.1.22 et voir ce que l’équipe Jeedom va faire …
… ok c’est un bug qui date, mais alors pourquoi quand un équipement est créé, sa (ou ses) commande(s) ne se cré(ent) pas avec par défaut l’option répétition à ‹ ‹ JAMAIS REPETER › › au lieu de ‹ ‹ AUTOMATIQUE › › ???
2 « J'aime »
Tout à fait d’accord ! Une petite option générale pour positionner cette option par défaut serait bien du coup 
1 « J'aime »
@kiboost, sans vouloir abuser de ta gentillesse …
… je te demanderais bien d’expliquer ton bout de code
là tu balaies toutes le commandes ; c’est bien ça ?
Tu sélectionnes toutes les commandes ‹ ‹ info › › de type ‹ ‹ binaire › ›
Je ne sais pas à quoi correspond le -1 mais j’imagine que tu forces l’option répétition à ‹ ‹ JAMAIS REPETER › › ; non ?
Là je ne sais pas !
Pour finir tu ecris le log …
Merci d’avance
Non le -1 c’est une valeur par default si il trouve pas la conf, donc si pas de conf pas besoin de changer, je zappe.
en l’etat mon code ne fait que afficher les choses, il ne change strictement rien. Il faut dé-commenter la partie qui change et sauve les commandes pour çà
Ok, compris pour le -1
Mais alors
ça sert à quoi ?
Ok compris aussi. Franchement merci bcp !
Bonsoir,
Après plusieurs heures de surveillance je me surprend à être peu impacté, il n’y a que mes scénarios présence qui se lançaient en boucle où j’ai du passer la commande sur NE JAMAIS REPETER dans BLEA.
Vu que certains sont impactés plus que d’autres je pose une question qui me taraude depuis plusieurs mois.
J’ai lu qu’il y avait 2 possibilités pour qu’une commande active un scénario .
- soit renseigne un déclencheur sur le première page du scénario :
#[OBJET][EQUIPEMENT][Etat]# == 1
- Soit dans les paramètres de la commande on indique de déclencher le scénario concerné si la valeur passe à 1.
J’avais donc lu qu’il valait mieux utiliser la solution 2 et c’est ce que je fais presque toujours depuis (alors que c’est plus ennuyeux à faire).
Mon scénario de présence est un des rares à être déclenché via l’onglet général du scénario car je veux qu’il se déclenche lors d’un passage à 1 et lors d’un passage à 0.
Est-ce que ça peut influer ou non ?
Merci.
Salut @kiboost
j’ai appliqué ton scenario et une grande partie de mes commandes info binaire n’ont pas été modifiées.
Une idée ?
Bonjour olive, il faut décommenter la dernière partie du code, @kiboost l’explique un peu plus haut.
Merci @kiboost et @naboleo pour le partage de leur code, cela permet de nous faire gagner un précieux temps et à retrouver un fonctionnement normal de jeedom.
Encore merci à vous deux.
Je suis pas idiot quand même …
j’ai bien lancé cela :
$allCmds = cmd::all();
foreach ($allCmds as $cmd) {
if ($cmd->getType() != 'info' || $cmd->getSubType() != 'binary') continue;
$repeat = $cmd->getConfiguration('repeatEventManagement', -1);
if ($repeat == -1) continue;
$name = str_pad($cmd->getEqLogic()->getName().'/'.$cmd->getName(), 50, ' ');
$scenario->setLog($name.' -> '.$repeat);
if ($repeat == 'auto') {
$cmd->setConfiguration('repeatEventManagement', 'never');
$cmd->save();
}
}
et j’ai plein de commandes info binaire qui n’ont pas été traitées !