MQTT et Lixee comme source

[Nalexdouze]

Avec une simple formule ;-)

Par exemple :

Code :

msg.payload.active_power / msg.payload.apparent_power

Code :

msg.payload = '{"Pw":' + msg.payload.active_power +
              ',"Pf":' + msg.payload.active_power / msg.payload.apparent_power +
              ',"Pva":' + msg.payload.apparent_power + '}';
msg.topic = "ton_topic_de_lecture_du_routeur"
return msg;

Il me semble que le Pf = actif / apparent

Cordialement
Alexis

[Nalexdouze]

Salut,

As-tu réussi a faire ce que tu voulais ? 

[PhilippeBE]

Salut,

As-tu réussi a faire ce que tu voulais ? 

Oui ... et non.

Je met bien a disposition de RMS un topic MQTT avec les valeurs qu'il attend (Pw, Pf, Pa) et d'autres, pour que je puisse les 'voir' dans l'écran "Données brutes" de l'interface web de RMS.

Mais je ne suis toujours pas 'sûr' des infos exploitées dans RMS qui sont fournies par Linky.
Je m'explique :
- si je regarde le code d'exploitation de la TIC du Linky en direct, je ne comprend pas exactement ce qu'il exploite (ce que je comprend, c'est que Linky ne fournit pas la Pw, et ce que je crois comprendre, c'est que Andrée fait une de temps pour la déterminer)
- si je regarde le code d'exploitation des topics MQTT, André dit clairement qu'il faut que Pw soit connu et fourni.

Dans un noeud node-red, je positionne Pw, Pa et Pf à partir des données issues de la TIC Linky ainsi :
Pw = CCASN
Pa = SINSTS
Pf = CCASN / SINSTS

Je positionne aussi d'autres valeurs pour les comparer :
Pa2 = SINSTS1 + SINSTS2 + SINSTS3
East =EAST

Voila le code de la fonction node-red :

Code :

var P = msg.payload;
var val_Pw = P.active_power;
var val_Pa = P.total_apparent_power;
var val_Pa2 = P.apparent_power + P.apparent_power_ph_b + P.apparent_power_ph_c;
var val_East = P.current_summ_delivered;
var timestamp = P.current_date.substring(7, 9)+":"+P.current_date.substring(9, 11)+":"+P.current_date.substring(11, 13);
var val_Pf = val_Pw / val_Pa;
var newmsg = { payload: '{ "Pw":' + val_Pw + ',"Pva":' + val_Pa + ',"Pva2":' + val_Pa2 + ',"Pf":' + val_Pf.toPrecision(2) + ',"EAST":'+val_East+',"HEURE":"'+timestamp+'" }', topic: "Test/RMS" }
return newmsg;

Ca tourne 24/7 depuis quelques jours, sans planter, c'est deja bon signe.
J'ai commandé un dimmer 40A pour mettre en application sur mon ballon dans un 2eme temps, et voir comment le délestage se comporte.

Si André a un avis sur le sujet, ca m'intéresse bien entendu.

   

[Nalexdouze]

Si je compare les données de mon TIC et des pinces CT de mon Envoy, je ne suis pas sur que Pw = CCASN 

Mais je suis peut-être dans le faux.

   

[PhilippeBE]

En relisant le code d'André exploitant les données du Linky, je crois qu'il se base sur EAST (totaliseur puissance soutirée) pour extrapoler une Pw moyenne sur la période écoulée.

Je vais essayer d'implémenter la même technique, a savoir :

récup EAST et timestamp
calcul conso en W par EAST - EAST-1 (stocké lors de l'itération précédente)
calcul période en s par TIMESTAMP - TIMESTAMP-1 (stocké lors de l'itération précédente) 
calcul Pw moyenne = conso / période

Bon, les bases sont là. Reste à voir :
- comment stocker de manière persistante 2 valeurs dans un noeud fonction node-red
- comment les récupérer ensuite
- comment cela se comporte au fil du temps (données très hachées, ou qui se lissent, ...)


Edit : j'ai la réponse au stockage / récupération des valeurs, il faut utiliser la notion de context de node-red