Je viens d’avoir les mêmes erreurs que toi, mais pas suite à une mise à jour OTA : j’ai changé le coordinateur zigbee, de connbee 2 à zzh!
Voir ce post : ZigbeeLinker changement de coordinateur - #8 par vmath54
Lors de la manip, j’ai supprimé dans le dossier /var/www/html/plugins/zigbee2mqtt/data/zigbee2mqtt les fichiers database.db et state.json ; la doc officielle zigbee2mqtt (FAQ | Zigbee2MQTT) ne précisait pas de supprimer le fichier state.json.
Ce fichier semble contenir les dernières valeurs recueillies par zigbee2mqtt des équipements zigbee appairés.
J’ai changé la clé, modifié la conf en conséquence, relancé les dépendances (pas nécessaire), redémarré, et appairé à nouveau les équipements.
Ca a fonctionné pour tous les équipements, sauf le Zlinky_TIC. Je l’ai bien appairé, il dialogue bien avec le zzh!, le lqi remonte bien, mais aucun autre attribut ne remonte ; et j’ai les mêmes erreurs que toi, du genre :
No converter available for 'current_summ-delivered' ("")
J’ai d’abord pensé à un problème lié à une éventuelle nouvelle version de zigbee2mqtt qui serait bugguée, puisque le message indique que zigbee2mqtt ne trouvait pas de ‹ converter › pour les attributs du Zlinky_TIC.
Après pas mal de recherches, je me suis apercu que dans ces messages, il y avait toujours cela à la fin : (« »)
Ca correspond à la donnée que le converter doit traiter ; dans le cas de l’attribut ‹ current_summ-delivered ›, ca devrait être une donnée numérique, alors qu’il est vide.
C’est cela qui provoque les messages d’erreur.
Donc, ces messages viennent du fait que les données ne remontent pas du Zlinky_TIC, et qu’il n’y a plus d’historique, puisque j’ai viré l’ancien fichier state.json.
Les données ne remontent pas, parce que j’ai mis ‹ measurement_poll_interval › à -1 (ce paramètre a été maintenu lors de la manip, car il se trouve dans le fichier configuration.yaml), mais les ajustements que j’avais mis dans l’onglet ‹ rapport › n’ont pas été maintenus ; je suppose qu’ils sont mémorisés dans le fichier database.db. Voir mon post un peu plus haut dans ce sujet.
J’ai passé ‹ measurement_poll_interval › à 300 (la valeur -1 est probablement inappropriée), et j’ai reparamétré les attributs de l’onglet ‹ rapport › comme dans mon post précédent.
redémarrage du démon, et tout est rentré dans l’ordre …