Compatibilité module énergie

[Makimax35]

Bonjour, cela fonctionne à merveille, pas habitué de HA, j'ai juste dû redémarrer avant de modifier le fichier de configuration sinon il indiquait une erreur d'intégration absence.
L'index étant en Wh, il faut créer un sensor supplémentaire pour le convertir en kWh et pouvoir utiliser le module énergie. Est-ce possible de le mettre nativement dans l'intégration ?
Et la fréquence de rafraichissement semble être de 30 secondes. Est-ce possible de la modifier ? Est-ce possible aussi d'avoir une fréquence de rafraichissement élevée pour les mesures instantanées comme la puissance apparente et pouvoir surveiller des appareils presque à la seconde tout en gardant une fréquence "normale" pour les autres données comme l'index ?
Merci

[hekmon]

Bonjour @Makimax35 , merci pour le retour !

Je vais essayer de répondre à toutes ces questions dans l'ordre même si j'imagine que certaines réponses ne seront pas celles attendues..

L'index étant en Wh, il faut créer un sensor supplémentaire pour le convertir en kWh et pouvoir utiliser le module énergie. Est-ce possible de le mettre nativement dans l'intégration ?

Pas besoin normalement. Les kWh étant juste un multiple (x1000 sur le système international) des Wh, HA peut tout a fait prendre un sensor en Wh et l'afficher en kWh s'il en a l'envie (et il le fait de lui même sur les grandes valeurs). Comme le Linky envoie des Wh j'ai préféré faire apparaître dans HA les valeurs au plus proche de la source.

Le module énergie requiert des sensors qui ont une device class réglée sur energy (peut importe que leur unité soit en Wh, kWh ou MWh ; comme la doc l'indique les trois sont possibles). C'est déjà le cas dans mon plugin et j'utilise moi même ce module pour avoir les stats de mon Linky dans la partie énergie de HA. J'imagine que si tu poses la question c'est que tu n'a pas réussi à utiliser ce capteur dans la partie énergie ? Tu pourrais me donner plus de détails sur là où tu t'attends à le voir/trouver sans le voir ?

Et la fréquence de rafraichissement semble être de 30 secondes. Est-ce possible de la modifier ? Est-ce possible aussi d'avoir une fréquence de rafraichissement élevée pour les mesures instantanées comme la puissance apparente et pouvoir surveiller des appareils presque à la seconde tout en gardant une fréquence "normale" pour les autres données comme l'index ?

Ahah. Alors... Cela a été une grosse partie de la réflexion lors du design de l'architecture du plugin. Plus généralement toutes ces problématiques sont celles au coeur de tout système de métrologie et je vais essayer de t'expliquer pourquoi j'ai fait ce choix. Déjà pour répondre rapidement: oui je pourrais mettre à jour les données plus fréquement mais j'ai choisi de ne pas le faire.

Premièrement il faudrait passer le système en push et non en pull. C'est à dire que ce n'est plus HA qui viendrait prendre la donnée mais mon plugin qui pousserait de lui même la donnée. C'est possible mais c'est plus lourd pour HA (tu dois lui demander de refresh son état par la suite). Ce dernier étant programmé en asynchrone cela représenterait un parasitage régulier et important de sa boucle d'execution et augmenterait nécessairement la charge du programme (quid de ceux qui le font tourner sur de petits ARMs ?). Alors oui cette valeur pourrait être configurable mais un minimum devrait aussi être calculé (de mémoire la connection série du Linky fait une boucle complète en un tout petit peu plus d'une seconde). Dans un design push KISS je devrais push les données dès que je les reçois sans avoir une valeur prédéfinie de fréquence d'envoi (== grosse charge sur HA). En effet, décider de les envoyer toutes les N secondes (15 par exemple) impliquerait de garder un système de cache comme actuellement avec le design en pull : une sorte d'hybride entre les 2 systèmes pas vraiment super où on se tape les inconvénients des 2 et pas vraiment d'avantages à proprement parler. Donc une augmentation de la complexité et de la charge pour une solution au finale encore et toujours imparfaite.

