Mode standard

[gduteil]

Ajout du support du mode standard

[hekmon]

Ravi de voir que le coeur de lecture série n'a pas eu besoin de modification :)

J'ai eu une idée : plutôt que d'attendre d'avoir le temps de passer tout cela en revue, je vous propose de merge et de créer la v3 en beta/preview. Ainsi ceux qui le souhaitent peuvent tester le mode standard dès maintenant et cela me laisse le temps... de trouver du temps de m'y mettre sérieusement.

[theblackhole]

Bonne idée ! Je pense que je vais faire une demande pour passer au mode standard pour aider à faire des tests. Vu que ça ne fait pas longtemps que j'ai installé mon Linxee, ça ne me dérangerait pas si les données étaient perdues/fausses/plus enregistrées.

Préviens nous quand la v3 beta est disponible au test @hekmon🙂

[gduteil]

Ca me parait être une bonne solution, plus simple pour les eventuels testeurs.

Pour info je viens de me rendre compte que le fork n'était plus fonctionnel depuis la dernière MAJ de HA (j'avais ajouté certains sensors en CONFIG).
Je les ai passés en DIAGNOSTIC, je vais faire le pull request

[gduteil]

Bonne idée ! Je pense que je vais faire une demande pour passer au mode standard pour aider à faire des tests. Vu que ça ne fait pas longtemps que j'ai installé mon Linxee, ça ne me dérangerait pas si les données étaient perdues/fausses/plus enregistrées.

Préviens nous quand la v3 beta est disponible au test @hekmon🙂

Les entités changent de nom, les anciennes données ne sont plus liées.
La seule solution que j'ai trouvée est de taper directement dans la base SQLite pour changed les IDs , je viens d'ajouter les 4 requêtes que j'ai utilisées ici https://github.com/gduteil/linkytic/wiki/Passage-du-mode-Historique-au-mode-Standard

Faire une sauvegarde de HA avant, on sait jamais ! ;)

[theblackhole]

Alors si c'est ce que je pense, j'ai déjà eu cette situation récemment avec un nouveau nom d'entités (ajout de "linky" dans le nom des entités) que je voulais fusionner avec l'ancien et ma solution, plutôt que de passer par des commandes SQLite a été, je crois, de supprimer les anciennes entités et renommer les nouvelles en anciennes (ou inversement ?).
Je ne sais plus dans quel sens c'était mais l'action de renommer moi même les entités a fait que HA a merge les anciennes stats avec les nouvelles dans le tableau de bord Energie (la nouvelle entité en elle-même n'a plus les anciennes données mais la donnée "statistique" liée, elle, a rassemblé les 2)

Quand je testerai cette évolution du module, je tâcherai de noter les instructions exactes pour conserver les anciennes données (si ça fonctionne)

[gduteil]

Effectivement en supprimant les nouvelles puis en donnant le nouveau nom aux anciennes ça devrait fonctionner, avec juste la perte des des nouvelles données avant l'opération, mais si c'est fait assez rapidement ça ne pose pas vraiment de problème

[hekmon]

Les entités changent de nom, les anciennes données ne sont plus liées.

Ca avait effectivement été un sujet lors du passage de la v1 (yaml config) à la v2 (config flow) : j'avais mis dans le readme de l'époque une petite procédure pour ceux qui voulaient garder les mêmes.

Pour info je viens de me rendre compte que le fork n'était plus fonctionnel depuis la dernière MAJ de HA (j'avais ajouté certains sensors en CONFIG).
Je les ai passés en DIAGNOSTIC, je vais faire le pull request

Oui j'ai eu le même problème (d'où la sortie de la v2.0.7). J'aurais pu le fix moi même mais merci !

Préviens nous quand la v3 beta est disponible au test @hekmon🙂

J'ai repéré 2 ou 3 petites choses que je souhaiterai corriger avant (2 sondes orphelines créées sur la pile et non ajoutées dans l'array des sondes), un peu de linting par ci par là et des classes héritées que réimplémente le constructeur du parent plutôt que de l'appeler directement (repéré mais pas encore corrigé). J'ai déjà commencé, ca devrait pas trop tarder :)

[hekmon]

Désolé pour le temps d'attente mais la relecture réintégration a fait du bien car elle m'a permis de trouver une regression pour le mode historique. Désormais corrigée :)

@gduteil au final il y aura eu quelques de commits d'integration à la code base, pouvez-vous relire la version finale pour m'assurer que je n'ai pas enlever quelque chose de vital pour le mode standard et la tester chez vous ?

La première beta de la version 3 est par ici 🎉

[theblackhole]

La première beta de la version 3 est par ici 🎉

Top ! Je viens d'envoyer la demande à mon fournisseur pour passer au mode standard, il n'y a plus qu'à attendre... :)

En attendant j'imagine que la beta est sensée gérer à la fois le mode historique et standard ? (que je sache s'il faut que j'attende le mode standard pour l'installer)

[gduteil]

Désolé pour le temps d'attente mais j'ai la relecture réintégration a fait du bien car elle m'a permis de trouver une regression pour le mode historique. Désormais corrigée :)

@gduteil au final il y aura eu quelques de commits d'integration à la code base, pouvez-vous relire la version finale pour m'assurer que je m'ai pas enlever quelque chose de vital pour le mode standard et la tester chez vous ?

