C’est très prometteur, mais je dois être patient avant d’afficher mes infos sur le dashboard : le calcul des consos et coûts pour mon historique en est à 3% en 30 minutes, donc j’en ai pour une quinzaine d’heures ! Avec un Zlinky et une vingtaine de prises connectée, je suppose que c’est normal
Je voulais par contre partager deux aspects sur mon expérience utilisateur à la mise en place de cette intégration, si ça peut aider :
La doc explique qu’on peut « voir la hiérarchie de son réseau électrique » et qu’il faut « vérifier que chaque appareil est bien associé à son parent ». Je pense comprendre à peu près ce dont il s’agit, mais en fait je n’en suis pas si sûr, et je me dis qu’il pourrait y avoir une explication à cette étape de la doc qui explique pourquoi il y a une hiérarchie, ce qu’elle va apporter, et quelles sont les hiérarchies typiques. L’exemple donné avec la prise Nous est un peu ‹ léger › pour ça.
Par exemple, chez moi j’ai une intégration Enedis, un compteur Zlinky, une prise de mesure de conso mais qui suit en fait la production d’énergie de mes panneaux solaires, et une vingtaine de prises connectées qui mesurent des consos, dont certaines sont ‹ empilées ›. Par exemple, j’ai une prise de conso ‹ multimédia › à l’entrée d’une multiprise, et plusieurs autres prises de conso par appareils sur cette multiprise (l’écran, l’ampli,…). Et je ne suis pas sûr de la hiérarchie que je dois mettre en place
Bon j’avoue que je pousse peut-être un peu loin…
Et par ailleurs quand j’ai mis à jour le Zlinky dans l’intégration Zigbee, puis que je suis allé dans l’intégration Suivi de l’énergie, les 6 index EASFxx (je suis en tempo) n’avait pas des noms clairs (HC Bleu, HP Bleu, HC Blanc,…). Est-ce peut-être parce que j’ai d’abord fait la migration en 4.66, puis en 4.66.2 (parce que je crois avoir vu que tu avais amélioré des choses sur ça, Pierre-Gilles, mais peut-être que les deux mises à jour successive ne m’en ont pas fait profiter…). Je ne sais pas si c’est possible de faire le nommage clair automatiquement ?
Tiens nous au courant dès que c’est calculé, je suis curieux du résultat
L’idée, c’est d’établir une hiérarchie en fonction de qui est branché sur quoi.
Si une prise est branchée sur une autre, alors la prise « parent » doit être placée au-dessus dans la hiérarchie, et la prise « enfant » en dessous.
A terme, ça permettra de reconstruire correctement la consommation réelle sans double-compter, surtout quand plusieurs dispositifs sont “empilés”.
Pour l’instant, cette possibilité n’est pas encore exploitée mais ça servira plus tard
Alors il y a deux choses
Jusqu’ici, je n’avais pas trop compris l’histoire des EASFxx (tu dois être en mode standard). Chez moi je suis en mode historique, et mon Lixee TIC renvoie plutôt du BBRHPJB, etc.Si tu peux me donner la signification de chaque EASFxx, je peux les intégrer proprement dans Gladys !
Par contre, ces nouveaux noms plus clairs ne seront utilisés que pour les nouveaux appareils appairés dans Gladys. Je ne peux pas me permettre d’écraser les noms de fonctionnalités déjà existants : si un utilisateur a renommé ses données comme il le souhaite, ce serait un peu violent de tout lui remplacer…
Maintenant on pourrait aussi ajouter un petit helper dans l’interface Zigbee2MQTT pour afficher des explications spécifiques à cet appareil, qui, soyons honnêtes, est un peu complexe pour tout le monde (moi y compris ).
De ce que j’ai vu dans Gladys, tous les index/noms du TIC standard existent déjà dans un appareil MQTT nommé « Téléinformation » (dont les EASFxx) mais pas en TIC historique (qui pourrait être une amélioration je pense).
Les EASF peuvent changer en fonction du fournisseur d’énergie que tu as :
EDF Tempo alors on utilise EASF01 à EASF06 pour les HCJB, HPJR, etc.
heures super creuses de total energies : HP, HC et HSC alors on utilise EASF01, 02 et 03 seulement
base EDF : EASF01
HP/HC EDF : EASF01 et EASF02
etc.
Je pense qu’il est difficile d’avoir des noms spécifiques pour les TIC standard sachant que si on change d’opérateur, EASF01 passera de l’ancien abonnement au nouveau (mais quid de l’index …).
En regardant ce matin pour essayer de mettre tout ça en service, j’ai vu qu’il existait une fonctionnalité MQTT ‘Production d’énergie’. Celle-ci est-elle gérée dans la partie énergie dont nous parlons ici ?
Si oui, est-il possible d’y créer les deux ‘30 minutes’ de manière automatique à la manière des autres index ?
Non ce n’est pas géré En soit les fonctionnalités existent et tu peux les remplir avec de la donnée, mais ce volet n’existe pas actuellement dans Gladys
Je regarde ce développement d’un peu loin à la base, parce que je possède des panneaux solaires dont j’utilise l’API pour récupérer mes consommations / productions.
Mais le côté calcul du coût avec les heures pleines / creuses est vraiment super intéressant !!
Je ne sais pas ce qui vaudrait le plus le coup au final : acheter un lixee à mettre sur mon Linky ou bien essayer de voir si je peux intégrer les valeurs de l’API actuelle avec ces fonctionnalités de gestion de l’énergie ?
Pour le moment l’API communique avec NoreRed, et j’ai créé des fake devices MQTT pour récupérer tout ça côté Gladys.
Le calcul des conso a effectivement pris 15h, et là j’attends le calcul des couts : 18% effectués en environ 6h…
ok pour ça, c’est clair et je comprends la logique pour éviter les doubles-comptes avec des prises de mesure de conso.
Mais tu peux me confirmer ce que je dois faire pour les ‹ briques › Enedis, Zlinky, et mesure de prod des panneaux solaires : les 3 devraient être au même niveau 0, et ensuite toutes mes prises de conso sont sous le Enedis ? Par défaut, Gladys a fait cela : tout (Zlinky, panneaux solaires, et chaque prise de mesure de conso) est enfant de Enedis.
Chez moi, j’ai ça :
EASF01 = HC Bleu (ID externe = zigbee2mqtt:Compteur Zlinky:teleinformation:easf01:current_tier1_summ_delivered)
EASF02 = HP Bleu (zigbee2mqtt:Compteur Zlinky:teleinformation:easf02:current_tier2_summ_delivered)
EASF03 = HC Blanc (zigbee2mqtt:Compteur Zlinky:teleinformation:easf03:current_tier3_summ_delivered)
EASF04 = HP Blanc (zigbee2mqtt:Compteur Zlinky:teleinformation:easf04:current_tier4_summ_delivered)
EASF05 = HC Rouge (zigbee2mqtt:Compteur Zlinky:teleinformation:easf05:current_tier5_summ_delivered)
EASF06 = HP Rouge (zigbee2mqtt:Compteur Zlinky:teleinformation:easf06:current_tier6_summ_delivered)
J’avoue que je n’ai pas d’avis, c’est à toi de voir ce que tu veux faire Le Lixee l’avantage c’est que tu le branches et ça marche direct, l’API tu as un peu de travail, à toi de voir
Non, laisse ce que Gladys fait par défaut, tout doit être enfant d’Enedis, sinon il faudra que tu crées un contrat par appareil à la racine (le contrat est rattaché à un appareil).
Merci, mais du coup @mutmut disait plus haut que ces mêmes fonctionnalités ne sont pas forcément du Tempo, donc je ne sais pas si on peut faire grand chose malheureusement
Merci pour cette super fonctionnalité. Je crois avoir fait les choses dans le mauvais ordre (après lecture de la doc ), et être entré dans un bug étrange.
J’ai le Zlinky et 4 prises Nous zigbee, et j’ai d’abord créé la hiérarchie, créer le contrat, et lancer les calculs, avant de “mettre à jour” les appareils dans l’intégration zigbee to mqtt (pour les nouvelles fonctionnalités). Après avoir fait cette mise à jour, les appareils zigbee ont totalement disparu de la hierarchie… Mais le plus génant, c’est que lorsque la tâche de fond pour le calcul des couts se (re)lance, le CPU monte à 100% et la GUI est injoignable, obligé de redémarrer le container. J’ai du désactiver le service suivi d’energie.
Il y aurait-il moyen de nettoyer mes bêtises et de reset tous les paramètres de la nouvelle intégration pour recommencer plus proprement ?
En soit, c’est pas si grave, quand tu as mis à jour les appareils normalement ils se sont replacé sous le compteur sur lequel est rattaché ton contrat, non ?
Ah, par contre ça, c’est gênant. Est-ce que tu aurais des logs à me partager pour que j’essaie de corriger ça ? docker logs gladys --tail=10000 pour afficher les 10 000 dernières lignes
Pas certain que ce soit la même chose, mais @mutmut a eu des soucis similaires récemment, j’aimerais vraiment comprendre ce qui se passe !
Détection des dépendances circulaires pour éviter les blocages
Passage de « monnaie » à « kWh » et unité dynamiques pour la monnaie (euro et dollar)
DuckDB mis à jour à v1.4.3
MQTT
Correction d’un bug où les valeurs numériques n’étaient pas parsées en tant que « nombre » lors de l’utilisation d’un topic personnalisé, ce qui affichait une valeur brute non arrondie dans l’interface.
Correction d’un bug : si une scène écoute sur le même topic qu’un appareil MQTT avec topic personnalisé, supprimer la scène n’annule plus l’écoute du topic pour l’appareil MQTT.
Suite aux messages que @mutmut m’a envoyés en privé, et aux tests très positifs de @Terdious sur la modification de la limite mémoire de DuckDB, je viens de publier la release v3.66.4.
Cette version réduit la limite maximale d’utilisation de la RAM par DuckDB, qui passe de 80 % à 30 %, afin de laisser plus de marge au système et à Gladys.
Cette offre n’est pas supportée, et pire encore, on ne va pas pouvoir la gérer avec un simple contrat défini en JSON sur GitHub. Il va falloir coder une logique spéciale à cause de cette histoire de week-ends et de jours fériés
Les week-ends, c’est simple, mais les jours fériés, c’est l’enfer Et ne me dis pas que tu habites dans une région avec des jours fériés spécifiques, ce serait le pompon
Le Lixee l’avantage c’est que tu le branches et ça marche direct, l’API tu as un peu de travail, à toi de voir 
), et être entré dans un bug étrange.
Et ne me dis pas que tu habites dans une région avec des jours fériés spécifiques, ce serait le pompon 
