Closed netweaver1970 closed 2 years ago
does the status page of ebusd-esp show acquired ebus signal after the soft reboot of it (without hardware reset)?
The screenshot is from before the reboot. When I'm restarting the add-on directly or via a HA restart, I need to soft restart the ebusd-esp. I never needed a physical restart to get it back ok
Using the MQTTretain flag also solves my issue. So for now fixed but I'm sure this is not working as you were thinking it should work,
did a rebuild from sources to 22.2. I had to do a reset again of the esp-ebusd suing the web frontend before HA (and/or ebusd) would again see the adapter WITH an aquired signal.
your description is hard to understand (at least for me) since you're mixing up ebusd, the HA addon, and potentially the ebusd HA integration settings. anyway, is this still an issue when using the latest ebusd-esp firmware, latest PIC firmware, and latest ebusd release?
After upgrading the PIC with latest version just now, it seems the issue is solved. Thanks.
Description at boot/restart of the EBUSD addon in HA, the ebus doesn't seem 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. Since the only thing changed from working to not working was the ebusd install: now as an HA add-on vs a standard binary on another RaspPi, I obviously (but wrongly) concluded that the issue must be in the current ebusd install and that's why I created it in the ebusd repo. Now re-opened here.
ebusd version 22.1.v22.1-31-g4cdac87
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
I tried also with latency=50 and latency blank (for auto). Same issue
Operating system Debian 11 (Bullseye) / Raspbian 11 / Ubuntu 20-21
CPU architecture arm64
Hardware interface adapter 3 WiFi
Related integration MQTT Home Assistant via mqtt-hassio.cfg
Logs![153785286-cf8b4d25-f355-4ce6-9fa3-4d53cf8396f3](https://user-images.githubusercontent.com/18028618/154642557-3bd91a8c-a35d-40de-823f-b852609b5960.png)
Then at 2:30AM I performed a reset of the ebus-esp (using the web frontend) and only then the EBUSD continues further. Sometimes I need to do multiple reboots (via the web interface) before the ebusd -> ebus-esp communication continues properly. Or whenever the ebus-esp 'works' good again.![153786134-875b1e88-cbf6-497f-9b7e-931e3dfe0f7b](https://user-images.githubusercontent.com/18028618/154642681-dc0b6226-21ec-4dca-99da-fdccca886715.png)