La première beta de la version 3 est par ici 🎉

Merci pour la relecture et les corrections, les relectures sont toujours utiles d'autant plus que je ne suis pas très à l'aise avec Python et encore moins avec l'API de Home Assistant.

J'ai installé la bêta, ça a l'air fonctionnel chez moi, au moins en standard, monophasé et sans reinjection.

[gduteil]

La première beta de la version 3 est par ici 🎉

Top ! Je viens d'envoyer la demande à mon fournisseur pour passer au mode standard, il n'y a plus qu'à attendre... :)

En attendant j'imagine que la beta est sensée gérer à la fois le mode historique et standard ? (que je sache s'il faut que j'attende le mode standard pour l'installer)

Oui la bêta gère les 2 modes, néanmoins lors du passage en mode standard il faudra supprimer l'ancien compteur et le réinstaller en cochant le mode standard, et faire une opération pour rattacher les anciennes entités sur les nouvelles (voir les posts ci-dessus)

[theblackhole]

Voici mon retour d'expérience de la beta avec le mode standard :

Linky : Sagem G1 monophasé
Abonnement : EDF Base (et pas de production)
Module : Linxee TIC-DIN
Mode : Standard avant la mise à jour vers la beta (ils ont été plus rapide que moi EDF/ENEDIS 😁)

Je confirme que le baudrate 9600 pour le mode Standard est correct, comme indiqué dans le readme :

linkytic/README.md

Lines 123 to 126 in 0f81acc

	* Mode standard (à vérifier)
	```bash
	stty -F /dev/ttyUSB0 9600 sane evenp parenb cs7 -crtscts
	```

A voir dans le temps mais tout semble fonctionner : les statistiques semblent correctement récupérées, beau travail ! 🙂

J'ai reproduit (et retranscrit) la méthode que j'ai utilisé pour fusionner les anciennes statistiques du tableau énergie avec les nouvelles et ainsi ne pas perdre l'historique.

Note: j'ai tendance à laisser un peu de temps entre chaque action, surtout les action de renommage d'entité et celles de suppression pour laisser le temps à home assistant de faire un éventuel travail de fond. C'est probablement pas nécessaire mais comme il n'y a aucun retour visuel sur le processus de migration/fusion de données, impossible de savoir si on peut enchaîner les actions ou s'il faut le laisser travailler en arrière plan pour éviter des problèmes

1. Nettoyage et mapping

• Supprimer l'ancien appareil et ajouter le nouveau en mode standard
• Supprimer votre source de consommation réseau dans le tableau énergie
• Il y a 3 statistiques qui sont maintenant orphelines (vérifiable dans outils de développement > statistiques) :
  • sensor.linky_index_option_base
  • sensor.linky_puissance_apparente
  • sensor.linky_intensite_instantanee
• Il faut maintenant trouver quelles sont les nouvelles entitées qui pourraient correspondre aux anciennes.
  • Dans mon cas, les entités sensor.linky_libelle_tarif_fournisseur_en_cours (BASE) et sensor.linky_numero_de_lindex_tarifaire_en_cours (01) m'indiquent que la sonde qui s'appelait sensor.linky_index_option_base correspond maintenant à sensor.linky_energie_active_soutiree_fournisseur_index_01 et le dernier index relevé est cohérent.
  • sensor.linky_puissance_apparente devient sensor.linky_puissance_app_de_reference (vous confirmez ?)
  • sensor.linky_intensite_instantanee devient sensor.linky_courant_efficace_phase_1 (vous confirmez ?)
• Profitez en pour faire une capture d'écran de la liste complète des nouvelles entités, ça servira plus tard

2. Renommage des anciennes entités / fusion des données :
   Avec ces infos, il faut maintenant :

