Etrange, ça se connecte puis au bout de quelques secondes l’outil se déconnecte…
— Connexion perdue: AMQJS0008I Socket closed.
09:04:27 — Reçu sur ERT3/tic/tarif : 0.0000
09:04:27 — Reçu sur ERT3/tic/abonnement : BBRHPJB
09:04:27 — Reçu sur ERT3/total_prix/inj : 0.00
09:04:27 — Reçu sur ERT3/total_prix/gaz : 0.00
09:04:27 — Reçu sur ERT3/total_prix/eau : 0.00
09:04:27 — Reçu sur ERT3/total_prix/discharge : 0.00
09:04:27 — Reçu sur ERT3/total_prix/charge : 0.00
J’ai supprimé le CLIENT ID et plus de problème.
On peut bien activer les relais du RT3 indépendamment
.
J’attends toujkours mon EBX connect pour tester le X8R
Du coup je découvre un bug du RT3. Dans TIC, je n’ai qu’une étiquette malgré un redémarrrage du RT3

Pourquoi toutes les étiquettes ne sont pas présentes ?
C’est vraiment dommage que même dans MQTT tout soit difusé sous forme de tableau. Même ça c’est fait à l’ancienne
… Ca serait tellement plus propre de faire des objets JSON avec le nom des compteurs. La grosse problématique ici que le mapping dans les tableaux peut changer si on modifie les compteurs.
Ca aurait tellement mieux d’avoir ce genre d’info en exemple
EDRT3
▶device(8 topics, 14 messages)
▼Nom de la Torre 1 = {"index torre":1,"puissance":150.2,"puissance apparente":451.2,"power_facror":0.5,......."device":{"applicationVersion":0,"dateCode":"20250116","friendlyName":"Sonde Buanderie","hardwareVersion":0,"ieeeAddr":"0x142d41fffe2fb1c4","manufacturerID":4742,"manufacturerName":"SONOFF","model":"SNZB-02D","networkAddress":56410,"powerSource":"Battery","softwareBuil…
▼Nom de la Torre 2 = {"index torre":2,"puissance":150.2,"puissance",......
Autre exemple d’une prise connectée MQTT de l’objet JSON. Sans parler d’avoir autant d’info, ce type d’objet est bien plus ouvert.
{
"current": 0.75,
"device": {
"applicationVersion": 2,
"dateCode": "",
"friendlyName": "Prise Info Bureau",
"hardwareVersion": 1,
"ieeeAddr": "0xdc8e95fffe42d26a",
"manufacturerID": 4190,
"manufacturerName": "Schneider Electric",
"model": "EKO09716",
"networkAddress": 42900,
"powerSource": "Mains (single phase)",
"softwareBuildID": "002.009.001 R",
"stackVersion": 6,
"type": "Router",
"zclVersion": 3
},
"energy": 368.83,
"indicator_mode": "always_on",
"last_seen": "2026-06-19T09:52:49+02:00",
"last_seen": "2026-06-19T09:52:50+02:00",
"linkquality": 152,
"power": 101.04,
"power": 110.21,
"power_on_behavior": "on",
"state": "ON",
"voltage": 233
}
C’est un début d’exemple que j’ai essayé de proposer. Il faudrait ça pour tout en fait. Et en utilisant lesq sous topics pour les catégories (ça c’est bien le cas à date).
Les avantages c’est que ça permet aussi de rajouter des infos dans le JSON suivant l’évolution des produits en étant rétro compatible et sans rien cassé. Là actuellement que ça soit à l’utilisation (modification dans les compteurs) ou du aux developpeurs, il y a de forte probabilité d’avcoir des régressions… Quel dommage
@GCE pour ne pas avoir de regression pour les futurs devs, si vous modifiez le MQTT, je vous conseille de diffuser en parallèle des nouveaux topics (exemple : relay_state_v2) pour ne pas casser l’existant
Là mêmes les relais sont sous forme de tableau sans le nom.