hekmon
commented
1 year ago 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, 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