2 appareil détecté

[DizHell]

Bonjour,

Cela fait un moment que j'utilise votre solution avec mon capteur TIC USB, je recontre 2 problemes :

• L'intégration me detecte 2 appareils Linky un est vide et l'autre contient les ressources, les 2 porte le meme nom.
• Et tout les 15jours lorsque je fais ma sauvegarde vie Proxmox, (avec arret de la VM HA) l'intégration ne remonte plus aucunne info, je doit checker le dimande matin et redemarrer Home Assistant.

Je sais pas si les 2 sont lié, j'ai essayé de faire une automatisation pour redemarrer HomeAssistant le dimanche 2h aprés la sauvegarde mais cela ne fonctionne pas tout le temps.
Pour les appareils en doublon là je viens d'en desactiver un (faute de pouvoir supprimer) à voir si cela pose probleme.

[theblackhole]

Bonjour,

ça fait longtemps (toujours ?) que j'ai aussi cet affichage de 2 appareils un vide et un rempli mais je n'ai jamais prêté d'importance car ça n'impacte pas le fonctionnement du module

Quant au problème de connexion au redémarrage de la VM HA, je crois que j'avais eu ça en mode historique et j'avais peut-être résolu ça avec un changement de baudrate au démarrage de HAOS (j'ai un LiXee USB).
Depuis que je suis passé au mode standard je n'ai plus de soucis de ce côté. Je pense que le baudrate par défaut de la connexion série est le bon ce qui fait qu'il n'y a pas besoin de le changer.

Aussi si jamais ça peut t'aider, pour fiabiliser la connexion au démarrage (vu que j'ai plusieurs appareils USB en série comme le SkyConnect et le LinXee), j'utilise le chemin /dev/serial/by-id/ (ex /dev/serial/by-id/usb-Silicon_Labs_CP2102_USB_to_UART_Bridge_Controller_0001-if00-port0 pour mon LinXee) pour désigner mon module TIC plutôt que /dev/ttyUSB0 car il me semble qu'avec plusieurs appareils série USB l'attribution n'est pas forcément la même à chaque démarrage, un coup /dev/ttyUSB0 pourrait désigner le SkyConnect, un coup le LinXee. En faisant la référence par id, ça ne change pas car c'est un lien symbolique vers l'appareil réel (/dev/ttyUSB0 ou /dev/ttyUSB1 dans mon cas)

[tomleglaunec]

Bonjour,
Je prépare un patch pour passer la configuration d'un chemin /dev/tty* vers son équivalent /dev/serial/by-id qui devrait être persistant malgré les redémarrages (comme suggéré par @theblackhole). Pour ma part je n'ai pas eu de soucis sous proxmox. Par acquis de conscience, pouvez vous poster (@theblackhole, @DizHell) les entrées de l'intégration contenues dans le fichier .storage/core.config_entries ? Dans vos cas, il devrait y avoir 2 entrées pour le domaine "linkytic" :

[DizHell]

Merci @tomleglaunec pour ton retour rapide.
Voici mon config_entries
{ "entry_id": "e2db04df8a5e74552093c7b434545e4b", "version": 1, "minor_version": 1, "domain": "linkytic", "title": "/dev/ttyUSB0", "data": { "serial_device": "/dev/ttyUSB0", "tic_mode": "hist", "three_phase": false }, "options": { "real_time": false }, "pref_disable_new_entities": false, "pref_disable_polling": false, "source": "user", "unique_id": "linkytic_/dev/ttyUSB0", "disabled_by": null },

Pour la partie Proxmox, je suis en version 8.0.3, mais de mémoire j'avais deja le probleme en 7.
J'integre l'USB par identifiant USB :

La sauvegarde est géré par le Noeux en tache planifié, une mensuel en local qui marche :

Et un Hebdomadaire, stocké sur mon Nas en NFS qui elle pose probleme avec le linky :

J'ai donc refait un automatisme pour la prochaine fois au cas ou, pas encore testé (fait hier) :

[hekmon]

Bonjour @DizHell,