• Supprimer le nouveau compteur nouvellement ajouté
• L'ajouter à nouveau en mode Historique (même s'il est passé en mode Standard, ce sont les anciennes entités qui nous intéressent)
• Dans outils de développement > statistiques , supprimer (avec le bouton Corriger) toutes les statistiques correspondant aux nouvelles entités qui sont maintenant orphelines (car on l'a ajouté en mode historique), s'aider de la capture d'écran précédente de la liste d'entités si besoin
• Renommer les entités (j'ai renommé l'id et le nom dans le doute mais probablement que l'id doit suffire) :
  • sensor.linky_index_option_base dans mon cas devient sensor.linky_energie_active_soutiree_fournisseur_index_01 (et le nom devient Energie active soutirée fournisseur, index 01)
  • sensor.linky_puissance_apparente devient sensor.linky_puissance_app_de_reference (nom Puissance app. de référence) (vous confirmez ?)
  • sensor.linky_intensite_instantanee devient sensor.linky_courant_efficace_phase_1 (nom Courant efficace, phase 1) (vous confirmez ?)

3. Dernière suppression et dernier ajout :

• Supprimer une nouvelle fois l'Appareil linky et vérifiez que dans "outils de développement > statistiques" les 3 statistiques renommées sont bien présentes (fournisseur index 01, puissance app de référence etc...)
• Ajouter une dernière fois l'Appareil en mode Standard
• Ajouter la nouvelle source de consommation (ex Energie active soutirée fournisseur, index 01) dans le tableau énergie
• Voilà ! Si tout s'est bien déroulé, dans le tableau de bord énergie, l'historique de consommation précédent est consultable et les nouvelles données s'ajouteront à la suite. Au passage c'est normal que l'historique des entités ne soit pas fusionné et que seules les nouvelles données soient visibles, cette méthode ne fusionne que les données statistiques (exploitées dans le tableau de bord énergie par exemple)

Vous voulez que je fasse une PR sur le README pour l'intégrer (avec des images et des choses à retravailler j'imagine ?) ? Ou un autre MD/Wiki séparé ?

[gduteil]

Les correspondances des entités ont l'air correctes, pour l'énergie soutirée j'ai un doute, je pense que sans contrat heures creuses l'index 01 est le même relevé que le total (ce qui est mon cas) mais qu'avec un contrat heures creuses les relevés seront ventilés entre l'index 01 et 02.

Le mieux est effectivement de prendre une capture des valeurs avant de supprimer le compteur, identifier les entités qu'on souhaite migrer et comparer avec les entités du mode standard en se basant sur les valeurs remontées pour trouver la correspondance.

[hekmon]

Bonnes nouvelles ! Merci pour vos retours 🙏

@theblackhole je mettrai à jour le readme lors du passage à la v3.0.0 stable et à ce moment là je mettrais directement un lien vers votre post pour votre (très complet !) walkthrough.

Tant qu'on est en beta, gardons les informations centralisées ici pour les aventuriers :)

[hekmon]

Tant que j'y suis, l'un de vous serait-il prêt à faire un screenshot de l'appareil et de toutes ses sondes ? Je suis curieux :D

(pensez à caviarder le numéro de série de la sonde "adresse du compteur")

[gduteil]

Tant que j'y suis, l'un de vous serait-il prêt à faire un screenshot de l'appareil et de toutes ses sondes ? Je suis curieux :D

(pensez à caviarder le numéro de série de la sonde "adresse du compteur")

Voici :

[hekmon]

Fiou ca en fait un petit paquet par rapport au mode historique, merci !

[gduteil]

Fiou ca en fait un petit paquet par rapport au mode historique, merci !

Oui, et encore il n'y a pas ceux pour le triphasé ni l'injection

[theblackhole]

@gduteil

Les correspondances des entités ont l'air correctes, pour l'énergie soutirée j'ai un doute, je pense que sans contrat heures creuses l'index 01 est le même relevé que le total (ce qui est mon cas) mais qu'avec un contrat heures creuses les relevés seront ventilés entre l'index 01 et 02.

Oui c'est ce que je pense aussi d'où les sondes sensor.linky_numero_de_lindex_tarifaire_en_cours qui indique quel index est utilisé actuellement et sensor.linky_libelle_tarif_fournisseur_en_cours à quoi il correspond (dans notre cas comme on n'a pas de HP/HC, ça sera toujours le 01)

J'ai également remarqué la présence des sondes distributeur qui donnent d'autres index. Elles n'ont pas de libellé dans HA mais on peut voir à quoi cela correspond sur l'affichage du compteur et quel index est en cours :

Je me demande si c'est une info transmise par le TIC que l'on pourrait récupérer. Car, perso, même si ça n'influe pas sur mon tarif, je trouve que c'est une donnée intéressante 🙂

@hekmon

Bonnes nouvelles ! Merci pour vos retours 🙏

Avec plaisir ! 😃

@theblackhole je mettrai à jour le readme lors du passage à la v3.0.0 stable et à ce moment là je mettrais directement un lien vers votre post pour votre (très complet !) walkthrough.

Tant qu'on est en beta, gardons les informations centralisées ici pour les aventuriers :)

Bonne idée ! ça permettra à d'autres testeurs de vérifier si la méthode est bonne pour tous avant de publier. Par contre pour en faciliter l'édition, je pense qu'il faudra que ça soit dans un nouveau Wiki Github, soit dans un nouveau fichier Markdown sur lequel tu pourras pointer le lien.

Tant que j'y suis, l'un de vous serait-il prêt à faire un screenshot de l'appareil et de toutes ses sondes ? Je suis curieux :D

Au passage je confirme que de mon côté, avec mon compteur G1, il n'y a pas de différence avec les captures de @gduteil 😉

Aussi je viens d'avoir une idée : est-ce que ce ne serait pas intéressant d'informer les utilisateurs actuels de la stable qu'une beta est disponible et que des testeurs ayant une situation différente de nous 2 sont les bienvenus (ex: HP/HC, Tempo, abonnement professionnel avec tarifs en fonction de l'heure/la saison, Triphasé, Producteur, autre marque de compteur...) ? Je ne sais pas si HACS propose un système de notification ou si ça passerait par une montée de version avec un rajout dans le readme et/ou détail dans la release peut-être ?

[hekmon]

J'ai également remarqué la présence des sondes distributeur qui donnent d'autres index. Elles n'ont pas de libellé dans HA mais on peut voir à quoi cela correspond sur l'affichage du compteur et quel index est en cours :
Je me demande si c'est une info transmise par le TIC que l'on pourrait récupérer. Car, perso, même si ça n'influe pas sur mon tarif, je trouve que c'est une donnée intéressante 🙂

Malheureusement je ne pense pas que ce soit possible, vu qu'elle ne sont pas décrites dans le standard TIC (la description du mode standard commence à la page 17).

Bonne idée ! ça permettra à d'autres testeurs de vérifier si la méthode est bonne pour tous avant de publier. Par contre pour en faciliter l'édition, je pense qu'il faudra que ça soit dans un nouveau Wiki Github, soit dans un nouveau fichier Markdown sur lequel tu pourras pointer le lien.

Je n'ai jamais utilisé le wiki intégré à github, il faut que je regarde ca avant la sortie de la v3 stable oui.

Aussi je viens d'avoir une idée : est-ce que ce ne serait pas intéressant d'informer les utilisateurs actuels de la stable qu'une beta est disponible et que des testeurs ayant une situation différente de nous 2 sont les bienvenus (ex: HP/HC, Tempo, abonnement professionnel avec tarifs en fonction de l'heure/la saison, Triphasé, Producteur, autre marque de compteur...) ? Je ne sais pas si HACS propose un système de notification ou si ça passerait par une montée de version avec un rajout dans le readme et/ou détail dans la release peut-être ?

