Bonjour,
J’essaie l’intégration externe ebusd de @Will_71 (ghcr.io/william-de71/gladys-ebusd:0.1.0) et le test échoue alors que tout semble correct de mon côté. Pouvez-vous me dire si le problème vient de l’intégration ?
Environnement
- Gladys Assistant 5.3.2 sur Gladys OS (Raspberry Pi 5, Raspberry Pi OS Trixie 64 bits, image flashée avec Raspberry Pi Imager). Conteneurs :
gladys,watchtower,ebusd,gladys-ext-william-de71-gladys-ebusd. - ebusd
john30/ebusd26.1.26.1 en Docker sur le même Pi (192.168.1.13) :
docker run -d --name=ebusd --restart=unless-stopped -p 8888:8888 john30/ebusd --scanconfig -d ens:192.168.1.14:9999 - Adaptateur : eBUS Adapter Stick C6 (ESP32-C6), firmware 20261109, en Wi-Fi (192.168.1.14), protocole enhanced sur TCP. Page Status de l’adaptateur : « ebusd connected : yes », « eBUS signal : no signal » (normal, voir plus bas).
Réglages de l’adaptateur (Enhanced protocol, TCP) :
- Chaudière : Vaillant, pas encore branchée (je prépare l’installation avant de la raccorder). Le signal eBUS est donc « no signal » pour l’instant.
Configuration de l’intégration
Adresse d’ebusd : 192.168.1.13 (sans http://), port 8888, utilisateur et secret vides, « Autoriser les modifications » décoché. La configuration s’enregistre sans problème.
Ce que j’observe
Le test affiche ebusd ne répond pas à 192.168.1.13:8888 (element not found) et le badge reste sur « Déconnecté » :
Quelques minutes plus tôt, avec la même configuration, un autre message était apparu : « ebusd répond mais n’entend rien sur l’eBUS : vérifiez l’adaptateur et son câblage ». Aucune erreur dans docker logs gladys-ext-william-de71-gladys-ebusd (seulement [gladys-sdk] connected to Gladys).
Ce qui montre qu’ebusd est joignable et fonctionne
docker exec ebusd ebusctl info:
version: ebusd 26.1.26.1
device: 192.168.1.14:9999, TCP, enhanced, firmware 1.1[6b09].1[6b09]
signal: no signal
reconnects: 0
masters: 1
messages: 11
address 31: master #8, ebusd
address 36: slave #8, ebusd
docker exec ebusd ebusctl find:
Broadcast Datetime = no data stored
Broadcast Error = no data stored
Broadcast Id = no data stored
Broadcast IdAnswer = no data stored
Broadcast Signoflife = no data stored
Memory Eeprom = no data stored
Memory Ram = no data stored
Ebusd répond correctement et ne connaît que ses 7 messages internes, sans aucun appareil Vaillant, puisque la chaudière n’est pas branchée.
nc -vz 192.168.1.13 8888depuis le Pi : succeeded.- Depuis l’intérieur du conteneur de l’intégration (
net.connectsous Node) :172.30.0.1:8888OK et192.168.1.13:8888OK. - ebusd tourne depuis plusieurs heures sans reconnexion.
Mon hypothèse
element not found semble être une réponse d’ebusd à une commande qui cible un élément absent. Je l’ai reproduit à la main :
docker exec ebusd ebusctl find -c bai
ERR: element not found
(bai est le circuit de la chaudière Vaillant, absent chez moi puisqu’elle n’est pas branchée.) En revanche, un simple ebusctl find fonctionne et ne renvoie pas cette erreur. L’intégration traite peut-être cette réponse comme une panne (« ebusd ne répond pas ») alors qu’ebusd répond bien et signale simplement que l’élément n’existe pas encore.
Mes questions
- Est-ce bien cette réponse (
ERR: element not found, par exemple sur une recherche de circuit commebai) que l’intégration reçoit ? Dans ce cas, peut-elle être traitée comme « aucun appareil trouvé » plutôt que comme une panne quand le bus est vide ? - Faut-il que la chaudière soit branchée et détectée par ebusd pour que le test réussisse ?
- Y a-t-il un moyen d’obtenir des logs plus détaillés dans le conteneur de l’intégration ?
Je peux fournir d’autres logs ou captures. Merci d’avance !
maintenant ca fonctionne.