Concernant le double appareil c'est un bug qui a normalement été corrigé en v3.0.0-beta2 je vous laisse prendre connaissance des releases notes. Attention si vous faites l'upgrade, le module en est actuellement une version plus loin (la v3.0.0-beta3) : quelle version du module utilisez-vous ?

Concernant la perte de lien après le redémarrage de votre VM, sans logs de l'extension je ne peux me prononcer. Mais les pistes de @theblackhole et @tomleglaunec me semblent être pertinentes.

[theblackhole]

@tomleglaunec

Je n'ai qu'une entrée pour le domaine linkytic que voici :

      {
        "entry_id": "1cacc261c51d77ab6fbd732d8cf13c9e",
        "version": 1,
        "minor_version": 1,
        "domain": "linkytic",
        "title": "/dev/serial/by-id/usb-Silicon_Labs_CP2102_USB_to_UART_Bridge_Controller_0001-if00-port0",
        "data": {
          "serial_device": "/dev/serial/by-id/usb-Silicon_Labs_CP2102_USB_to_UART_Bridge_Controller_0001-if00-port0",
          "tic_mode": "std",
          "producer_mode": false,
          "three_phase": false
        },
        "options": {},
        "pref_disable_new_entities": false,
        "pref_disable_polling": false,
        "source": "user",
        "unique_id": "linkytic_/dev/serial/by-id/usb-Silicon_Labs_CP2102_USB_to_UART_Bridge_Controller_0001-if00-port0",
        "disabled_by": null
      },