Tout à fait. Pour HACS, c'est déjà disponible vu que je publie des releases "beta" dans github avec les bon tags (l'utilisateur doit néanmoins cocher "voir les préversions" ou quelque chose du genre). Pour ceux qui le font en manuel, je viens de mettre à jour le readme afin de renvoyer par ici :)

[gduteil]

@theblackhole j'ai personnellement opté pour l'utilisation du "linky_energie_active_soutiree_totale" qui a la même valeur que le 01 sans abonnement HC, mais ça me paraissait plus logique.

Bien vu pour la correspondance des index, je m'étais posé la question à quoi ça correspondait mais il n'y avait rien dans la doc, j'avais pas pensé à comparer avec les valeurs affichées directement sur le compteur. À voir s'il vaut mieux laisser les les entités avec ces noms là et mettre les correspondance dans le readme/wiki, quitte à ce que les utilisateurs les renomment s'ils le souhaitent ou s'il faut les renommer par défaut.

[theblackhole]

@hekmon

Malheureusement je ne pense pas que ce soit possible, vu qu'elle ne sont pas décrites dans le standard TIC (la description du mode standard commence à la page 17).

Ah dommage, en effet ça ne semble pas possible.
Par contre en lisant la doc, ça me fait penser la migration de sensor.linky_puissance_apparente vers sensor.linky_puissance_app_de_coupure serait peut-être plus adaptée que vers la sonde sensor.linky_puissance_app_de_reference que j'ai indiqué car maintenant la distinction est faite entre la puissance apparente souscrite et celle utilisée pour couper le compteur (ex: reduction en cas d'impayé j'imagine ?).
Qu'en pensez-vous ?

@gduteil

@theblackhole j'ai personnellement opté pour l'utilisation du "linky_energie_active_soutiree_totale" qui a la même valeur que le 01 sans abonnement HC, mais ça me paraissait plus logique.

Haaaaa mais je l'ai totalement manqué celui-là. En effet c'est beaucoup plus simple 😁
Par contre pas forcément adapté pour ceux qui voudraient suivre séparément les HC et HP mais je pense qu'ils auront d'autres index à mapper à ce moment là

À voir s'il vaut mieux laisser les les entités avec ces noms là et mettre les correspondance dans le readme/wiki, quitte à ce que les utilisateurs les renomment s'ils le souhaitent ou s'il faut les renommer par défaut.

Pour un renommage c'est une bonne idée mais il faudrait que ce soit fait en récupérant l'info dynamiquement et seulement au niveau du nom, pas de l'id.

Car la présence de ce fameux pointeur d'index avec libellé me laisse penser que ça peut être différent en fonction du fournisseur et des options choisis. (Par exemple: peut-être que pour EDF HP est en index 01 et HC en index 02 mais que pour Engie avec un contrat similaire ce serait un total en index 01, HC en 02 et HP en 03).

Ou alors l'intégration pourrait se référer à un tableau de correspondance adapté en fonction de chaque fournisseur et ses options (que l'utilisateur devrait renseigner dans les options de l'intégration). C'est plus embêtant à maintenir mais ça permettrait d'éviter de devoir attendre un cycle complet HP/HC par exemple pour avoir toutes les entités renommées.

[theblackhole]

@hekmon

Tout à fait. Pour HACS, c'est déjà disponible vu que je publie des releases "beta" dans github avec les bon tags (l'utilisateur doit néanmoins cocher "voir les préversions" ou quelque chose du genre). Pour ceux qui le font en manuel, je viens de mettre à jour le readme afin de renvoyer par ici :)

C'est bien ça avec la bêta à cocher pour avoir la maj.
Mais quand on est dans le canal stable et qu'une beta est publiée, HACS ne n'indique pas qu'une nouvelle version est disponible. D'où la notion de notification, quitte à passer par une nouvelle release stable (même s'il n'y a rien de nouveau) pour en informer les utilisateurs s'il n'y a pas d'autres moyens de notifier les utilisateurs actuels.

[theblackhole]

Top si ça fonctionne ! Ravi d'avoir pu aider :)
A voir avec le temps et les futurs redémarrages mais oui tu verras que c'est plus facile et stable de lier un hub à ta VM. Comme ça tous les périphériques branchés à ton hub seront automatiquement reconnus par ta VM sans changer de configuration dans proxmox.

