Historisation de plusieurs valeurs d'une commande info dans la même seconde

Plugins Protocole domotique
,
1

Sur les douze valeurs, je n’ai que la dernière valeur qui est historisée.
Le problème doit probablement venir que ces valeurs remontent dans la même seconde.
Cela peut-il être résolu dans le plugin ou dans le core ?

[2020-02-02 16:53:55][INFO] : -> Shellies Annonces|Annonce {"id":"shelly1-000004","mac":"B4E62D000004","ip":"192.168.1.231","new_fw":false, "fw_ver":"20200122-090220/v1.5.9@4b657c90"}
[2020-02-02 16:53:55][INFO] : -> Shellies Annonces|Annonce {"id":"shelly1pm-000007","mac":"840D8E000007","ip":"192.168.1.240","new_fw":false, "fw_ver":"20200122-090726/v1.5.9@4b657c90"}
[2020-02-02 16:53:55][INFO] : -> Shellies Annonces|Annonce {"id":"shelly1pm-000008","mac":"840D8E000008","ip":"192.168.1.241","new_fw":false, "fw_ver":"20200122-090726/v1.5.9@4b657c90"}
[2020-02-02 16:53:55][INFO] : -> Shellies Annonces|Annonce {"id":"shelly1pm-000012","mac":"840D8E000012","ip":"192.168.1.239","new_fw":false, "fw_ver":"20200122-090726/v1.5.9@4b657c90"}
[2020-02-02 16:53:55][INFO] : -> Shellies Annonces|Annonce {"id":"shelly1pm-000001","mac":"840D8E000001","ip":"192.168.1.242","new_fw":false, "fw_ver":"20200122-090726/v1.5.9@4b657c90"}
[2020-02-02 16:53:55][INFO] : -> Shellies Annonces|Annonce {"id":"shelly1pm-000010","mac":"840D8E000010","ip":"192.168.1.246","new_fw":false, "fw_ver":"20200122-090726/v1.5.9@4b657c90"}
[2020-02-02 16:53:55][INFO] : -> Shellies Annonces|Annonce {"id":"shelly1-000011","mac":"B4E62D000011","ip":"192.168.1.232","new_fw":false, "fw_ver":"20200122-090220/v1.5.9@4b657c90"}
[2020-02-02 16:53:55][INFO] : -> Shellies Annonces|Annonce {"id":"shelly1pm-000002","mac":"840D8E000002","ip":"192.168.1.243","new_fw":false, "fw_ver":"20200122-090726/v1.5.9@4b657c90"}
[2020-02-02 16:53:55][INFO] : -> Shellies Annonces|Annonce {"id":"shelly1-000006","mac":"B4E62D000006","ip":"192.168.1.234","new_fw":false, "fw_ver":"20200122-090220/v1.5.9@4b657c90"}
[2020-02-02 16:53:55][INFO] : -> Shellies Annonces|Annonce {"id":"shelly1pm-000009","mac":"840D8E000009","ip":"192.168.1.237","new_fw":false, "fw_ver":"20200122-090726/v1.5.9@4b657c90"}
[2020-02-02 16:53:55][INFO] : -> Shellies Annonces|Annonce {"id":"shelly1pm-000003","mac":"840D8E000003","ip":"192.168.1.238","new_fw":false, "fw_ver":"20200122-090726/v1.5.9@4b657c90"}
[2020-02-02 16:53:55][INFO] : -> Shellies Annonces|Annonce {"id":"shelly1pm-000005","mac":"840D8E000005","ip":"192.168.1.245","new_fw":false, "fw_ver":"20200122-090726/v1.5.9@4b657c90"}
2

Bonsoir @Jeandhom,
Je viens de faire un test avec tes données et je reproduis le comportement que tu observes.
La fonction d’historisation est gérée par le core.
Le plugin jMQTT transmet toutes les données au core sans fournir de date d’acquisition : par défaut le core prend alors la date courante tronquée à la seconde.
Il est aussi possible de fournir la date d’acquisition au core ; je viens de faire un test en passant une date contenant les millisecondes. Le comportement est inchangé : le core tronque la date à la seconde entière et on retrouve en base de donnée, table history, la dernière donnée reçue sur chaque seconde.
Si @loic vois ce fil, il pourrait peut être confirmer le comportement et indiquer si une modification est possible.

3

Bonsoir @domotruc,
Merci pour ton expertise, cela confirme mon analyse.
Il reste, à priori, deux solutions pour résoudre ce problème :

  • soit le plugin ment en ajoutant une seconde sur la date de chaque valeur suivante (méthode crade).
  • soit la table history est modifiée pour prendre en compte dans le champ date les millisecondes (méthode propre).
    Attendons le retour de @loic.
4

Bonjour
J’ai pas lu tous ce que je peux dire :

  • pas possible de passer en dessous de la seconde
  • le core gère même a 5min par défaut sauf si il est en aucun lissage (de mémoire)
5

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.

6

Je suis pas d’accord pour qu’une valeur soit ignorée il faut le même datetime et le même id de commande

7

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.

8

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).

9

Dans les traces de @Jeandhom les id ont l’air toutes différentes…

10

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.

11

Une fois toutes les 24 heures, je ne pense pas que cela puisse écrouler Jeedom.

12

Je vais faire des tests en multiscenario pour voir ce que cela donne.

13

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…

14

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.

15

Oui, c’est bien ça, je confirme.

16

Merci : mon doute est levé…

17

Ok donc la ton message est faux :

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.

On parle bien de commande et pas d’équipement

18

Exact, il faut lire, il s’agit bien d’une seule commande … (désolé).

Commande action qui envoi la requête :

Capture%2020200203
Capture%20202002031072×56 4.57 KB

Commande info qui reçoit les douze réponses dans la même seconde :

Capture%2020200204
Capture%20202002041217×64 13 KB

19

Ok donc non c’est pas possible ce que tu veux faire on ne peut avoir plus d’un changement par seconde d’une commande

20

Comme dit plus haut.

Je reviendrai donner le résultat des courses.