De mon côté question setup c'est une VM HAOS hébergée sur ma Freebox Delta. Je sais que c'est du QEMU derrière et que je peux monter un port USB de la box (ce que j'ai fait avec un hub) mais je n'ai pas plus de détails sur le fonctionnement.

Édit suite au message simultané de @hekmon : Je suis bien sur la beta.3 et j'étais sur la beta.2 avant ça (j'ai eu un doute mais le sensor hacs "pending updates" me montre que j'étais bien à jour depuis cette release)

[DizHell]

Je suis en version officielle 2.0.7

Si tu ne cherche pas de testeur, et que la version finale ne tarde pas, je vais rester en version prod car il fait partie des modules obligatoire que j'utilise H24 du coup, je suis pas chaud pour passer sur la beta.

[tomleglaunec]

Merci @theblackhole et @DizHell pour vos retours, le doublon ne provient donc pas d'une desynchro du port matériel (passer sur le chemin par id est néanmoins la chose à faire pour supprimer le risque).
Un patch pour corriger le doublon sur le canal stable (2.0.8?) pourrait être la solution en attendant une release stable, mais de ma compréhension de HA le doublon de capteur devrait résulter en une erreur dans le log au démarrage (même id unique) et non en un nouvel appareil ! Quels sont les entités fournies par l'appareil doublon ?

[DizHell]

Le doublon n'a aucun appareil attaché il est vierge

[hekmon]

Un appareil vide finira par être supprimé par HA lui même (c'est justement en voyant le double appareil que j'ai fais le fix pour la beta-02 et le miens a fini par disparaitre). Seulement sans le fix, a chaque démarrage vous avez une petite chance, suivant l'ordonnancement d'initialisation de HA, de ré avoir la sonde binaire de connection dans un appareil séparé (réinitialisant de fait le temps nécessaire à HA pour nettoyer cet appareil vide).

Je suis en version officielle 2.0.7

Si tu ne cherche pas de testeur, et que la version finale ne tarde pas, je vais rester en version prod car il fait partie des modules obligatoire que j'utilise H24 du coup, je suis pas chaud pour passer sur la beta.

La beta concerne surtout le nouveau code pour le mode standard, de ce que je vois des messages précédents vous êtes en mode historique : le risque d'avoir un problème est très faible, cette partie du code n'ayant pas changé.

Je suis moi même en beta-3 alors que je suis aussi en mode historique. La version stable de la v3 sortira une fois que je serai passé moi même en mode standard et fais un test extensif de toutes les entités (et là dessus je ne saurai m'engager sur une date pour le moment).

Peut-être que ce fix devrait être backport en v2 pour une v2.0.8 comme le suggère @tomleglaunec .

[hekmon]

Merci @theblackhole et @DizHell pour vos retours, le doublon ne provient donc pas d'une desynchro du port matériel (passer sur le chemin par id est néanmoins la chose à faire pour supprimer le risque). Un patch pour corriger le doublon sur le canal stable (2.0.8?) pourrait être la solution en attendant une release stable, mais de ma compréhension de HA le doublon de capteur devrait résulter en une erreur dans le log au démarrage (même id unique) et non en un nouvel appareil ! Quels sont les entités fournies par l'appareil doublon ?

Le doublon provient de la sonde binaire pouvant s'initialiser avec les sondes "normales". Mais les informations permettant de créer et d'identifier l'appareil provenant de la sonde ADS, si la sonde binaire s'initialise avant la lecture et le parsing des infos sur le lien série de la sonde ADS, la sonde série déclare appartenir à un appareil sans informations a proprement parler. Les sondes suivantes ayant bien les informations ADS lues, elles se déclarent correctement dans un appareil avec les bonnes infos.

C'est le but du fix de la beta-02 : là où avant la sonde ADS portait le role de lecture et de parsing des infos ADS (puis les partageaient avec le contrôleur central) c'est maintenant le conteneur central qui porte cette logique permettant une extraction et la mises à disposition de ces infos AVANT l'initialisation des sondes. Ces dernières s'initialisent donc toutes avec les infos disponibles et se rattachent donc au même appareil.

[tomleglaunec]

@theblackhole Si tu es en beta3, tu devrais pourvoir supprimer le doublon car l'intégration n'est plus sensé le fournir (patché en beta2 d'après @hekmon). Est-ce le cas ?

[theblackhole]

@tomleglaunec Sauf s'il y a une option que je ne connais pas, dans l'interface on ne peut que désactiver un appareil, pas le supprimer complètement.

Après au niveau du dessus c'est toujours possible de supprimer complètement l'intégration (qui contient les 2 appareils) mais je n'ai pas envie de faire ça juste pour régler un problème purement visuel ^^

[tomleglaunec]

Ok effectivement j'ai confondu entrée et appareil... La dernière option serait de retirer manuellement l'entrée de l'appareil doublon dans le fichier .storage/core.device_registry mais si aucune info n'est remontée l'appareil devrait disparaitre de lui même

[tomleglaunec]

J'ai réussi à reproduire le bug en v3.0.0-beta3. Au démarrage, l'intégration va initier les capteurs même si le lecteur série n'est pas disponible (par exemple le dongle USB n'est plus connecté, migration de /dev/ttyXXX, pas de TIC connectée ou erreur de lecture) : les infos d'identification étant nulles, HA va créer un nouvel appareil (device_registry). Les entités restent identiques mais sont rattachés à l'appareil qui porte le même identifiant, ce qui explique les appareils vides constatés (une fois le bon identifiant, les entités sont rattachés au bon appareil).

La solution est donc de vérifier la bonne réception de la TIC (au moins le S/N) puis ensuite instancier les différents capteurs. Les capteurs ne doivent pas être instanciés si cet identifiant unique ne peut être lu (problème de connectivité au démarrage).

La documentation développeur au sujet des registres d'appareils dit :

If you connect a sensor to another device to read some of its data, it should still be represented as two different devices. The reason for this is that the sensor could be moved to read the data of another device.

Finalement, ne devrait-il pas y avoir un appareil qui représente l'interface TIC/USB et un second qui représente le compteur ?

PS: On peut supprimer sans risque les entrées du core.device_registry puisque ce sont les entités qui déclarent l'appareil à qui elles appartiennent.

[hekmon]

Cette partie de la documentation (et l'usage du via_device) est plutôt faite pour les ponts (par exemple le pont netatmo de chauffage, chaque vanne est un appareil mais qui est lié au pont initial qui peut posséder ses propres sensors, ou encore la station météo de netatmo dont la base propose ses propres sondes mais dont les modules additionnels dépendent pour rapatrier les leurs).

L'utilisation du via_device est ici possible mais je m'interroge sur l'utilité in fine : même en créant un device TIC/USB ne portant que le sensor du lien série, cela n'éliminerait pas complètement le problème :

• il suffit que lien entre le Linky et le module USB ne soit pas branché pour qu'au démarrage de Home Assistant les infos ne l'appareil ne soient pas récupérables et donc que la création à la volée de l'appareil ne puisse se faire avec les bonnes informations
• les sondes ne doivent pas être instanciées uniquement si le connection est bonne : elles doivent l'être rien que pour apparaitre indisponibles (il faudrait tester s'il est effectivement possible de rajouter des sondes à HA en dehors de la fonction d'initialisation du module, je n'en suis pas certain)
• mais dans ce cas l'instanciation des sondes (même en indisponibles) rencontrerait de nouveau le problème d'absence d'infos de l'appareil !

Étant donné qu'une fois une connection effectuée (avec le patch de la version beta) toutes les sondes sont rapatriées dans le bon appareil et qu'un appareil vide finira par être nettoyé par HA je me pose la question de savoir si complexifier le code pour gérer un cas à la marge vaut bien le coup.

TL;DR

• avec le patch de la v3 beta la probabilité d'avoir un appareil fantôme devient très faible (uniquement en cas de mauvaise connection)
• une fois la connection corrigée, toutes les sondes s'auto corrigent d'elles même laissant l'appareil sans information vide et donc nettoyable par Home Assistant
• tenter d'éviter de créer un appareil vide est possible mais non trivial je pense
• je ne suis pas convaincu que le jeu en vaille la chandelle

Je laisse cette issue ouverte pour y réfléchir.

[theblackhole]

Pour ma part ça fait longtemps que cet appareil vide existe et vu que ça n'impacte pas les fonctionnalités, ça ne m'a jamais dérangé.
Par contre je ne sais pas au bout de combien de temps HA est censé le nettoyer car depuis qu'il existe, il y a eu plein de mises à jour d'HA, HAOS, HACS et du module en lui-même et rien n'a changé.

Peut-être qu'une solution pas trop compliquée (?) serait éventuellement de proposer, dans la configuration de l'intégration > dans une section "avancée" cachée de base, le nettoyage de cet appareil vide ? Ou une détection avec notif avec proposition de nettoyage ? (A moins que ce soit déjà le cas avec le commit de @tomleglaunec ?)

[tomleglaunec]

Je suis d'accord, il n'y a pas d'intérêt à ajouter un appareil juste pour l'interface TIC/USB.
La solution facile que j'ai implémenté et testé est la suivante (au démarrage de l'intégration):

1. Tester l'ouverture de la communication série
2. Vérifier la lecture de l'adresse du compteur (ce qui permet aussi d'assurer que l'identifiant est présent à l'instanciation des capteurs)
3. Tout cela encadré par un timeout (5 secondes actuellement)