Et si, au lieu d'un hub externe que tu branches, tu veux dédier un hub interne à ta VM tu peux les identifier en faisant lsusb (lsusb -t pour voir l'arborescence). Ils sont généralement appelés "Linux Foundation 2.0/3.0 root hub"

Exemple (cliquer pour dévoiler)

 ~  lsusb
Bus 006 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 005 Device 003: ID 1038:1208 SteelSeries ApS SteelSeries Apex 300 Gaming Keyboard
Bus 005 Device 002: ID 046d:c332 Logitech, Inc. G502 Proteus Spectrum Optical Mouse
Bus 005 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 002: ID 0b05:189d ASUSTek Computer, Inc. Xonar SoundCard
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 003: ID 051d:0002 American Power Conversion Uninterruptible Power Supply
Bus 001 Device 005: ID 0b0e:245d GN Netcom Jabra Link 370
Bus 001 Device 004: ID 05e3:0610 Genesys Logic, Inc. Hub
Bus 001 Device 002: ID 05e3:0608 Genesys Logic, Inc. Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

 ~  lsusb -t
/:  Bus 06.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 5000M
/:  Bus 05.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 480M
    |__ Port 1: Dev 2, If 0, Class=Human Interface Device, Driver=usbhid, 12M
    |__ Port 1: Dev 2, If 1, Class=Human Interface Device, Driver=usbhid, 12M
    |__ Port 2: Dev 3, If 0, Class=Human Interface Device, Driver=usbhid, 12M
    |__ Port 2: Dev 3, If 1, Class=Human Interface Device, Driver=usbhid, 12M
    |__ Port 2: Dev 3, If 2, Class=Human Interface Device, Driver=usbhid, 12M
/:  Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 10000M
/:  Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 480M
    |__ Port 1: Dev 2, If 0, Class=Audio, Driver=snd-usb-audio, 480M
    |__ Port 1: Dev 2, If 1, Class=Audio, Driver=snd-usb-audio, 480M
    |__ Port 1: Dev 2, If 2, Class=Audio, Driver=snd-usb-audio, 480M
    |__ Port 1: Dev 2, If 3, Class=Audio, Driver=snd-usb-audio, 480M
    |__ Port 1: Dev 2, If 4, Class=Audio, Driver=snd-usb-audio, 480M
    |__ Port 1: Dev 2, If 5, Class=Audio, Driver=snd-usb-audio, 480M
    |__ Port 1: Dev 2, If 6, Class=Human Interface Device, Driver=usbhid, 480M
/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 10000M
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/10p, 480M
    |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M
        |__ Port 2: Dev 4, If 0, Class=Hub, Driver=hub/4p, 480M
            |__ Port 2: Dev 5, If 0, Class=Audio, Driver=snd-usb-audio, 12M
            |__ Port 2: Dev 5, If 1, Class=Audio, Driver=snd-usb-audio, 12M
            |__ Port 2: Dev 5, If 2, Class=Audio, Driver=snd-usb-audio, 12M
            |__ Port 2: Dev 5, If 3, Class=Human Interface Device, Driver=usbhid, 12M
    |__ Port 2: Dev 3, If 0, Class=Human Interface Device, Driver=usbhid, 12M

Expérimente en déplaçant un appareil de port usb en port usb pour savoir quels ports usb correspondent à quel hub interne.
C'est ce (ou ces) hub(s) interne(s) choisi(s) que tu lieras à ta VM au lieu de chaque appareil.
Attention si tu n'en a qu'un hub (ou pas assez pour avoir des ports usb libres pour brancher une clé usb en cas de problème), alors il faudra utiliser un hub usb externe.
L'idée est d'éviter de se retrouver avec un proxmox que tu ne peux pas réparer/contrôler à cause de tous les appareils USB qui sont envoyés sur ta VM 😁

[yves67]

ok, merci
je viens de recréer le linky en mettant le lien symbolique et ça marche
je vais faire le zigbee
ok pour le HUB, je vais étudier cela demain
encore merci

[yves67]

depuis la machine promox voilà ce que je vois :

la VM 100 est le HA
mais je ne comprends pas comment ça marche
quand vous aurez un peu de temps merci de m'exliquer
MERCI

[theblackhole]

Salut @yves67 , désolé je t'avais oublié ^^
J'ai annoté ta capture pour que tu comprennes plus facilement ce qui est affiché

T'as 3 root_hub USB, chacun identifié par un numéro de Bus :

• un avec 4 appareils USB actuellement branchés dessus (Bus 1, cadre vert)
• un avec un appareil branché (Bus 2, cadre rouge)
• un libre (Bus 3, cadre jaune). En débranchant un appareil (ex: ton dongle bluetooth) et en relançant la commande, tu peux voir quelles prises usb correspondent à tel ou tel hub. Parfois un hub n'a pas de prise USB visible car il s'agit d'un hub interne
• une fois que t'as identifié le root_hub que tu veux dédier à ta VM (imaginons ici ton hub avec les 4 appareils, soit Bus 1 Dev 1, ID 1d6b:0002), c'est lui que tu lieras à ta VM à la place de chaque appareil USB que tu as lié un par un (Dev 5, 7, 12, 10). Ainsi, l'ensemble de ce que tu branches dessus sera disponible dans la VM.

Si t'as des questions, on peut poursuivre la discussion via MP Twitter ou mail, liens sur mon profil, car cette PR n'est pas l'endroit adapté pour ça. ;)

[romP44]

