Plusieurs Erreurs about linkytic HOT 6 CLOSED

Bonjour @baby-scarf ,

Regardons cela ensemble.

1ère erreur
La première erreur tout d'abord, en soit elle n'a rien d'inquiétant. Chaque ligne sur la connexion série possède à la fin un checksum pour valider l'intégrité de la ligne (et permettre de détecter une ligne invalide et éviter la remontée d'une mauvaise information). Cela peut arriver de temps en temps d'avoir une ligne invalide pour diverses raisons (mauvaise qualité du lien série, perturbation électromagnétique changeant la valeur d'un bit, etc...). L'important est simplement de ne pas en avoir trop souvent (sinon le câble ou le module série devrait être examinés voir remplacés).

En y regardant de plus près, le checksum remonté par l'erreur semble être 0x7f ce qui est normalement (c'est à dire d'après le standard Enedis)... impossible : celui-ci de devrait se trouver qu'entre 0x20 et 0x5f. Il semble donc que la perturbation ait impacté les bits composant le checksum (le nom du tag ISOUSC et sa valeure 45 semblent elles être normales) et l'intégration a donc décidé de ne pas prendre en compte cette dernière ne pouvant la vérifier. Comportement normal donc.

2eme erreur
Concernant la seconde erreur, c'est elle qui vous cause problème dans le sens où elle arrête le thread de série car l'erreur n'est pas prévue. Cette dernière prend racine lors de la formation d'une erreur de lecture série (comme la première) mais n'arrive pas à finaliser la remontée de cette erreur (où vous auriez eu une erreur du même format que la première).

Le détails de la seconde erreur semble indiquer que cette fois ci le tag comporte des bits invalides, amenant la définition d'un seul caractère (in position 2) hors des valeurs possibles de l'encoding ASCII utilisé par ENEDIS sur le lien TIC.

Donc ?
Je vais regarder pour publier rapidement une nouvelle version gérant correctement la seconde erreur pour éviter le crash du thread de gestion de la connexion série (je n'avais encore jamais eu de problèmes à ce niveau là) : cela ne corrigera pas l'erreur en elle même mais, comme pour la première, cela permettra de mettre la ligne de côté et de continuer à traiter les suivantes : l'intégration continuera de fonctionner malgré ces erreurs.

Par contre... Je ne vous cache qu'il est hautement inhabituel d'avoir autant d'erreurs sur un lien série et en aussi peu de temps. Quel module TIC/série utilisez vous ? La connexion série entre le TIC du Linky et le module est-elle bien en place ? Le câble n'est-il pas abimé ? Y a-t-il une source de pollution électromagnétique proche ? (des câbles trop fins pourraient être simplement trop sensibles par rapport a des câbles gainés).

from linkytic.

Pouvez-vous essayer la version 2.0.5 ? Elle devrait éviter l'arrêt de fonctionnement de l'intégration pour les cas comme votre seconde erreur.

Je vous encourage tout de même à surveiller les logs de l'intégration et les erreurs de validation de lignes (comme votre première erreur) : il peut arriver d'en avoir mais cela est sensé être des cas rares et isolés et non fréquents (cf mon dernier message).

from linkytic.

Bonjour,

merci pour votre efficacité et rapidité, je vais essayé de répondre à vos questions.
J’utilise un module fabriqué par moi à base optocoupleur 814 et quelques résistances relié au linky avec du câble fin téléphone, pourtant ce module même fonctionné très bien avec domoticz.
si c’est vraiment mon module après plusieurs essais je le remplacerai par la suite.
Tous mon matériel est branché au niveau de tableau général proche de la freebox, un Rflink.
J’ai mis en place votre correction ce matin je vous tiens informer de la suite .

une question : est il possible de branché mon module directement sur le port GPIO du raspberry comme je fesais avant pour domoticz ?

from linkytic.

Un log après 1 heure de fonctionnement :

Logger: custom_components.linkytic.serial_reader
Source: custom_components/linkytic/serial_reader.py:112
Integration: Linky TIC (documentation, issues)
First occurred: 06:44:57 (66 occurrences)
Last logged: 07:51:54

Failed to validate the checksum of line 'b'ISOUSC 45 \x7f'': ISOUSC -> 45 (None) | s1 607 0b1001011111 | truncated 31 0b11111 � | computed 63 0b111111 ? | expected 127 0b1111111 �
Failed to validate the checksum of line 'b'\xbfPTARIF HC.. <'': -> HC.. (None) | s1 908 0b1110001100 | truncated 12 0b1100 | computed 44 0b101100 , | expected 60 0b111100 <
Failed to validate the checksum of line 'b'?(TARIF HC.. <'': ?(TARIF -> HC.. (None) | s1 740 0b1011100100 | truncated 36 0b100100 $ | computed 68 0b1000100 D | expected 60 0b111100 <
Failed to validate the checksum of line 'b'?PTARIF HC.. <'': ?PTARIF -> HC.. (None) | s1 780 0b1100001100 | truncated 12 0b1100 | computed 44 0b101100 , | expected 60 0b111100 <
Failed to validate the checksum of line 'b'M?\xaaDETAT 000000 B'': -> 000000 (None) | s1 1000 0b1111101000 | truncated 40 0b101000 ( | computed 72 0b1001000 H | expected 66 0b1000010 B

from linkytic.

J’utilise un module fabriqué par moi à base optocoupleur 814 et quelques résistances relié au linky avec du câble fin téléphone, pourtant ce module même fonctionné très bien avec domoticz.

Il est possible que domoticz mettait simplement de côté les lignes invalides silencieusement quand j'ai décidé de les faire remonter (justement pour aider l'utilisateur a détecter un mauvais module ou lien). Mais je ne peux le dire avec certitude, je n'ai pas regardé le code de domoticz.

une question : est il possible de branché mon module directement sur le port GPIO du raspberry comme je fesais avant pour domoticz ?

Je ne saurais dire, malheureusement mon domaine (software) commence là où le hardware fini :)

First occurred: 06:44:57 (66 occurrences)
Last logged: 07:51:54

~1 erreur/minute sur le lien série c'est clairement beaucoup

Failed to validate the checksum of line 'b'ISOUSC 45 \x7f'': ISOUSC -> 45 (None) | s1 607 0b1001011111 | truncated 31 0b11111 � | computed 63 0b111111 ? | expected 127 0b1111111 �

tag ok, valeur ok, checksum ko

Failed to validate the checksum of line 'b'\xbfPTARIF HC.. <'': -> HC.. (None) | s1 908 0b1110001100 | truncated 12 0b1100 | computed 44 0b101100 , | expected 60 0b111100 <
Failed to validate the checksum of line 'b'\xbfPTARIF HC.. <'': -> HC.. (None) | s1 908 0b1110001100 | truncated 12 0b1100 | computed 44 0b101100 , | expected 60 0b111100 <
Failed to validate the checksum of line 'b'?(TARIF HC.. <'': ?(TARIF -> HC.. (None) | s1 740 0b1011100100 | truncated 36 0b100100 $ | computed 68 0b1000100 D | expected 60 0b111100 <
Failed to validate the checksum of line 'b'?PTARIF HC.. <'': ?PTARIF -> HC.. (None) | s1 780 0b1100001100 | truncated 12 0b1100 | computed 44 0b101100 , | expected 60 0b111100 <
Failed to validate the checksum of line 'b'M?\xaaDETAT 000000 B'': -> 000000 (None) | s1 1000 0b1111101000 | truncated 40 0b101000 ( | computed 72 0b1001000 H | expected 66 0b1000010 B

tag ko, valeur ok, checksum inconnu

Cela confirme ma conclusion précédente, vous avez beaucoup de lignes incorrectes en provenance du lien série. Mon intégration doit pouvoir les gérer tout en continuant de fonctionner, c'était le but de la mise à jour et si vous avez de nouveau une erreur de type Uncaught thread exception (celle-ci stoppant l'execution de l'intégration) prévenez moi que je rajoute un correctif.

Maintenant concernant vos erreurs/trames incorrectes en provenance du lien série, je ne saurais dire... Est-ce votre Linky qui est défectueux ? Votre connexion TIC ? Votre module série ? Le cablage ? J'ai bien peur que le seul moyen de le savoir serait de changer un élément après l'autre jusqu'à identifier le coupable. Ou alors simplement conserver l'ensemble tel quel et laisser l'intégration mettre de côté les lignes problématiques :)

from linkytic.

Bonjour @baby-scarf ,

Sans retour de votre part je me verrai contraint de fermer cette issue.

from linkytic.