Je pense que la version que j’utilise n’est plus une bêta, donc je préfère lancer une nouvelle discussion que d’utiliser une des discussions existantes sur les versions bêta.
Tous les jours à 00:10 j’ai l’erreur suivante dans les messages Jeedom :
Error on teleinfo::calculateOtherStats() : Call to a member function getStatistique() on null
Tous les jours vers 4h30 du matin j’ai les entrées suivantes dans le log du démon :
Error on send request to jeedom HTTPConnectionPool(host='127.0.0.1', port=80): Read timed out. (read timeout=120) retry : 0/3
Error on send request to jeedom HTTPConnectionPool(host='127.0.0.1', port=80): Read timed out. (read timeout=120) retry : 1/3
Error on send request to jeedom HTTPConnectionPool(host='127.0.0.1', port=80): Read timed out. (read timeout=120) retry : 2/3
Critical error on send_changes_async local variable 'r' referenced before assignment
Sont-ce des problèmes connus ? Comment puis-je aider à les résoudre ?
pour les erreurs vers 00h10 c’est de ma faute, j’ai modifié le calcul des stat en rajoutant un champ global. Il faudrait que tu ailles dans les options du plugin et que tu revalides même sans rien modifier:
Pour ton erreur à 4h30 alors là je ne vois pas. La variable r non assignée fait partie des choses que je n’ai pas touchées. Il se passe qq chose chez toi à 4h30 qui fait que le plugin ne peut pas envoyer vers jeedom, un des équipement de ton réseau lan redémarre à cette heure là?
Pour savoir si ça fonctionne avant demain matin tu peux aller dans le gestionnaire de tâches et lancer manuellement « calculateotherstat » de teleinfo.
Pour ton pb de 4h30, je regarde mais j’ai l’impression que tu as un redémarrage du plugin et qu’il a du mal à communiquer avec jeedom à ce moment là, parfois ça passe au 2ème essai parfois non c’est étrange. Il faudrait savoir pourquoi il relance le démon
Et pour ton pb de 4h30 tu n’aurais pas une tâche qui s’executerait dans ces heures là, genre un backup ou autre? Chez moi le backup est programmé à 5h24.
J’ai la même chose dans le log de rfxcom (avec le même code incorrect qui utilise r dans le handler d’exception alors que la variable n’a pas été initialisée, d’ailleurs…).
Et je n’ai toujours pas décidé de purger les données d’historique depuis le début… alors le .tar.gz de la sauvegarde fait 251MB dans lequel le DB_backup.sql fait 1.5GB
? Déverminer ? Diagnostiquer ? Investiguer ? Enfin, chercher d’où ça vient… 
