Oui, j’ai eu ce problème avec des index qui n’était pas des entiers. J’utilise ce plugin pour suivre les précipitations : 1L équivaut à 1mm de pluie. Comme l’index du cumul de pluie a une décimale après la virgule, ça ne fonctionnait jamais et ceci depuis plusieurs années.
La semaine dernière, j’ai eu l’idée de tout simplement multiplier par 10 l’index.
Maintenant, le plugin trouve la même chose que moi.
Idem pour la conso calculée par ma chaudière comme je dois diviser son index d’énergie (en je ne sais quelle unité) par 645 pour obtenir une conso en en L de gaz, j’arrondie le résultat sinon ça déconne.
En fait, l’extraction est nickel, mais j’aurais voulu avoir les infos au moment où s’est arrivé. La période à cheval sur le moment où c’était bon et sur le moment où l’anomalie est survenue.
Il faudrait dont que tu modifies les horaires de la requête
J’ai mis 0 en décimale sur ma commande , cela devrait résoudre le problème du coup, d’ailleurs je ne comprend pas pourquoi il y en a dans l’historique alors que ma commande est juste un changement d’état…
J’ai mis lissage aucun, effectivement plus de décimales. Je ferais un retour d’ici quelques jours pour vous dire si les valeurs négatives ont bien disparues.
Je viens faire mon retour, j’avais donc mis lissage aucun et un arrondi sans décimales…mais toujours des retour négatifs voir même plus… j’ai donc supprimé l’historique pour repartir de zéro et tout est dans l’ordre depuis plus d’une semaine… tout est parfait
La solution, oui, bien sur , on la mettra sur la communauté. Par contre, par Teamviewer, je ne ferais pas. J’ai déjà fait et ce n’est pas pratique, car je perd beaucoup de temps à communiquer en même temps avec l’utilisateur. Je préfère regarder tranquillement à tête reposé. Souvent, je le fais très tard le soir, quand j’ai de la dispo. Si tu ne souhaites pas ouvrir ton Jeedom, pas de problème, on continuera sur la communauté
L’index prend une valeur 28096 et ensuite à 5:01:14 il a alors une valeur plus petite (27755). Cela n’est pas normal, la valeur devrait toujours augmenter.
On voit bien le pic sur ton virtuel #[ENERGIE][CONSOMATION EAU ][TOTAL]#
J’en conclus que la fonction stateChanges yoyotte de temps en temps, ou alors on voit aussi un changement d’impulsion qui dure de 4:58:12 à 5:01:08. C’est peut-être ça le problème.
OK top … as tu une solution sur le bug du statechange… si quelqu’un peu nous aider ??? en tout cas merci de ton implication, un développeur qui suit son plugin
Non je penses que c’est un peu exagérer la consommation entre 4h et 5h, correspond à la régénération de l’adoucisseur, ce qui en moyenne correspond à environ 200 litres.
Mon shelly récupère l’impulsion d’un capteur inductif qui capte la petite roue métallique du compteur d’eau. A chaque tour, une impulsion, 1 litre. Donc si la roue s’arrête sous le capteur, l’impulsion reste à 1 jusqu’à la prochaine consommation d’eau. En résumé si pas de fuite d’eau, l’impulsion peut resté à 1 plusieurs jours en cas d’absence.
Donc d’après ce que je vois, je n’ai pas l’impression que le shelly soit en cause. C’est donc je pense le StateChanges qui donne une info erronée à un moment. Mais alors pourquoi, je ne sais pas
J’ai un peu regardé comment fonctionne le statChanges. Il compte le nombre d’occurence de la table historique et archhistorique.
Je pense tout de même que à un instant t tu as plein d’impulsions au moment où ça dure longtemps l’état à 1) et qu’après coup il n’y en a plus qu’une grande peut-être lissé par le système d’historisation Jeedom
$_dateTime = '';
if ($_startTime !== null) {
$_dateTime = ' AND `datetime`>="' . $_startTime . '"';
}
if ($_endTime === null) {
$_dateTime .= ' AND `datetime`<="' . date('Y-m-d H:i:s') . '"';
} else {
$_dateTime .= ' AND `datetime`<="' . $_endTime . '"';
}
if ($cmd->getSubType() != 'string') {
$_value = str_replace(',', '.', $_value);
$_decimal = strlen(substr(strrchr($_value, "."), 1));
$_condition = ' ROUND(CAST(value AS DECIMAL(12,2)),' . $_decimal . ') = ' . $_value;
} else {
$_condition = ' value = ' . $_value;
}
$values = array('cmd_id' => $_cmd_id,);
$sql = 'SELECT count(*) as changes
FROM (SELECT t1.*
FROM (
SELECT *
FROM history
WHERE cmd_id=:cmd_id' . $_dateTime . '
UNION ALL
SELECT *
FROM historyArch
WHERE cmd_id=:cmd_id' . $_dateTime . '
) as t1
WHERE cmd_id=:cmd_id' . $_dateTime . '
) as t1
where ' . $_condition . '';
$result = DB::Prepare($sql, $values, DB::FETCH_TYPE_ROW);
return $result['changes'];
Du coup une petite idée de débutant… Si mon shelly déclenche un scenario sans aucune action avec comme déclencheur #[SOUS SOL][SHELLY UNI COMPTEUR EAU][Statut 1]# ==1, et mon virtuel récupère le stateChanges de mon scenario et non du shelly on supprime donc ce problème !!! puisqu’il ne restera à 1 qu’au moment du déclenchement et non le temps que la roue métallique reste sous le capteur…