Bonjour,
Pouvez-vous m'expliquer comment installer la V3 sur Home Assistant pour avoir le mode standard ?
Je suis actuellement en version 2.0.7.

Edit : j'ai trouvé : https://hacs.xyz/docs/faq/beta

[jipem01]

Testé ce jour sur mon installation, Linky en mode standard :

• ADS n°67 non reconnu, me génère donc des erreurs dans les logs.
• Mon linky ne génère pas SINSTS, qui est indisponnible du coup. Par contre j'ai SINST1 à la place. Et non il ne s'agit pas de SINTS1 (liée au triphasé)
• Pareil dans les logs je vois SMAXN et SMAXN-1 au lieu de SMAXSN
  Quelques autres entitées sont indisponibles, il faut que je regarde si c'est normal.
  J'ai l'impression que sur mon ADS n°67 il y a quelques modifications des trames... Je vais fureté le net si je trouve de la documentation.

[bdecl]

J'ai testé la 3.0.0-beta3 (fresh install) sur ma config Linky triphasé (Sagem) - Standard - Producteur - Tempo - temps réel (on et off) - HA Green - Module Micro Téléinfo V3.0 et quasi tout fonctionne.

Ce qui ne donne pas de information mais certainement normal pour ma configuration:

• les 7 sensors en rapport les pointes mobiles
• sensor.linky_profil_du_prochain_jour_calendrier_fournisseur

Je reconfirme le mappage des index tempo (bleu, blanc, rouge) comme déjà mentionné plus haut:
HC Bleu: sensor.linky_energie_active_soutiree_fournisseur_index_01
HP Bleu: sensor.linky_energie_active_soutiree_fournisseur_index_02
HC Blanc: sensor.linky_energie_active_soutiree_fournisseur_index_03
HP Blanc: sensor.linky_energie_active_soutiree_fournisseur_index_04
HC Rouge: sensor.linky_energie_active_soutiree_fournisseur_index_05
HP Rouge: sensor.linky_energie_active_soutiree_fournisseur_index_06

HC Saison Basse : sensor.linky_energie_active_soutiree_distributeur_index_01
HP Saison Basse : sensor.linky_energie_active_soutiree_distributeur_index_02
HC Saison Haute : sensor.linky_energie_active_soutiree_distributeur_index_03
HP Saison Haute : sensor.linky_energie_active_soutiree_distributeur_index_04

Si je peux aider avec d'autres info, suffit de demander. Merci merci

[mruffat]

EDIT: Résolu ici : #19 (comment)

Bonjour,

J'utilise linkytic avec un Micro Téléinfo V3 depuis plusieurs mois maintenant. Je suis en triphasé avec un compteur mode standard. J’utilise donc la v3.0.0beta3 et cela fonctionne très bien. De temps en temps des capteurs deviennent indisponibles, notamment les capteurs de puissance instantanée mais rien de grave, cela ne dure que quelques secondes puis les valeurs reviennent. Par contre j'ai remarqué sur mon dashboard energie que l'indexe Bleu Heures Creuses ne bougeait plus depuis le 1er novembre :

Pourtant sur le compteur Linky l'indexe a bien augmenté. De plus, les indexes Blanc HP/HC ont bien augmenté ces derniers jours avec les premiers jours blancs. De plus l'indexe Bleu HP fonctionne aussi correctement. J'ai tenté de recharger l'intégration et de redémarrer mon serveur HA mais cela n'a rien changé. Est-ce que quelqu'un a une idée de ce qui peut poser problème ? Si des infos supplémentaires peuvent aider n'hésitez pas à me dire.

Merci par avance pour votre aide :)

[mruffat]

Petite investigation en activant les logs quelques instants, je trouve dans ce qui est reporté par l'extension la ligne suivante :

2024-11-17 23:03:39.422 DEBUG (LinkyTIC for /dev/ttyACM1) [custom_components.linkytic.serial_reader] line to parse: b'EASD01\t013004402\t.\r\n' 2024-11-17 23:03:39.423 DEBUG (LinkyTIC for /dev/ttyACM1) [custom_components.linkytic.serial_reader] line checksum is valid 2024-11-17 23:03:39.424 DEBUG (LinkyTIC for /dev/ttyACM1) [custom_components.linkytic.serial_reader] read the following values: EASD01 -> {'value': '013004402', 'timestamp': None}

