Nom des Tags base influxDB

[pf26]

Je vois qu'il y a un tag "_measurement", et un autre "measured_value" qui semblent contenir presque la même chose. A priori, le "measured_value" peut être supprimé En testant, je n'ai pas vu de différence de performance entre les 2 pour les requêtes.

Actuellement, les SN (des mesureurs Omegawatt) sont dans la colonne "device_name" et les noms des voies sont dans "nature". Je préfèrerais avoir des Tags "SN" et "Channel" dans la base InfluxDB. Ensuite, il faudrait remplir le Tag "device_name" à partir du SN et Channel (voir "Peuplement de la table device") Il faudrait à la fois changer le parser, et mettre à jour la base pour les data déjà parsées (ou effacer/reparser les fichiers)

[pf26]

Tags utilisés et peuplement selon parser SOCOMEC et OMEGAWATT: SOCOMEC const measure = { SN: measureMetadata[LOAD_NAME], Channel: measureMetadata[NATURE], device_name: metadatas[DEVICE_NAME], measured_at: measureDateAsString, //state: MEASURE_STATES.PRESENT, //load_name: , usage: measureMetadata[USAGE], //nature: , //measured_value: measureMetadata[MEASURED_VALUE], unit: measureMetadata[UNIT], //scale: measureMetadata[SCALE], value: row[measureIndex], };

OMEGAWATT const project = "project_name"; // nature = Ph${offset}; unit = "V"; <<<---- } else { const columnForDevice = (offset - voltageOffset + 1) % 12; //const voieNumber = ~~((columnForDevice - 1) / 2) + 1; //nature = ; unit = columnForDevice % 2 === 0 ? "Q" : "P"; } const device_offset = ~~((offset - voltageOffset) / 12); const device_name = metadata[device_offset]; <<---------------From device_table const value = row[offset]; const measure = { SN: metadata[device_offset], Channel: ~~((columnForDevice - 1) / 2) + 1, measured_at, //nature, device_name, //measured_value, value, unit, <<------------ project, };

[Augustin82]

@pf26 désolé, je ne comprends pas comment interpréter ton message. Est-ce que tu peux me faire un tableau de correspondance entre le nom actuel et le nom désiré, et ce pour Socomec et Omegawatt ? Par exemple :

Omegawatt - nature => channel
Socomec - nature => à enlever

Merci !

[pf26]

Mon message correspond aux codes de parser que je souhaite voir modifiés, avec les modifs indiquées par des <<<---- ou // pour les lignes retirées. Omegawatt: nature => channel device_name => sn à créer device_name tiré du fichier device_name.txt à partir de sn et channel => device_name à créer: "V", "W" ou "Var" => unit (W pour les puissances "P", Var pour les "Q" - incomplet dans mon message précédent) measured_value => supprimé

Socomec nature => channel load_name => sn measured_value => supprimé state => supprimé scale => supprimé

[Augustin82]

~Résolu par https://github.com/Augustin82/omegawatt/commit/97c7792e161f7a7c926a65fa99e017aab348b06c~ Pas du tout.

[Augustin82]

• tag device_name
• tag channel
• tag sn
• tag project
• field unit

[Augustin82]

Pour l'instant, on gardera commenté device_name en attendant que l'issue #12 soit résolue.

[Augustin82]

Je m'interroge sur la colonne "usage" : on l'a faite sauter, mais dans le même temps on veut la mettre dans la table device (#12).

J'ai aussi un doute sur la suppression, pour le parser Socomec, de la colonne "measured_value" (qui contient des trucs comme ER+ ou ER-) alors qu'on a transformé "nature" en "channel", quand ces colonnes contiennent en fait des trucs comme "Elec".

@pf26 tu peux confirmer sur ces sujets ?

[pf26]

Je préfère qu'on laisse le Tag "usage" - désolé si j'ai dit qu'on la faisait sauter et pas vu qu'elle n'apparaissait plus dans ta liste. Pour le "measured_value", la même info (EA+, ER+.. très importante en effet) se trouve dans "_measurement". Pour le "nature" qui devient "channel", on le remplit avec qqch qui n'a pas gd intérêt en effet actuellement, mais de toute façon il faut le Tag "channel" pour Omégawatt, et ça laisse probablement une possibilité de changer une info pour les Socomec.

[Augustin82]

@pf26 j'ai identifié le problème, ce n'est pas un problème de code.

En fait, quand on a basculé le tag "unit" en field, on a en quelque sorte "dédoublé" la time series : une time series qui contient les tags ainsi que le field value et la value 200 (ou une autre valeur numérique mesurée), et une autre séries qui contient les tags ainsi que le field unit et la value W (ou autre unité utilisée). Apparemment, quand on demande la moyenne de manière simple comme on le fait dans l'interface Influx, sans filtrer par field_, il essaie de faire la moyenne entre la _value de value (200) et la value_ de unit (Wh) ce qui n'a évidemment aucun sens. Quand on filtre sur l'un ou l'autre _field, les données sont affichées correctement.

Je vais repasser l'unité en "tag" plutôt qu'en "field", c'est mieux conceptuellement. Comme illustré dans un article que j'ai lu (https://grisha.org/blog/2015/03/20/influxdb-data/), l'idée derrière le fait de mettre plusieurs "fields" dans une mesure, c'est de mesurer l'état d'une seule "chose" à un moment donné, quand ça peut bouger de manière indépendante (dans l'exemple du blog ci-dessus, l'espace disque total et libre, à un moment donné, pour un serveur donné).

N'hésite pas à me faire un retour sur tout ça.

[Augustin82]

Résolu dans le commit cc54b462c4b5ec847139a16f03fb8048fb61baf5.