ce que je peux essayer de faire est de manipuler les relais du RT3 via l’API plutot que MQTT, même si l’API est une cata et que l’on ne peut pas piloter un relais unitaire.
Ca permettrait disoler MQTT et les relais
Non tu n’est pas le seul. Le RT3 esr instable et plante par moment ce qui induit la déconnexion du réseau du RT3. Et il est necessaire de le couper électriquement pour le relancer.
Pas certains que ca soit lié à l’utilisation de MQTT sur le RT3.
Pour ma part il y a peut etre une interraction avec les relais via les api ou mqtt
Je t invite à ouvrir un ticket sur le site GCE. Plus ils auront de cas plus ça leur permettra de corriger rapidement.
J’ai ajouté 3 problemes et un point positif sur mon post initial en fin de liste.
Update du post princiap pour MAJ suite version 1.1.0
Update du post principal => Découverte du bug critique en TIC standard ou les index TIC repassent à 0 quelques instants dans l’API lors du reboot ou plantage RT3. Non présent en mode historique à priori. Bug déjà présent en v1.0.0
bonjour @loic69
Est-ce un bug de l’ED3 ou une interprétation de HA des valeurs = 0 quand il y a pas de remontée suite à une déconnexion de l’ED3 que ce soit suite à reboot ou plantage ?
Un bug de l’ED3 signalé à GCE on voit bien toutes les valeurs à 0 dans l’API json.
En revanche oui j’ai du bricoler le availability dans HA pour rendre unvailable le sensor rest si valeur à 0 mais c’est du bricolage temporaire
pas logique !
- si reboot, l’API en peut pas répondre pendant la durée du reboot mais ensuite elle ne devrait répondre qu’une fois toute l’initialisation terminée au lieu d’envoyer des valeurs = 0 , pas vraiment un bug mais plutôt un cas de figure non pris en compte qui aurait du l’être !
si plantage, l’API ne peut répondre que si c’est que l’IHM qui est plantée (ce qui sembles être le cas puisqu’elle envoie des valeurs = 0 ce qui n’est pas logique non plus)
Manques peut-être un « heartbeat » au niveau de l’ED3 (API et MQTT) qui validerait le json…
Je sais pas exactement. Ce qui est sur c’est que ça me le fait depuis que je suis passé en TIC standard lundi. J’ai regardé dans mes logs HA avant, il n’y avait pas le problème. De toute fçacon ça se voit tout de suite car mes graphs dans le pannel energy HA explosent (passage de 0 à leur valeur initiale réelle…)
EDIT : C’est quand le RT3 revient sur le réseau apres le reboot, l’API répond avec des valeurs à 0. Je pense que c’est un bug alors que toute l’initialisation du hardware ne doit pas être prête. Ensuite on ne sait pas comment s’est fait dans le firmware. Le serveur web qui sert l’interface web est peut etre différent du serveur HTTP API. Seul GCE à la réponse.
Si certains ont le problème, voici le workaround HA en attendant que le problème soit corrigé. C’est sale mais pas moyen de faire différemment
# --- Index Tempo ---
# availability filtre unavailable/unknown ET les 0 provisoires (seuil bas) => Bug du RT3 en mode standard ou l'API renvoie des 0 au reboot du RT3 quelques instants
- name: "rt2_teleinfo_tempo_bleu_HC"
unique_id: rt2_teleinfo_tempo_bleu_HC
value_template: "{{ value_json.EASF01 | int }}"
availability: "{{ value_json.EASF01 | is_number and value_json.EASF01 | int > 0 }}"
device_class: energy
unit_of_measurement: "Wh"
state_class: total_increasing
icon: "mdi:flash"
le contournement ! 
Bonjour,
J’ai effectué la mise à jour samedi soir, sans soucis.
J’ai ensuite mis en place un script qui actionne les relais en MQTT depuis jeedom, toutes les 30 sec.
Aucun plantage depuis samedi soir et malgré les sollicitations des relais.
Tu as fait ça pour des tests ? Actionner des relais toutes les 30 secondes ?
Pour ma part je n’ai eu qu’un seul plantage qui m’a obligé à faire un reboot depuis la mise à jour. Par contre j’ai toujours des plantages (comme en v1) mais avec le RT3 qui reboot automatiquement. J’arrive à le détecter car mes sensors HA provenant de l’API remontent en non disponible
Mon ED3 plantait après avoir actionné les relais en MQTT, ou sous 5j sans raison. Donc, oui comme test, j’ai actionné les relais toutes les 30 secondes depuis Jeedom.
Je n’ai pas détecté de reboot automatique, mais j’imagine que cela doit se lire dans les logs. J’irais voir ce soir.
Il n’y a pas grand chose dans les logs et pas tres exploitable. C’est dommage de ne pas avoir plus d’info.
Mais oui ca semble être mieux avec la v1.1. Par contre il y a tjs un cas qui le fait planter mais il est encore aléatoire pour moi
Bonjour @loic69
Question bête mais tu es sur quel port pour l’ED3 ? Peut-être tester sur un autre port ?
Quel port de quoi ?
Pas compris
Je comprends pas. Il n y a qu un seul port RJ45 sur l’ED3. Non ce n’est pas le port de mon switch qui coupe quand le RT3 plante. Un simple téléchargement du fichier de configuration coupe la stack IP dans le RT3… idem un upload pour restauration de configuration.
Ma config IP est bonne également
il faudrait mettre le port sur 50080 par exemple pour voir si c’est pas une attaque sur le port 80 de l’ED3 qui provoque les reboot