Hola,
Estoy probando la integración externa ebusd de @Will_71 (ghcr.io/william-de71/gladys-ebusd:0.1.0) y la prueba falla aunque todo parece correcto por mi parte. ¿Podrían decirme si el problema viene de la integración?
Entorno
- Gladys Assistant 5.3.2 en Gladys OS (Raspberry Pi 5, Raspberry Pi OS Trixie 64 bits, imagen flashada con Raspberry Pi Imager). Contenedores:
gladys,watchtower,ebusd,gladys-ext-william-de71-gladys-ebusd. - ebusd
john30/ebusd26.1.26.1 en Docker en el mismo 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 - Adaptador: eBUS Adapter Stick C6 (ESP32-C6), firmware 20261109, en Wi-Fi (192.168.1.14), protocolo enhanced sobre TCP. Página de estado del adaptador: « ebusd connected: yes », « eBUS signal: no signal » (normal, ver más abajo).
Configuración del adaptador (Protocolo Enhanced, TCP):
- Caldera: Vaillant, todavía no conectada (estoy preparando la instalación antes de conectarla). La señal eBUS es por lo tanto « no signal » por ahora.
Configuración de la integración
Dirección de ebusd: 192.168.1.13 (sin http://), puerto 8888, usuario y secreto vacíos, « Permitir modificaciones » desmarcado. La configuración se registra sin problemas.
Lo que observo
La prueba muestra ebusd no responde a 192.168.1.13:8888 (element not found) y el badge permanece en « Desconectado »:
Unos minutos antes, con la misma configuración, otro mensaje apareció: « ebusd responde pero no escucha nada en el eBUS: verifique el adaptador y su cableado ». No hay errores en docker logs gladys-ext-william-de71-gladys-ebusd (solo [gladys-sdk] connected to Gladys).
Lo que muestra que ebusd es accesible y funciona
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 responde correctamente y solo conoce sus 7 mensajes internos, sin ningún dispositivo Vaillant, ya que la caldera no está conectada.
nc -vz 192.168.1.13 8888desde el Pi: succeeded.- Desde el interior del contenedor de la integración (
net.connectbajo Node):172.30.0.1:8888OK y192.168.1.13:8888OK. - ebusd lleva funcionando varias horas sin reconexión.
Mi hipótesis
element not found parece ser una respuesta de ebusd a un comando que apunta a un elemento ausente. Lo he reproducido manualmente:
docker exec ebusd ebusctl find -c bai
ERR: element not found
(bai es el circuito de la caldera Vaillant, ausente en mi caso ya que no está conectada.) En cambio, un simple ebusctl find funciona y no devuelve este error. La integración puede estar tratando esta respuesta como una falla (« ebusd no responde ») cuando en realidad ebusd sí responde e indica simplemente que el elemento no existe aún.
Mis preguntas
- ¿Es esta respuesta (
ERR: element not found, por ejemplo en una búsqueda de circuito comobai) la que recibe la integración? En ese caso, ¿podría ser tratada como « no se encontró ningún dispositivo » en lugar de como una falla cuando el bus está vacío? - ¿Es necesario que la caldera esté conectada y detectada por ebusd para que la prueba sea exitosa?
- ¿Hay alguna manera de obtener registros más detallados en el contenedor de la integración?
¡Puedo proporcionar más registros o capturas! ¡Gracias de antemano!
ahora funciona.