Ce qui est évoqué, c’est que pour qu’une valeur puisse être stockée dans la table history, elle doit avoir un datetime différent de la précédente sinon elle l’écrase.
Ici, différents modules répondent à une seule requête dans la même seconde dans un même équipement.
Pour que toutes les valeurs soient historisées, il faudrait que le datetime soit différent pour chaque valeur, d’où prendre en compte les millisecondes, ou que plusieurs valeurs avec le même datetime puissent être inclus dans la table.
Après, pour tous les traitements suivants, les millisecondes peuvent être ignorées.
D’ailleurs, ces valeurs étant des arrays (json), elles n’ont pas lieu d’être lissées.
Je suis tout à fait d’accord avec toi pour qu’aucune valeur ne soit ignorée.
Dans mon cas, sur les douze valeurs remontées par le plugin dans la même seconde, j’ai onze valeurs ignorées par le core.
Si la table history ne peut pas accepter plusieurs valeurs (enregistrements) avec le même id de commande et le même datetime alors il faut passer datetime en milliseconde.
Je suis pas d’accord la dessus deja c’est pas simple je sais même si mysql support ce type de champs, et il est anormal q’un équipement change d’état 12 fois par secondes, de toute façon même si la table history le faisait jeedom n’est pas tailler pour traiter autant de change à la seconde et ça on ne pourra jamais rien y faire (la vous voyez que la table history mais croyez moi ca doit merder a de nombreux endroit derrière).
Il s’agit bien d’un seul équipement (même id) qui fait une requête MQTT (façon broadcast) et tous les modules qui la reçoivent y répondent. Je n’ai que douze modules, pour l’instant.
Ok, donc tu as une requête qui déclenche 12 réponses de 12 modules différents (et avec 12 MAC)
Si j’ai bien compris le besoin, c’est de récupérer les 12 réponses, non ?
Est-ce que ça correspond au même id qu’évoque @loic pour faire le distingo lors de l’ajout dans la base ?
Si oui alors ça ressemble à un bug…
Attention je parle pas d’équipement dans mon message mais de commande et la différence est capital.
Et si la c’est bien 12 changement de valeur d’une seule et unique commande dans la seconde la réponse et non jeedom ne peut pas gérer ça et ne pourra jamais y arriver que ce soit une fois par 24h ou une fois tous les 100ans.
Merci @naboleo de t’intéresser à ce sujet.
Il s’agit bien d’un seul équipement (même id) qui fait une requête MQTT (façon broadcast) et tous les modules qui la reçoivent y répondent. Je n’ai que douze modules, pour l’instant.
Finalement en faisant un scénario, « Multi-lancement », « Synchrone », « Provoqué » avec comme déclencheur la commande info, je récupère bien mes douze valeurs.
Dans les logs du scénario, tout est à la même seconde.
Bonsoir @Jeandhom,
Pas bien compris ta solution. Ton besoin n’était pas d’historiser toutes les valeurs? En quoi passer par un scénario te permet de remplir le besoin?
Non, le besoin était de récupérer les douze valeurs de la même commande info pour ajouter un message dans le Centre de message lorsqu’un nouveau firmware est disponible.
Je pensais y arriver en passant par la table history.
Je partage le code, ce sera peut être plus clair.
Il ne faut pas oublier que le déclencheur du scénario change douze fois dans la même seconde.
Je fini par l’affichage d’un json dans un virtuel.
$trigger = cmd::cmdToHumanReadable($scenario->getRealTrigger());
$scenario->setLog('Trigger : ' . $trigger);
$cmd = cmd::byString($trigger);
$value = $cmd->execCmd();
$scenario->setLog('Valeur : ' . $value);
$shelly = json_decode($value,true);
$id = $shelly[id];
$scenario->setLog('ID : ' . $id);
$mac = $shelly[mac];
$scenario->setLog('MAC : ' . $mac);
$ip = $shelly[ip];
$scenario->setLog('IP : ' . $ip);
$fw_ver = $shelly[fw_ver];
$scenario->setLog('FW_VER : ' . $fw_ver);
$new_fw = $shelly[new_fw];
$source = 'Scénario ' . $scenario->getHumanName() . ' ' . $id;
if ($new_fw) {
$new_fw_txt = 'true';
// Ajout d'un message dans le Centre de Message
message::add($source,$fw_ver,'Nouveau firmware disponible - Mettre à jour le firmware');
} else {
$new_fw_txt = 'false';
// Retrait d'un message dans le Centre de Message
message::removeAll($source);
}
$scenario->setLog('NEW_FW : ' . $new_fw_txt);
$maVar = $scenario->getData('a_shelliesAnnonce');
$maVar[$mac] = $new_fw_txt;
$scenario->setData('a_shelliesAnnonce', $maVar);
$maVar = $scenario->getData('a_shelliesAnnonce');
$maVar = json_encode($maVar,true);
cmd::byString('#[Shellies Administration][Shellies Firmware][Retour Annonce]#')->event($maVar);
