Closed pierrepinon closed 9 months ago
Bad logger message: Sensor sensor.linky_812161027472_erq2 has device class 'power', state class 'None' unit 'VArh' and suggested precision 'None' thus indicating it has a numeric value; however, it has the non-numeric value: '''' (<class 'str'>) Bad logger message: Sensor sensor.linky_812161027472_erq3 has device class 'power', state class 'None' unit 'VArh' and suggested precision 'None' thus indicating it has a numeric value; however, it has the non-numeric value: '''' (<class 'str'>) Bad logger message: Sensor sensor.linky_812161027472_erq4 has device class 'power', state class 'None' unit 'VArh' and suggested precision 'None' thus indicating it has a numeric value; however, it has the non-numeric value: '''' (<class 'str'>) Bad logger message: Sensor sensor.linky_812161027472_irms2 has device class 'current', state class 'measurement' unit 'A' and suggested precision 'None' thus indicating it has a numeric value; however, it has the non-numeric value: '''' (<class 'str'>) Bad logger message: Sensor sensor.linky_812161027472_irms3 has device class 'current', state class 'measurement' unit 'A' and suggested precision 'None' thus indicating it has a numeric value; however, it has the non-numeric value: '''' (<class 'str'>)
J'ai beaucoup d'erreur de cast dans les logs
ValueError: could not convert string to float: "''"
Possible de rollback ? Car là c'est inutilisable en l'état pour tout le monde à mon avis
Le plugin teleinfo avait-il été redémarré récemment ?
Car outre les changements sur le module, je pense que c'est HA lui-même qui constitue les id des sensors différemment en concaténant les infos qui viennent du "device".
De même pour les warnings au sujet des class des devices et des states.
Etant donné que teleinfo2mqtt publie les configs des sensors pour la découverte au démarrage uniquement, il est possible que ces warnings étaient latents depuis plus longtemps que ça.
J'étais sur la dernière version et le dernier start date de moins d'une semaine. Les errors ont été publiés après le start du container
J'ai rollback la version référencée sur hass.io le temps d'y voir plus clair.
Même soucis ici sur la dernière version (en container docker non via hass.io)
Dans les logs on a
2023-11-28 00:21:11.266 ERROR (MainThread) [homeassistant.components.mqtt.models] Exception raised when updating state of sensor.linky_pmax, topic: 'teleinfo/__HIDDEN__' with payload: b'{"ADCO":{"raw":"__HIDDEN__","value":__HIDDEN__},"OPTARIF":{"raw":"BBR(","value":"BBR("},"ISOUSC":{"raw":"30","value":30},"BBRHCJB":{"raw":"005229277","value":5229277},"BBRHPJB":{"raw":"002239162","value":2239162},"BBRHCJW":{"raw":"000088750","value":88750},"BBRHPJW":{"raw":"000075998","value":75998},"BBRHCJR":{"raw":"000006197","value":6197},"BBRHPJR":{"raw":"000002092","value":2092},"PTEC":{"raw":"HCJW","value":"HCJW"},"DEMAIN":{"raw":"BLAN","value":"BLAN"},"IINST":{"raw":"008","value":8},"IMAX":{"raw":"090","value":90},"PAPP":{"raw":"01920","value":1920},"HHPHC":{"raw":"A","value":"A"}}'
Traceback (most recent call last):
File "/lsiopy/lib/python3.11/site-packages/homeassistant/components/sensor/__init__.py", line 616, in state
numerical_value = int(value)
^^^^^^^^^^
ValueError: invalid literal for int() with base 10: "''"
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/lsiopy/lib/python3.11/site-packages/homeassistant/components/sensor/__init__.py", line 619, in state
numerical_value = float(value)
^^^^^^^^^^^^
ValueError: could not convert string to float: "''"
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File "/lsiopy/lib/python3.11/site-packages/homeassistant/components/mqtt/models.py", line 305, in process_write_state_requests
entity.async_write_ha_state()
File "/lsiopy/lib/python3.11/site-packages/homeassistant/helpers/entity.py", line 743, in async_write_ha_state
self._async_write_ha_state()
File "/lsiopy/lib/python3.11/site-packages/homeassistant/helpers/entity.py", line 843, in _async_write_ha_state
state, attr = self._async_generate_attributes()
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/lsiopy/lib/python3.11/site-packages/homeassistant/helpers/entity.py", line 784, in _async_generate_attributes
state = self._stringify_state(available)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/lsiopy/lib/python3.11/site-packages/homeassistant/helpers/entity.py", line 749, in _stringify_state
if (state := self.state) is None:
^^^^^^^^^^
File "/lsiopy/lib/python3.11/site-packages/homeassistant/components/sensor/__init__.py", line 623, in state
raise ValueError(
ValueError: Sensor sensor.linky_pmax has device class 'power', state class 'None' unit 'W' and suggested precision 'None' thus indicating it has a numeric value; however, it has the non-numeric value: '''' (<class 'str'>)
ça se voit sur le contenu mais je suis en offre TEMPO
En creusant plus je me rend compte qu'il a été créé plein de nouvelles entitées qui ne correspondent pas à mes entitées (+ qui sont différentes des anciennes où il y avait l'id du linky)
Si je supprime totalement l'appareil sur home assistant et que je relance le container (en dernière version). L'appareil se recrée mais
En espérant que cela puisse t'aider à debug, n'hésites pas si besoin de plus de précisions
En creusant plus je me rend compte qu'il a été créé plein de nouvelles entitées qui ne correspondent pas à mes entitée
Oui, c'est une des modifs qui a été apportée. C'est à dire qu'on créé tous les sensors qui correspondent au mode de téléinfo (historique ou standard) quel que soit l'offre edf (tempo, base...) Les quelques sensors non utilisés par l'offre en cours resteront à "unknown".
Cela permet d'avoir une découverte fonctionnelle côté HA même chez les utilisateurs qui ont fréquemment des trames corrompues.
Si je rollback en 8.3.3
, j'ai mes id qui sont également foirés car HA concatène les id du "device" (linky$adco) et les id du sensor ("teleinfo$adco_xxx")
Ce qui donne des id de sensors différents et à rallonge ()
La payload de découverte est :
{
"unique_id":"teleinfo_0123456789_ADCO",
"name":"Teleinfo 0123456789 ADCO",
"state_topic":"teleinfo/0123456789",
"value_template":"{% if 'ADCO' in value_json %}{{ value_json.ADCO.raw }}{% else %}''{% endif %}",
"device":{
"identifiers":[
"0123456789"
],
"manufacturer":"Enedis",
"model":"linky_0123456789",
"name":"Linky 0123456789"
}
}
Et HA me donne le unique_id suivant sensor.linky_0123456789_teleinfo_0123456789_adco
Vous avez le même comportement ? Est-ce que HA ne s'est pas mis à définir des unique_id différement à partir d'une certaines version ?
Pour ma part, j'ai rollback avec une sauvegarde toute mon instance, car effectivement c'était un peu la foire
Il me semble que HA a changé des choses, mais je n'arrive plus à trouver l'info, je tiens au courant
Je me demande si ce n'est pas le même problème qu'observé ici sur le changement de nom dans HA cet été : https://github.com/Koenkk/zigbee2mqtt/issues/18445
Plus particulièrement ce changement
J'ai remarqué que le unique_id est différent de l'entity_id (au moins dernièrement). Le unique_id n'est utilisé qu'en interne sur home assistant et référence toujours la même entité. C'est pour ça que je n'ai vu les différents nom qu'en supprimant complètement l'appareil.
J'ai fait des modifs pour avoir les id des sensors sous la forme sensor.teleinfo_$id-compteur_$etiquette
.
Par exemple : sensor.teleinfo_0123456789_bbrhpjw
Vous pouvez tester la version fmartinou/teleinfo2mqtt:fix__70_break_entity_id
et me faire un retour, svp ?
Salut @fmartinou
Cela semble ok chez moi. Après avoir complètement supprimé l'appareil Teleinfo de HA. J'ai lancé le container sur la nouvelle version et les entités sont bien arrivées avec leur ancien nom (et sans le nom à rallonge).
Les entités manquantes de mon dernier post sont aussi bien présentes.
Je pense qu'on est ok !
Merci pour ton feedback rapide. 👍 Je vais releaser une version fix dans la journée du coup 😀
Released as 9.0.2
Bonsoir,
Depuis la dernière mise à jour, l'ensemble des sensors ont changés de nom et malgré les publications sur le broker MQTT, aucun sensor ne sont mise à jour...