Si l'un des items échoue au démarrage de l'intégration, la fonction async_setup_entry remontera l'erreur ConfigEntryNotReady, qui signifiera à l'utilisateur qu'un problème est présent et les entités ne seront pas instanciés.

HA essayera périodiquement de relancer l'intégration, donc s'il s'agit d'un défaut temporaire ça n'impactera pas le fonctionnement global de l'intégration. Les entités resteront dans un état indisponible en attendant la résolution du problème (automatique ou nécessitant l'intervention de l'utilisateur).
Qu'en pensez vous ?

En plus de ça, le chemin /dev/tty* est enregistré via son équivalent persistant by-id si disponible (il me semble que ça dépend du type d'installation HA).

PS: @theblackhole oui il me semble qu'une telle option est disponible, à voir si ça peut résoudre le conflit actuel sans trop de travail, je commence à douter du fait que HA nettoiera le registre d'appareil de lui-même...

[yves67]

j'ai installé aussi la béta 3.0, en mode historique, triphasé
et je viens de voir que j'ai 3 appareils:

[theblackhole]

Belle collection ! 😄

[yves67]

heureusement qu'un seul ne fonctionne, mais je n'arrive pas à supprimer les 2 qui n'ont pas d'identités ..

[hekmon]

@tomleglaunec J'aime bien l'approche ConfigEntryNotReady (à voir si cette erreur là est la plus propice à notre cas de figure) si HA tente effectivement périodiquement de relancer le setup ca pourrait être une bonne approche :

• initialisation de l'integration (avant l'init des plateformes)
• attente de la lecture d'au moins une trame complete sinon ConfigEntryNotReady / integration not initialized
• initialisation des plateformes (qui attentent pour le moment qu'au moins une trame complète soit lue justement pour avoir l'ADS caché dans le controleur et pouvoir déclarer l'appartenance au bon appareil)

D'ailleurs avec une telle approche je me demande même si le binary sensor est encore bien utile : le simple fait que les sensors soient fonctionnels donne l'information de savoir si le lien série est ok ou non. Cela permettrait de supprimer le binary sensor, seul sensor de la plateform binary sensor et de n'initialiser que la plateforme sensor. J'aime bien.

Pour ce qui est du /dev/by-id/... par contre pour moi l'integration ne peux pas le faire d'elle même :

• si je dis a mon intégration "lis ce fichier" elle doit lire ce fichier et pas un autre (plus un programme fais de la magie cachée, plus les futurs debug sont compliqués)
• par exemple avec du HA sous docker, il est nécessaire de passer le device explicitement, donc ce genre de magie ne marcherait pas

Par contre je suis d'accord avec vous que (comme pour les disques ou les interfaces réseaux sous linux) les identifiants dynamiques sont à éviter. Donc pour moi la question est plutôt de l'ordre : Comment orientez l'utilisateur pour qu'il rentre un chemin d'identifiant unique au moment de l'initialisation ? Cela pourrait être :

• une partie de readme consacré à cela
• un script dans le repo qui permet de trouver tout seul le chemin "fixe" d'un device (un helper pre configuration par exemple)
• un changements des textes (préremplissage du field texte et/ou description UI) qui orienterait l'utilisateur vers cela

[theblackhole]

@hekmon

Pour ce qui est du /dev/by-id/... par contre pour moi l'integration ne peux pas le faire d'elle même :
(...)

Alors peut-être que c'est le privilège des addons officiels mais il existe un mécanisme bien fait sur les addons Silab Multiprotocol et OpenThread Border Router : les appareils série sont récoltés et listés dans un menu déroulant, et le fait d'y trouver un nom incite naturellement à le choisir 🙂 .

J'ai vu cette section dans leur fichier de conf qui pourrait être lié, je ne sais pas si c'est un standard HA, un truc que seul les addons officiels peuvent avoir ou un truc custom qu'ils ont fait (et qu'il y a bien plus de choses derrière) mais ça pourrait être une piste à explorer peut-être si ce n'est pas déjà fait ?