Donc il semblerait que la valeur remontée par l'extension est bien celle fournie par la connexion série... Mais une fois de plus, sur l'écran du Linky la valeur de l'indexe HC Bleu est différente et a continué d'augmenter... Problème de liaison TIC du Linky en lui même (j'en doute) ? Ou alors problème avec mon module USB (je ne vois pas ce qui peut expliquer ce message) ? Ou encore l'extension aurait une sorte de cache qui boucle sur un vieux message ? Toute idée ou demande d'info supplémentaire est la bienvenue !

[mruffat]

Ok j'ai trouvé... et je me sens bête... J'utilisais le capteur linky_energie_active_soutiree_distributeur_index_01 au lieu du linky_energie_active_soutiree_fournisseur_index_01 qui pour ce dernier est bien à jour !
Quel différence entre les 2 et pourquoi le premier s'est arrêté au 1er Novembre, je ne sais pas mais si quelqu'un a la réponse ça m’intéresse d'apprendre :)

[theblackhole]

@mruffat Distributeur = ENEDIS (+entreprises locales de distribution), fournisseur = EDF et alternatives.
Entre fournisseur et distributeur chacun a sa définition des index (par exemple en fonction des contrat, la période HP/HC est différente ou pas d'HP/HC)
Je viens de regarder sur mon linky qui a le même comportement au premier novembre et l'arrêt de cet index marque le passage entre la "saison basse" et la "saison haute".
Tu peux le voir de différentes manières :

• sensor.linky_statut_tarif_contrat_distributeur indique l'index en cours qui sera le 3 (il y a l'équivalent pour le fournisseur)
• tu peux te référer au tableau de correspondances : Mode standard #19 (comment)

HC Saison Basse : sensor.linky_energie_active_soutiree_distributeur_index_01
HP Saison Basse : sensor.linky_energie_active_soutiree_distributeur_index_02
HC Saison Haute : sensor.linky_energie_active_soutiree_distributeur_index_03
HP Saison Haute : sensor.linky_energie_active_soutiree_distributeur_index_04

• si tu regardes ton index 03 il devrait commencer à mesurer au 1er novembre au moment où le 01 s'est arrêté

[mruffat]

Je comprends mieux ! Intéressant, merci beaucoup pour les explications :)

[theblackhole]

Avec plaisir ! :)

[bagnico]

Salut !
J'ai demandé a passer en STANDARD et ça a été effectif ce matin a 00h
J'ai pu récupérer mes conso en renommant les anciens ID :
edf_linky_energie_active_soutiree_fournisseur_index_02 -> HP BLEU
edf_linky_energie_active_soutiree_fournisseur_index_01 -> HC BLEU
edf_linky_energie_active_soutiree_fournisseur_index_04 -> HP BLANC
edf_linky_energie_active_soutiree_fournisseur_index_03 -> HC BLANC
edf_linky_energie_active_soutiree_fournisseur_index_06 -> HP ROUGE
edf_linky_energie_active_soutiree_fournisseur_index_05 -> HC ROUGE

Par contre je n'ai pas pu me servir de la méthode spécifiée ci-dessus, à savoir que quand j'essayais de réimporter le compteur en mode "HISTORIQUE" les id n'apparaissaient plus (certainement parce que la lecture dans ce mode du TIC c'était plus dispo)
Pas bien grave j'ai restauré HA au moment où le compteur était encore en HISTORIQUE, puis renommé les id, supprimé et ajouté le compteur en mode STANDARD et voilà

Merci pour cette nouvelle version, je projette d'installer des panneaux bientôt il fallait donc que je puisse récupérer l'injection

[romP44]

Merci pour cette nouvelle version, je projette d'installer des panneaux bientôt il fallait donc que je puisse récupérer l'injection

Pour avoir l'index d'injection, il faut un contrat de revente. Malheureusement ça ne marche pas quand on est en autoconsommation.

[bagnico]

Je ne savais pas que l'index d'injection n'était pas récupérable en TIC si on était pas en mode producteur, c'est complètement con...
Pour ma part ce n'est pas grave j'envisage un contrat avec EDF OA mais pour mon beau-frère c'est balo il faudra trouver une autre solution

Merci !

[theblackhole]

Je ne savais pas que l'index d'injection n'était pas récupérable en TIC si on était pas en mode producteur, c'est complètement con...

Perso ça me parait au contraire logique, pas d'injection dans le réseau de distribution, pas d'index d'injection ^^

