inconsistent connection made from EBUSD (as HA Add-on) to the ebus-esp (Wemos D1 mini on EBUS adapter V3)

[netweaver1970]

Description

Sometimes the EBUSD addon in HA doesn't recognize the ebusd-esp as being 'active/working' and then seems to 'hang' at the ebus-esp communication side. The rest of the EBUSD tasks seem to continue. The log shows the adapter is resetting, while the HTTP page from the ebusd-esp show all ok, no problem and is responding fine to navigation steps.

Then, when resetting the ebusd-esp from the web control panel, the EBUSD addon most of the times finally proceeds with doing the bus scan, reading config files etc.

Actual behavior

when the ebusd-esp in a working state, the EBUSD often doesn't proceed with the scan because it thinks it's resetting

Expected behavior

when the ebusd-esp in a working state, the EBUSD software should always be able to connect, without the need for a manual Wemos D1 mini reset.

I never saw this behaviour with my old EBUSD install of last year..

ebusd version

latest release

ebusd arguments

ebusd --foreground --mqtthost=core-mosquitto --mqttport=1883 --mqttuser=ebusd --mqttpass=???? --scanconfig --latency=10 --accesslevel=* --device=enh:192.168.0.95:9999 --log=all:notice --log=bus:notice --mqttvar=filter-direction=r|u|^w --mqttint=/etc/ebusd/mqtt-hassio.cfg --mqttjson

Operating system

Debian 11 (Bullseye) / Raspbian 11 / Ubuntu 20-21

CPU architecture

arm64

Dockerized

same as ebusd version

Hardware interface

adapter 3 WiFi

Related integration

MQTT Home Assistant via mqtt-hassio.cfg

Logs

Then at 2:30AM I performed a reset of the ebus-esp (using the web frontend) and only then the EBUSD continues further

[netweaver1970]

seems very similar behaviour to john30/ebusd-esp#55

[john30]

as stated in the issue template, this is not related to ebusd at all but obiously to ebusd-esp. therefore closed