• silabs-multiprotocol/config.yaml#L43-L44
• openthread_border_router/config.yaml#L39-L40

[tomleglaunec]

J'aime bien l'approche ConfigEntryNotReady (à voir si cette erreur là est la plus propice à notre cas de figure) si HA tente effectivement périodiquement de relancer le setup ca pourrait être une bonne approche (...)

ConfigEntryNotReady est l'erreur à renvoyer en cas d'échec d'initialisation avec la possibilité de remonter un message contextuel visible par l'utilisateur.

Pour ce qui est du /dev/by-id/... par contre pour moi l'integration ne peux pas le faire d'elle même (...)

Le module homeassistant.components.usb fournit un utilitaire get_serial_by_id qui renvoie le chemin persistant (qui n'est autre qu'un lien symbolique vers le vrai /dev, mais qui ne dépend que des propriétés intrinsèques USB) s'il est disponible, le cas contraire le chemin fournit par l'utilisateur est utilisée.

Dans les deux cas, je me suis inspiré de l'intégration officielle zha.
J'ajoute encore quelques optimisations au niveau des capteurs et je proposerai une PR, le code ajoutant ces fonctions est déjà disponible sur ma fork.

De la même manière, comme propose @theblackhole, lister les ports séries/USB (via serial.tools.list_ports.comportspar exemple) dans le ConfigFlow pourrait aider l'utilisateur dans son choix.