Si tu seras en autoconsommation mais avec un contrat de revente de surplus, alors il y aura une injection et en toute logique tu devrais passer en mode producteur (à s'assurer à la signature du contrat au pire) et tu auras donc cet index qui servira à facturer le surplus injecté.

[bagnico]

Oui j’aurai le mode P
Et non c’est pas logique puisque l’index s’incrémente quand même sur le compteur, c’est juste ce n’est pas diffusé sur la TIC (mais tu peux faire un relevé à la main)

[romP44]

Oui je trouve ça dommage de l'afficher mais de ne pas l'avoir sur la télé info.
J'ai appelé Enedis il y a quelque mois pour demander à passer en mode producteur, évidemment sans succès.

[theblackhole]

@bagnico @romP44
Ah donc vous dites qu'avec panneaux solaires en autoconsommation sans revente de surplus, avec un compteur en mode consommateur donc, il y a quand même un index d'injection qui s'incrémente ?
Etrange, pour moi cet index représente une injection dans le réseau de distribution (=vers l'extérieur, pour pouvoir facturer justement. Et celui ci est normalement disponible sur TIC en mode Standard Producteur), sans revente donc pas d'injection (où alors vous êtes généreux et offrez votre électricité en surplus ? ^^). Ou alors ça serait un index différent ?

Je peux voir à quoi ça ressemble par curiosité cet index sur un de vos compteurs voir s'il y a un lien avec celui disponible en mode producteur évoqué dans la doc technique de la TIC ?

Car le seul système de panneau photovoltaïque que j'ai pu voir de mes propre yeux jusqu'ici est un système indépendant sur batterie sans revente, le reste que je connais ne sont que des recherches (ex1, ex2) donc curieux de mieux connaitre ce fonctionnement.

[clerelus]

Bonjour,
J'ai installé la v3.0.0-beta4 sur ma HomeAssistant/Raspberry Pi 4 équipée du module Lixee TIC Din. Tout s'est bien installé. Je suis avec un compteur Linky mode TIC Standard car j'ai une installation de panneaux solaires en autoconsommation et revente de surplus sur le réseau Enedis.

Cependant, je constate que les données remontées sur le module ne se rafraichissent pas. Toutes les données sont bonnes à l'instant de la récupération mais après cela ne se met pas à jour. Faut-il paramétrer quelque chose en particulier ?
Merci de votre aide.

[theblackhole]

Bonjour @clerelus,
Est-ce que les commandes décrites dans le README (https://github.com/hekmon/linkytic#configuration-du-module) font bien défiler les informations en continu ?

[clerelus]

Bonjour @theblackhole,

Merci pour ta réponse.

En tapant la commande cat /dev/ttyUSB1, j'ai bien le défilement en continu. En mode Historique, je n'avais aucun souci. J'avais bien les données en temps réel.

Pour info, je me suis aussi rapproché d'Enedis car la migration du mode Historique au mode Standard a été faite dimanche dernier.
Et depuis, je n'ai plus accès à la rubrique de gestion des accès à mes données sur leur site. Le souci vient peut être de là, j'attends leur retour.

Merci

[bagnico]

@clerelus c'est drôle parce que je suis passé le 23/11 au mode standard et je n'ai plus de remontées sur le site Enedis aussi depuis le 24
Pour le moment j'avoue que ça m'arrange puisque je suis en TEMPO (jour ROUGE aujourd'hui mais je suis décompté en BLEU) mais je prévois des panneaux solaires bientôt ce serait bien que le compteur communique

[jm-github]

J'ai eu le même genre de soucis de rafraichissement après avoir mis à jour de la beta3 à la beta4. Je suis revenu à la beta3 et ça fonctionne à nouveau

[bdecl]

Hello

Ma config: Triphasé, TIC standard, producteur, Tempo.

J'ai mis à jour de la beta 3 à la beta 5. J'ai observé les choses suivantes:

Le retour de dépassement est maintenant home ou away

Mode historique on == mode standard ?

J'ai du changer mes label dans mes automatisations. Les noms de tarifications (HC ROUGE, HP ROUGE, ...) ont moins d'espaces.

Pour le reste cela semble de bien fonctionner.

[bagnico]

Bonjour,
Je viens de passer sur la beta5 et j'observe également que le "mode historique" est maintenant sur "On" aussi.
Par ailleurs mon compteur ne communique plus chez ENEDIS depuis mon passage en standard, TEMPO ne fonctionnait plus également (annonce de couleur du lendemain HS, couleur du jour en "BLANC" et les jours suivants ont tous été comptés en BLEU).

Je n'avais pas fait le rapprochement avec le plugin mais j'ai vu dans les corrections des comportements similaires (#53 et #52)
Malheureusement je suis repassé sur une offre HPHC il y a quelques jours, ce qui a nécessité le déplacement d'un technicien ENEDIS pour la reprogrammation du compteur puisqu'il ne communiquait plus, après reboot du compteur il a communiqué quelques secondes et depuis plus rien, ce matin après la mise à jour en Beta5 le compteur est repassé en "Registered" concernant le CPL

Est-il possible que la beta4 soit à l'origine de ce dysfonctionnent ? Si c'est le cas t'as réussi un coup de maitre pour faire rester le compteur en BLEU lorsqu'on est en TEMPO toute l'année !

Je ferais une update demain matin pour vous dire si les données sont bien remontées chez Enedis.

[bagnico]

Fausse joie, le compteur n'a pas envoyé les infos a Enedis cette nuit et il est repassé en mode "NEW UNLOCK" à 19h hier...

[tomleglaunec]

Merci pour vos retours

Le retour de dépassement est maintenant home ou away

Effectivement, la classe BinarySensorDeviceClass.PRESENCE n'est pas très appropriée (pour moi présence faisait référence à un statut présent ou absent, c'est plutôt destiné à informer la présence à la maison d'un appareil/utilisateur), elle sera remplacé dans la prochaine release (ainsi que pour le capteur surtension)

Mode historique on == mode standard ?

Non, erreur de décodage, sera corrigé (comme ce registre n'est pas envoyé en mode historique, il n'a pas vraiment d'intérêt car théoriquement toujours égal à 1 mais bon c'est mieux de l'avoir à la bonne valeur...)

Est-il possible que la beta4 soit à l'origine de ce dysfonctionnent ?

Les compteurs Linky ne peuvent que transmettre des données mais sont incapables d'en recevoir sur la TIC, donc impossible que l'intégration soit à l'origine du problème, ou alors nous venons de trouver une vulnérabilité exploitable ;)
D'après ce que tu décris, c'est plutôt du coté infra Enedis ou sur ton Linky (firmware/hardware?) que se trouve le problème puisqu'ils n'arrivent pas à communiquer sur le CPL (tu ne reçois pas la couleur tempo et eux ne reçoivent pas les données de conso), pas de solution miracle ici
Pour en revenir au bug des registres de status, les valeurs étaient erronée car mal décodées, corrigé avec #54 (sauf pour le mode historique)

[bagnico]

Je trouvais ça peu probable mais on ne sait jamais, ça aurait été une belle vulnérabilité ^^
J'attends un peu, sinon je verrai avec Enedis pour le remplacer