Et là tu vas me dire "oui mais en ayant toutes les 15s j'ai plus de chance de voir un pic sur ma consommation instantanée !". C'est vrai. Mais le problème est infini: et si le pic apparait entre les 15s ? C'est le problème classique de sampling en métrologie : les valeurs instantanées ne sont tout simplement pas faites pour être récupérées ainsi. Je vais digresser rapidement sur un cas classique qui vient du (de mon) monde professionnel: imagine un serveur web qui a des métriques sur sa carte réseau sur la quantité de données y transitant. Que tu sample a 30s, 15s, 10s, 5s ou même 1s : il y a toujours un risque qu'un très gros burst de données sur un très court temps passe inaperçu. Comment faire dans ce cas ? En métrologie on préfère toujours les compteurs à des valeurs instantanées. Pourquoi ? Car on est sur de rien rater, peu importe le sampling. En reprenant mon exemple si je mesure a t+0 la quantité totale de données qui a transitée et a t+1 cette nouvelle quantité, le burst sera enregistré. Alors on ne saura pas exactement quand il a eu lieu et on calculera la valeur moyenne sur cette durée de temps ((nouvelle quantité - ancienne quantité) / temps écoulé, la fonction rate de prometheus par exemple). Plus le sampling est bas plus on aura un interval de temps faible avec une valeur forte qui fera apparaître sur ce segment de temps une activité plus importante. Alors oui cette valeur sera être lissée sur cette valeur de temps (celle de ton sampling, 30s, 15s, etc...). Dans ce cas, il est d'ailleurs possible (et conseillé !) d'ajouter à ce compteur de quantité totale d'autres compteurs de type "valeur maximale rencontrée" par exemple qui ne peut être enregistré que par la source et proposé au système qui vient récupérer les données toutes les N secondes. Tout cela pour te dire qu'en métrologie une valeur instantanée est purement indicative et que vouloir l'avoir exacte est un problème insoluble et infini.

Donc !
J'ai choisi d'architecturer mon plugin différemment. Ce n'est pas lui qui pousse les données toutes les 30s vers HA, c'est HA qui décide quand il veut rafraichir les données de ce plugin. D'un côté mon plugin va lire, dans un thread à part, les données du port série en continue et conserver en permanence en mémoire la dernière valeur lue pour chacun des compteurs. D'un autre, de temps en temps HA va venir demander à mon plugin quelle est la valeur du compteur X et l'obtenir instantanément grace au cache en mémoire de la lecture série continue.

Je trouve ce découplage beaucoup plus élégant:

• Je ne charge pas plus que nécessaire la machine et HA. J'effectue la lecture de la connection en série en continue, cela consomme un peu de ressources mais je le fais dans un thread séparé et je ne "harcèle" pas HA plus que de raison alors qu'il n'a rien demandé: je maintient donc une utilisation minimale des ressources.
• Quand HA décide de mettre à jour ses valeurs, il vient les chercher et grace au cache que je maintient en mémoire je n'ai pas besoin de lancer une lecture série et d'attendre une boucle complète comme j'ai pu le voir sur d'autres plugins par exemple: je donne instantanément la dernière valeur lue de manière indépendante par mon thread. Cette réponse instantanée permet une meilleure fluidité et donc performance de HA (je ne bloque pas sa boucle d'execution).
• Cela laisse donc HA seul maître de la pression qu'il choisi de se mettre: quand venir mettre à jour les données. L'avantage c'est que si dans le futur HA se dote d'une fonction permettant de customiser cette valeur (que ce soit globale ou par intégration) le design actuel est déjà compatible.
• La puissance instantané est donc purement indicative (et peut laisser passer un pic comme expliqué, mais c'est aussi le cas sur ton écran Linky !) mais ne peut être autrement peut importe la valeur de sampling: il y aura toujours des 'trous' dans ce qu'elle retournera. Il faut la prendre pour ce qu'elle est et plutôt se diriger vers des rate basé sur les compteurs en Wh pour avoir un semblant d'instantané.

Voilà j'espère que mon pâté n'a pas été trop indigeste mais comme c'est effectivement une question importante (et intéressante sur le pourquoi !) j'ai voulu expliquer pourquoi cette valeur de 30s et pourquoi elle ne changera pas... depuis mon plugin ! (mais peut être dans le futur depuis HA).

Bonne journée à toi.

[Makimax35]

Bonjour et merci pour ce retour clair alors que pourtant je ne suis pas vraiment du domaine. Je pensais en effet que le plugin était maître de la remontée et non tampon et serviteur de HA mais en effet c'est bien comme cela. Je m'acharnait et tenter de comprendre le code (n'y connaissant vraiment rien) pour trouver cette valeur de 30 secondes. Au moins c'est vu et je te remercie.
J'ai bien compris que l'instantané n'est qu'un instantané à un moment du système, pas forcément le moment du pic. Ma volonté était juste pour la PAPP de l'avoir plus vite, sans la logger, aucune acquisition, mais a un délai permettant d'allumer une lampe, ou une télé, ou un PC afin de savoir sa consommation. Ainsi lorsque je vois une PAPP élevée sur une durée assez longue cela m'oriente vers tel appareil (ou plusieurs évidemment) en fonctionnement comme par exemple ma pompe à chaleur qui n'utilisait pas la PAC mais la résistance chauffante le semaine dernière, et c'est ton plugin qui m'a permis de le constater.

Il y a un moment déjà j'avait tenté Nodered + MQTT + InfluxDB et Grafana, mais pour un novice cela fonctionne mais trop compliqué comme chaîne, j'avais mis un rafraichissement à 5 secondes pour la PAPP, mais au final tout abandonné car la mise en page ne valait pas celle de Home Assistant avec HighCharts ! et surtout la base de données était devenu gigantesque malgré mon échantillonnage final à 30 secondes.

Je ne sais pas ce que cela donnera avec les 30 secondes et le stockage par HA.

Concernant les kWh, je le voit bien partout y compris dans le module énergie mais j'avais lu qu'il fallait absolument des Total_increasing avec unité kWh donc j'ai fait un sensor avec la mise à l'échelle.
Est-ce que cela va gonfler la base HA inutilement puisque doublons avec le Wh ? peut être remettre comme tu l'as prévu au final et laisser HA gérer le multiplicateur à l'affichage.

Tu parles du monde professionnel, je fleurte avec un projet similaire mais uniquement logger, sur un même concept mais sans HA, et le capteur n'est pas un Linky mais similaire dans le fond. Travail tu dans une société de prestation ? peut être en MP pour ne pas sortir du sujet.

As tu une propositions de carte pour la mise en page / graphique sur lovelace (apex, ...) ?
Et la dernière question, pourquoi ton plugin ne serait pas directement dans les intégrations HA pour simplifier la décompression, répertoire, configuration yaml ? j'imagine que ce n'est pas simple. En tout cas il va au dela de LIXEE car mon boitier est un CGE Electronic au format DIN donc identique au modèle LIXEE, mais cela fonctionne, comme cela doit fonctionner avec le DIY d'un ami avec Optocoupleur. C'est finalement l'intégration Linky TIC USB que tu as fait !
Encore un énorme merci pour le travail effectué

[hekmon]

Comme tu le dis, la papp de linky est utile pour une charge un minimum continue, quand je veux mesurer un appareil précisément ou ponctuellement j'utilise une prise wattmètre ;)

Grafana est un outil extrêmement puissant mais un peu long a prendre en main pour aller au fond de toutes ces possibilités (c'est ce que j'utilise professionnellement) et ce n'est que la brique visualisation de toute une stack de metrology (il faut effectivement une tsdb comme influxdb + les exporters, etc...). Je ne connais pas HighCharts pour HA, je jetterai un oeil !

Pour le module énergie il faut effectivement un total_increasing qui est en fait, la dénomination HA d'un "compteur" tel que je le décrivait dans mon premier post, en interne cela va lui permettre de calculer automatiquement l'augmentation tout en gérant les "reset" que ce type de compteurs peut rencontrer, c'est cette augmentation qui est utilisée pour la quantité d'énergie affichée apr tranche horaire. Il n'a pas non plus besoin d'avoir une unité particulière mais simplement d'avoir la classe energy (et c'est cette dernière qui limite les unités à Wh ou à 2 de ces multiples, c'est donc un prérequis indirect).

Les compteurs de ce plugin possèdent ces 2 prérequis et sont donc de fait utilisables directement. HA choisira tout seul la mise à l'échelle et donc la "bonne" unité. Par exemple bien que mon plugin retourne des Wh à HA, celui-ci décide de les afficher en kWh au vu de l'ordre de grandeur du compteur:

Tout cela pour dire que ton compteur supplémentaire adapté en kWh n'est effectivement pas nécessaire et stocke une seconde fois la même donnée :)

Concernant les DMs, je te laisse récupérer mon email dans l'historique des commits git de ce repository ou de regarder le nom de ma société (mon compte github est rattachée à son organisation) c'est effectivement une société de service mais peut être pas celle que tu imagines.

Malheureusement, je connais pas trop d'amélioration de mise en page / graphique pour lovelace, je j'ai que peu de temps personnel donc j'avoue rester sur les widgets de base (certainement à tort !).

Concernant les intégrations, oui j'aimerai aussi avoir les assistants de configuration graphique pour ce plugin in fine... Mais c'est un cran supérieur en terme de complexité et au vu de mon temps limité je préférais avoir une première version simple et fonctionnelle rapidement plutôt que d'attendre d'étudier et comprendre le système d'intégration graphique avec le risque de ne jamais finir ce plugin... (par exemple, ce fichier n'est actuellement pas nécessaire ni utilisé pour la configuration basique mais sera nécessaire pour ce système).

Un jour j'espère :)

[hekmon]

Concernant la compatibilité des autres modules TIC, cela ne m'étonne pas vu qu'une fois encapsulé dans le protocole USB cela reste une connection série standard respectant le standard TIC d'Enedis... Peut-être devrais plus clairement indiquer dans le fichier readme qu'il n'est pas seulement compatible avec celui de Lixee 🤔

Merci pour les noms de vos modules, avoir quelques exemples d'autres modules fonctionnels est un gros plus !

[Makimax35]

Merci pour ces réponses détaillées. Pas du métier, je n'imaginais pas l'ampleur pour passer cela en intégration graphique donc je comprends. Pour la compatibilité c'est ce que je me disais, la partie USB et com série étant commune (y compris avec la version DIY) ton plugin est "universel" donc mon CGE electronics en fait partie. C'est carrément le plugin qui pourrait changer de nom, au début je n'y croyais pas plus que cela donc encore merci pour le travail et le partage.
Dans le readme, préciser de rédémarrer entre le décompression dans le répertoire custom_components et l'ajout dans le fichier de configuration sinon on a une erreur.

Concernant la conversion d'unité, le module énergie de HA liste bien les entités compatible et celle de ton plugin était proposée donc comme tu le dis les prérequis sont au vert alors j'ai suivi ton conseil et supprimé mon doublon kWh.

Pour le projet pro, en effet la prestation de ta société n'est pas celle que j'imaginais mais la compétence y est surement ^^, je ne veut pas m'étendre et faire un hors sujet mais cela aurait été intéressant d'en discuter. Au moins en conseil.
Du coup je clôture. Encore merci.

[hekmon]

Concernant la fréquence de mise à jour, je me permets de partager un petit teasing...

[hekmon]

Plus d'informations ici: #2 (comment)

[hekmon]

La 1ère beta de la v2 contenant le mode temps réel qui vous intéressait est disponible. Plus d'infos ici.

[Makimax35]

C'est noël avant l'heure, j'essai de trouvé un moment ce jour pour tenter la migration. Merci d'avance car c'est un boulot monstre j'imagine et cela semble correspondre totalement à mon besoin.