Issues reading/writing to ebus

palonsorodriguez commented 1 year ago

Description

Hi John & ebud team. Thanks very much for your efforts. What you've created is impressive

Issue

My heatpump is managed from Home assistant so I can heat the water during low energy prices or when my solar panels have surplus energy. I'm experiencing long delays reading/writing data from/to ebus (minutes, even hours) via ebusd

Environment

eBUS Adapter v5 (Wifi).
Docker version 24.0.5
ebusd: image version 23.2-amd64-devel on ubuntu Ubuntu 20.04.6 LTS
mqtt + Home Assistant
Heatpump: Saunier Duval Genia Air (https://www.saunierduval.es/para-el-profesional/productos/genia-air-72640.html)
Env: using ens, ebusd latency=75

Actual behavior

Symptoms

I noticed that very often the heatpump is having a hard time following the commands written by Home Assistant timely and the heatpump started/stopped when it was not desired, and also the read water temp variable doesn't update for a long time, not being able to see the actual temp.
Among others I'm reading HwcStorageTemp and writting to HwcTempDesired On the other hand, I'm able to read/write the same variables almost instantly using the heatpump remote (MiPro Sense)

Troubleshooting

Wifi looks stable and strong (AP is less than 1m from the adapter), getting signal 100%, -29dBm Doing a ping from the ubuntu (where docker is running) to ebusd adapter

25 packets transmitted, 25 received, 0% packet loss, time 24037ms
rtt min/avg/max/mdev = 3.279/10.690/51.585/9.607 ms

Tried different latency values in ebus env variables ranging from 50 to 200 (ms)

Stopped Home Assistant (so no active client is using the bus) and run manual commands reading/writting to ebusd and noticed that often it takes 3/4 tries until a successful attempt, eg:

when reading from ebus

read -f -c bass2 HwcStorageTemp
ERR: SYN received

read -f -c bass2 HwcStorageTemp
ERR: wrong symbol received

read -f -c bass2 HwcStorageTemp
ERR: read timeout

read -f -c bass2 HwcStorageTemp
35

when writing to ebus

write -c bass2 HwcTempDesired 65
ERR: read timeout

write -c bass2 HwcTempDesired 65
ERR: SYN received

write -c bass2 HwcTempDesired 65
done

Expected behavior

I used a different adapter before and I didn't experience this issue, but I had other stability issues, so I decided to use the official ebusd adapter

ebusd version

23.2

ebusd arguments

docker-compose.yaml

version: '3'
services:
  ebusd:
    image: john30/ebusd:devel
    container_name: ebusd
    restart: unless-stopped
    ports:
      - 8888:8888
      - 8080:8080
    environment:
      EBUSD_DEVICE: "ens:192.168.0.7:9999"
      EBUSD_LATENCY: 75
      EBUSD_CONFIGPATH: "/config"
      EBUSD_SCANCONFIG: full
      EBUSD_CONFIGLANG: "en"
      EBUSD_POLLINTERVAL: 15
      EBUSD_ADDRESS: ff
      EBUSD_ANSWER: ""
      EBUSD_PORT: 8888
      EBUSD_HTTPPORT: 8080
      BUSD_HTMLPATH: "/var/ebusd/html"
      EBUSD_LOGFILE: "/var/log/ebusd.log"
      EBUSD_LOG: "all:info"
      EBUSD_LOGAREAS: all
      EBUSD_LOGRAWDATA: ""
      EBUSD_MQTTHOST: "192.168.0.243"
      EBUSD_MQTTPORT: 1883
      EBUSD_MQTTTOPIC: "ebusd"
      EBUSD_MQTTINT: "/config/ebusdconfig/mqtt-hassio.cfg"
      EBUSD_MQTTVAR: "filter-direction=r|u|^w"
      EBUSD_MQTTJSON: ""
    volumes:
      - /mnt/docker/ebusd-configuration/latest/en:/config
      - /etc/localtime:/etc/localtime:ro

Operating system

Debian 11 (Bullseye) / Ubuntu 20-21 / Raspbian 11 / Raspberry Pi OS 11 (including lite)

CPU architecture

x64

Dockerized

devel

Hardware interface

adapter 5 via USB

Related integration

TCP (cmdline client like ebusctl or netcat), MQTT Home Assistant via mqtt-hassio.cfg

Logs

Finally I scripted the readings so I can have timestamps to be able to correlate to the logs. Below one reproduction of the issue

Note: the script reads HwcStorageTemp. If it is not a number it will wait 3 seconds and try again until it gets a number, in the case below until it reads 59°C

./getHwcTemp.sh 2023-09-27T22:55:37+00:00Z value: ERR: SYN received isnumber:false retry:0 2023-09-27T22:55:43+00:00Z value: ERR: SYN received isnumber:false retry:1 2023-09-27T22:55:48+00:00Z value: ERR: read timeout isnumber:false retry:2 2023-09-27T22:55:53+00:00Z value: 59 isnumber:true retry:3

The corresponding ebus logs are attached here ebusd_2023_09_27.log

Thanks very much for your help!!! Pablo

palonsorodriguez commented 1 year ago

Note: ebusd fw Build: 20230917

john30 commented 1 year ago

the wifi latency seems way too high e.g. on 2023-09-27 22:55:48.480 it suggests that it took 44ms to transfer a single byte to the adapter. this way it can't work as the SYN generator on the bus jumps in ("SYN received"). do you have a lot of other wifi nets around that disturb yours?

palonsorodriguez commented 1 year ago

Hi John, Thanks very much for pointing me in a good direction. When you mention that it took 44ms to transfer a single byte to the adapter, which are the relevant lines in the logs so I can find them while testing? My adapter addres is ff while the heating is 15 at the starting timestamp I can read

2023-09-27 22:55:48.480 [bus notice] >ff15
2023-09-27 22:55:48.480 [bus debug] notify request: ERR: SYN received
2023-09-27 22:55:48.480 [bus error] send to 15: ERR: SYN received, retry
2023-09-27 22:55:48.480 [bus debug] ERR: SYN received during send command, switching to ready
2023-09-27 22:55:48.480 [bus debug] start request ff
2023-09-27 22:55:48.480 [bus debug] arbitration start with ff

Which is the line you pointed that happens 44ms later? What I can see about that timeframe is

2023-09-27 22:55:48.611 [bus debug] arbitration lost (timed out)
2023-09-27 22:55:48.611 [bus debug] ERR: arbitration lost during ready, retry
2023-09-27 22:55:48.611 [bus debug] start request ff
2023-09-27 22:55:48.611 [bus debug] arbitration start with ff
2023-09-27 22:55:48.674 [bus notice] <15
2023-09-27 22:55:48.675 [bus debug] ERR: SYN received during receive command, switching to ready

Yes, there are quite a few wifi networks. Some of them are IoT devices (eg, Shelly https://www.shelly.com/en-es). I've shut down as many net as I could & tried to lower my AP signal. After that did a ping test, and looks like the latency average is about 15 ms.

--- 192.168.0.7 ping statistics ---
500 packets transmitted, 499 received, 0.2% packet loss, time 499713ms
rtt min/avg/max/mdev = 2.630/15.159/134.885/15.806 ms

Is that still too much? What is the maximum recommended?

Thanks a lot! Best regards

john30 commented 1 year ago

this is the difference to the previous log entry 2023-09-27 22:55:48.436 [bus debug] arbitration won.

the critical delay is the AUTO-SYN that is allowed to appear anywhere between 30ms and 45ms after the last byte seen on the bus. consequently, sending a byte the interface and receiving it back in total may not take longer than 30ms.

with 15ms average ping delay, you're right at the edge of it and the maximum is awfully high, too. whenever you hit such a high delay in the middle of writing something to the interface, you'll see exactly those messages in the log

MarkusGH commented 1 year ago

Had similar issues here. I use multiple access points with identical SSID. Unfortunately there is no easy way to choose to which of those APs the ebus adapter connects and for some reason it always connected to a "distant" AP, resulting in huge latency spikes. Reconfigured it to connect to a different SSID which is only broadcasted by the "closest" AP and the problems went away.

MarkusGH commented 1 year ago

So if you are using multiple APs or (even worse) some kind of WLAN repeaters be aware that the ebus adapter seems not always to connect to the AP with the strongest signal.

Xyaren commented 1 year ago

Is there a way to force a specific AP to be used ? (By using a mac address or alike ?)

john30 commented 1 year ago

you can check with the newest firmware 20231015 that now does a full scan to find the strongest AP

mczubin commented 1 year ago

I just wanted to comment that I also had the above problem: random timeouts and syn errors. As expected, the device connected to a very distant AP.

The latest firmware looks like it has resolved the issue. Regardless, I ordered the Ethernet addon (since it's sitting next to the switch).

Thanks again, @john30 !

Xyaren commented 1 year ago

you can check with the newest firmware 20231015 that now does a full scan to find the strongest AP

Unfortunately the errors remain. So far: Wifi: unusable Raspberry PI via GPIO: Stable Laptop via USB: Stable

Xyaren commented 1 year ago

I did some testing. I remove every other device from my wifi and moved the adapter ontop of my AP(Router). The adapter show 100% (-20db). Even then I get an average ping of about 60ms to 100ms. If I do the same with other devices on my wifi network I get much lower ping around 3-4ms.

That smells a bit fishy..

Now the fun bit:

When i simultaniously open my browser on http:///logo.svg and refresh the hell out of the page (aka generate traffic) the ping goes down to 1ms (quite stable).

Is suspect the ebus-adapter's wifi adapter goes into some kind of sleep state ? @john30 Can you confirm this ?

john30 commented 1 year ago

how does that fit to your other post where you wrote that pings are below 1ms?

anyway, what exactly do you mean with "Wifi: unstable"? what is the measurement for stability you are using? some logs would be helpful as well probably

Xyaren commented 1 year ago

Unusable meaning that I can't get a successful scan done. The 1ms were false due to an error in my testing (pinged the wrong host). The adapter is about 3 meters away from my router, short ebus cable to the heater.

I started logging my pings to the device during the test (see timestamps):

Ping Logs

``` ping -D 192.168.2.74 | awk '{ if(gsub(/\[|\]/, "", $1)) $1=strftime("[%F %T]", $1); print}' PING 192.168.2.74 (192.168.2.74) 56(84) bytes of data. [2023-10-20 20:18:26] 64 bytes from 192.168.2.74: icmp_seq=1 ttl=255 time=58.5 ms [2023-10-20 20:18:27] 64 bytes from 192.168.2.74: icmp_seq=2 ttl=255 time=80.4 ms [2023-10-20 20:18:28] 64 bytes from 192.168.2.74: icmp_seq=3 ttl=255 time=104 ms [2023-10-20 20:18:29] 64 bytes from 192.168.2.74: icmp_seq=4 ttl=255 time=23.7 ms [2023-10-20 20:18:30] 64 bytes from 192.168.2.74: icmp_seq=5 ttl=255 time=0.844 ms [2023-10-20 20:18:31] 64 bytes from 192.168.2.74: icmp_seq=6 ttl=255 time=0.901 ms [2023-10-20 20:18:32] 64 bytes from 192.168.2.74: icmp_seq=7 ttl=255 time=1.39 ms [2023-10-20 20:18:33] 64 bytes from 192.168.2.74: icmp_seq=8 ttl=255 time=1.42 ms [2023-10-20 20:18:34] 64 bytes from 192.168.2.74: icmp_seq=9 ttl=255 time=1.38 ms [2023-10-20 20:18:35] 64 bytes from 192.168.2.74: icmp_seq=10 ttl=255 time=2.41 ms [2023-10-20 20:18:36] 64 bytes from 192.168.2.74: icmp_seq=11 ttl=255 time=0.903 ms [2023-10-20 20:18:37] 64 bytes from 192.168.2.74: icmp_seq=12 ttl=255 time=0.905 ms [2023-10-20 20:18:38] 64 bytes from 192.168.2.74: icmp_seq=13 ttl=255 time=1.13 ms [2023-10-20 20:18:39] 64 bytes from 192.168.2.74: icmp_seq=14 ttl=255 time=0.943 ms [2023-10-20 20:18:40] 64 bytes from 192.168.2.74: icmp_seq=15 ttl=255 time=6.96 ms [2023-10-20 20:18:41] 64 bytes from 192.168.2.74: icmp_seq=16 ttl=255 time=1.53 ms [2023-10-20 20:18:42] 64 bytes from 192.168.2.74: icmp_seq=17 ttl=255 time=1.27 ms [2023-10-20 20:18:43] 64 bytes from 192.168.2.74: icmp_seq=18 ttl=255 time=1.15 ms [2023-10-20 20:18:44] 64 bytes from 192.168.2.74: icmp_seq=19 ttl=255 time=1.21 ms [2023-10-20 20:18:45] 64 bytes from 192.168.2.74: icmp_seq=20 ttl=255 time=0.995 ms [2023-10-20 20:18:46] 64 bytes from 192.168.2.74: icmp_seq=21 ttl=255 time=1.06 ms [2023-10-20 20:18:47] 64 bytes from 192.168.2.74: icmp_seq=22 ttl=255 time=1.11 ms [2023-10-20 20:18:48] 64 bytes from 192.168.2.74: icmp_seq=23 ttl=255 time=1.10 ms [2023-10-20 20:18:49] 64 bytes from 192.168.2.74: icmp_seq=24 ttl=255 time=1.30 ms [2023-10-20 20:18:50] 64 bytes from 192.168.2.74: icmp_seq=25 ttl=255 time=1.04 ms [2023-10-20 20:18:51] 64 bytes from 192.168.2.74: icmp_seq=26 ttl=255 time=1.13 ms [2023-10-20 20:18:52] 64 bytes from 192.168.2.74: icmp_seq=27 ttl=255 time=1.04 ms [2023-10-20 20:18:53] 64 bytes from 192.168.2.74: icmp_seq=28 ttl=255 time=0.974 ms [2023-10-20 20:18:54] 64 bytes from 192.168.2.74: icmp_seq=29 ttl=255 time=1.50 ms [2023-10-20 20:18:55] 64 bytes from 192.168.2.74: icmp_seq=30 ttl=255 time=1.09 ms [2023-10-20 20:18:56] 64 bytes from 192.168.2.74: icmp_seq=31 ttl=255 time=0.968 ms [2023-10-20 20:18:57] 64 bytes from 192.168.2.74: icmp_seq=32 ttl=255 time=91.5 ms [2023-10-20 20:18:58] 64 bytes from 192.168.2.74: icmp_seq=33 ttl=255 time=0.877 ms [2023-10-20 20:18:59] 64 bytes from 192.168.2.74: icmp_seq=34 ttl=255 time=0.938 ms [2023-10-20 20:19:00] 64 bytes from 192.168.2.74: icmp_seq=35 ttl=255 time=1.37 ms [2023-10-20 20:19:01] 64 bytes from 192.168.2.74: icmp_seq=36 ttl=255 time=79.2 ms [2023-10-20 20:19:02] 64 bytes from 192.168.2.74: icmp_seq=37 ttl=255 time=0.975 ms [2023-10-20 20:19:03] 64 bytes from 192.168.2.74: icmp_seq=38 ttl=255 time=0.838 ms [2023-10-20 20:19:04] 64 bytes from 192.168.2.74: icmp_seq=39 ttl=255 time=27.9 ms [2023-10-20 20:19:05] 64 bytes from 192.168.2.74: icmp_seq=40 ttl=255 time=3.91 ms [2023-10-20 20:19:06] 64 bytes from 192.168.2.74: icmp_seq=41 ttl=255 time=1.19 ms [2023-10-20 20:19:07] 64 bytes from 192.168.2.74: icmp_seq=42 ttl=255 time=0.959 ms [2023-10-20 20:19:08] 64 bytes from 192.168.2.74: icmp_seq=43 ttl=255 time=0.876 ms [2023-10-20 20:19:09] 64 bytes from 192.168.2.74: icmp_seq=44 ttl=255 time=0.923 ms [2023-10-20 20:19:10] 64 bytes from 192.168.2.74: icmp_seq=45 ttl=255 time=0.827 ms [2023-10-20 20:19:11] 64 bytes from 192.168.2.74: icmp_seq=46 ttl=255 time=11.1 ms [2023-10-20 20:19:12] 64 bytes from 192.168.2.74: icmp_seq=47 ttl=255 time=10.0 ms [2023-10-20 20:19:13] 64 bytes from 192.168.2.74: icmp_seq=48 ttl=255 time=14.6 ms [2023-10-20 20:19:14] 64 bytes from 192.168.2.74: icmp_seq=49 ttl=255 time=18.7 ms [2023-10-20 20:19:15] 64 bytes from 192.168.2.74: icmp_seq=50 ttl=255 time=7.23 ms [2023-10-20 20:19:16] 64 bytes from 192.168.2.74: icmp_seq=51 ttl=255 time=5.40 ms [2023-10-20 20:19:17] 64 bytes from 192.168.2.74: icmp_seq=52 ttl=255 time=5.60 ms [2023-10-20 20:19:18] 64 bytes from 192.168.2.74: icmp_seq=53 ttl=255 time=13.0 ms [2023-10-20 20:19:19] 64 bytes from 192.168.2.74: icmp_seq=54 ttl=255 time=4.79 ms [2023-10-20 20:19:20] 64 bytes from 192.168.2.74: icmp_seq=55 ttl=255 time=1.14 ms [2023-10-20 20:19:21] 64 bytes from 192.168.2.74: icmp_seq=56 ttl=255 time=1.79 ms [2023-10-20 20:19:22] 64 bytes from 192.168.2.74: icmp_seq=57 ttl=255 time=7.43 ms [2023-10-20 20:19:23] 64 bytes from 192.168.2.74: icmp_seq=58 ttl=255 time=32.2 ms [2023-10-20 20:19:24] 64 bytes from 192.168.2.74: icmp_seq=59 ttl=255 time=0.987 ms [2023-10-20 20:19:25] 64 bytes from 192.168.2.74: icmp_seq=60 ttl=255 time=0.931 ms [2023-10-20 20:19:26] 64 bytes from 192.168.2.74: icmp_seq=61 ttl=255 time=1.87 ms [2023-10-20 20:19:27] 64 bytes from 192.168.2.74: icmp_seq=62 ttl=255 time=2.66 ms [2023-10-20 20:19:28] 64 bytes from 192.168.2.74: icmp_seq=63 ttl=255 time=0.846 ms [2023-10-20 20:19:29] 64 bytes from 192.168.2.74: icmp_seq=64 ttl=255 time=1.11 ms [2023-10-20 20:19:30] 64 bytes from 192.168.2.74: icmp_seq=65 ttl=255 time=62.5 ms [2023-10-20 20:19:31] 64 bytes from 192.168.2.74: icmp_seq=66 ttl=255 time=0.978 ms [2023-10-20 20:19:32] 64 bytes from 192.168.2.74: icmp_seq=67 ttl=255 time=1.18 ms [2023-10-20 20:19:33] 64 bytes from 192.168.2.74: icmp_seq=68 ttl=255 time=1.41 ms [2023-10-20 20:19:34] 64 bytes from 192.168.2.74: icmp_seq=69 ttl=255 time=1.50 ms [2023-10-20 20:19:35] 64 bytes from 192.168.2.74: icmp_seq=70 ttl=255 time=1.04 ms [2023-10-20 20:19:36] 64 bytes from 192.168.2.74: icmp_seq=71 ttl=255 time=0.950 ms [2023-10-20 20:19:37] 64 bytes from 192.168.2.74: icmp_seq=72 ttl=255 time=0.964 ms [2023-10-20 20:19:38] 64 bytes from 192.168.2.74: icmp_seq=73 ttl=255 time=13.5 ms [2023-10-20 20:19:39] 64 bytes from 192.168.2.74: icmp_seq=74 ttl=255 time=0.795 ms [2023-10-20 20:19:40] 64 bytes from 192.168.2.74: icmp_seq=75 ttl=255 time=1.51 ms [2023-10-20 20:19:41] 64 bytes from 192.168.2.74: icmp_seq=76 ttl=255 time=1.25 ms [2023-10-20 20:19:42] 64 bytes from 192.168.2.74: icmp_seq=77 ttl=255 time=1.06 ms [2023-10-20 20:19:43] 64 bytes from 192.168.2.74: icmp_seq=78 ttl=255 time=1.15 ms [2023-10-20 20:19:44] 64 bytes from 192.168.2.74: icmp_seq=79 ttl=255 time=0.972 ms [2023-10-20 20:19:45] 64 bytes from 192.168.2.74: icmp_seq=80 ttl=255 time=7.75 ms [2023-10-20 20:19:46] 64 bytes from 192.168.2.74: icmp_seq=81 ttl=255 time=1.15 ms [2023-10-20 20:19:47] 64 bytes from 192.168.2.74: icmp_seq=82 ttl=255 time=1.66 ms [2023-10-20 20:19:48] 64 bytes from 192.168.2.74: icmp_seq=83 ttl=255 time=1.37 ms ====== Ebusd stopped here ====== [2023-10-20 20:19:56] 64 bytes from 192.168.2.74: icmp_seq=90 ttl=255 time=66.4 ms [2023-10-20 20:19:57] 64 bytes from 192.168.2.74: icmp_seq=91 ttl=255 time=94.2 ms [2023-10-20 20:19:58] 64 bytes from 192.168.2.74: icmp_seq=92 ttl=255 time=114 ms [2023-10-20 20:19:59] 64 bytes from 192.168.2.74: icmp_seq=93 ttl=255 time=34.1 ms [2023-10-20 20:20:00] 64 bytes from 192.168.2.74: icmp_seq=94 ttl=255 time=56.1 ms [2023-10-20 20:20:01] 64 bytes from 192.168.2.74: icmp_seq=95 ttl=255 time=81.0 ms [2023-10-20 20:20:02] 64 bytes from 192.168.2.74: icmp_seq=96 ttl=255 time=102 ms [2023-10-20 20:20:02] 64 bytes from 192.168.2.74: icmp_seq=97 ttl=255 time=24.2 ms [2023-10-20 20:20:04] 64 bytes from 192.168.2.74: icmp_seq=98 ttl=255 time=44.2 ms [2023-10-20 20:20:05] 64 bytes from 192.168.2.74: icmp_seq=99 ttl=255 time=69.4 ms [2023-10-20 20:20:06] 64 bytes from 192.168.2.74: icmp_seq=100 ttl=255 time=90.1 ms [2023-10-20 20:20:07] 64 bytes from 192.168.2.74: icmp_seq=101 ttl=255 time=121 ms [2023-10-20 20:20:08] 64 bytes from 192.168.2.74: icmp_seq=102 ttl=255 time=34.2 ms [2023-10-20 20:20:09] 64 bytes from 192.168.2.74: icmp_seq=103 ttl=255 time=59.2 ms [2023-10-20 20:20:10] 64 bytes from 192.168.2.74: icmp_seq=104 ttl=255 time=80.1 ms [2023-10-20 20:20:11] 64 bytes from 192.168.2.74: icmp_seq=105 ttl=255 time=205 ms [2023-10-20 20:20:12] 64 bytes from 192.168.2.74: icmp_seq=106 ttl=255 time=29.9 ms [2023-10-20 20:20:13] 64 bytes from 192.168.2.74: icmp_seq=107 ttl=255 time=51.8 ms [2023-10-20 20:20:14] 64 bytes from 192.168.2.74: icmp_seq=108 ttl=255 time=68.9 ms [2023-10-20 20:20:15] 64 bytes from 192.168.2.74: icmp_seq=109 ttl=255 time=98.7 ms [2023-10-20 20:20:16] 64 bytes from 192.168.2.74: icmp_seq=110 ttl=255 time=117 ms [2023-10-20 20:20:17] 64 bytes from 192.168.2.74: icmp_seq=111 ttl=255 time=38.5 ms [2023-10-20 20:20:18] 64 bytes from 192.168.2.74: icmp_seq=112 ttl=255 time=58.4 ms [2023-10-20 20:20:19] 64 bytes from 192.168.2.74: icmp_seq=113 ttl=255 time=87.7 ms [2023-10-20 20:20:20] 64 bytes from 192.168.2.74: icmp_seq=114 ttl=255 time=104 ms [2023-10-20 20:20:21] 64 bytes from 192.168.2.74: icmp_seq=115 ttl=255 time=25.4 ms [2023-10-20 20:20:22] 64 bytes from 192.168.2.74: icmp_seq=116 ttl=255 time=46.0 ms [2023-10-20 20:20:23] 64 bytes from 192.168.2.74: icmp_seq=117 ttl=255 time=75.6 ms [2023-10-20 20:20:25] 64 bytes from 192.168.2.74: icmp_seq=118 ttl=255 time=1015 ms [2023-10-20 20:20:25] 64 bytes from 192.168.2.74: icmp_seq=119 ttl=255 time=0.754 ms ```

Ebusd Logs

Ebusd log: (timestamps are in utc) - 2h behind my local time (due to docker) ``` 2023-10-20 18:18:29.916 [main notice] ebusd 23.2.23.2 started with auto scan on device: 192.168.2.74:9999, enhanced 2023-10-20 18:18:30.553 [bus notice] device status: resetting 2023-10-20 18:18:30.553 [bus notice] bus started with own address 31/36 2023-10-20 18:18:30.554 [mqtt notice] connection established 2023-10-20 18:18:30.559 [bus notice] signal acquired 2023-10-20 18:18:30.921 [bus notice] new master 10, master count 2 2023-10-20 18:18:30.957 [bus notice] new master 03, master count 3 2023-10-20 18:18:30.957 [update notice] received unknown MS cmd: 1008b5100900006078ffff04ff00 / 0101 2023-10-20 18:18:30.957 [bus notice] <1008b5100900006078ffff04ff00320001019a00 2023-10-20 18:18:31.391 [bus notice] device status: reset, supports info 2023-10-20 18:18:31.499 [bus notice] device status: extra info: firmware 1.1[3a0f].1[3a0f], jumpers 0x0f 2023-10-20 18:18:36.957 [update notice] received unknown MS cmd: 1008b5110101 / 095a5a00804e560000ff 2023-10-20 18:18:36.961 [bus notice] <1008b51101018900095a5a00804e560000ff0200 2023-10-20 18:18:40.655 [bus notice] >310807 2023-10-20 18:18:40.655 [main error] scan config 08: ERR: SYN received 2023-10-20 18:18:40.991 [update notice] received unknown MS cmd: 1008b5100900006078ffff04ff00 / 0101 2023-10-20 18:18:40.991 [bus notice] <1008b5100900006078ffff04ff00320001019a00 2023-10-20 18:18:41.391 [bus error] device status: eBUS comm error: overrun 2023-10-20 18:18:42.791 [bus notice] >311507 2023-10-20 18:18:42.791 [main error] scan config 15: ERR: SYN received 2023-10-20 18:18:43.358 [bus error] device status: eBUS comm error: overrun 2023-10-20 18:18:46.941 [update notice] received unknown MS cmd: 1008b5110101 / 095a5a00804e560000ff 2023-10-20 18:18:46.957 [bus notice] <1008b51101018900095a5a00804e560000ff0200 2023-10-20 18:18:48.963 [update notice] received unknown BC cmd: 10feb516080048182020100523 2023-10-20 18:18:48.963 [bus notice] <10feb51608004818202010052385 2023-10-20 18:18:49.212 [update notice] received unknown MS cmd: 1008b512020064 / 00 2023-10-20 18:18:49.221 [bus notice] <1008b512020064ae00000000 2023-10-20 18:18:50.991 [update notice] received unknown MS cmd: 1008b5100900006078ffff04ff00 / 0101 2023-10-20 18:18:50.998 [bus notice] <1008b5100900006078ffff04ff00320001019a00 2023-10-20 18:18:54.972 [update notice] received unknown MS cmd: 1008b5110101 / 095a5a00804e560000ff 2023-10-20 18:18:54.981 [bus notice] <1008b51101018900095a5a00804e560000ff0200 2023-10-20 18:18:55.171 [bus notice] scan 08: ;Vaillant;BAI00;0518;7401 2023-10-20 18:18:55.171 [update notice] store 08 ident: done 2023-10-20 18:18:55.171 [update notice] sent scan-read scan.08 QQ=31: Vaillant;BAI00;0518;7401 2023-10-20 18:18:55.171 [bus notice] scan 08: ;Vaillant;BAI00;0518;7401 2023-10-20 18:18:55.171 [bus notice] >3108070400d1<000ab54241493030051874012f>00 2023-10-20 18:18:55.677 [main notice] read common config file vaillant/broadcast.csv 2023-10-20 18:18:55.805 [main notice] read common config file vaillant/scan.csv 2023-10-20 18:18:55.934 [main notice] read common config file vaillant/general.csv 2023-10-20 18:18:56.063 [main notice] read scan config file vaillant/08.bai.csv for ID "bai00", SW0518, HW7401 2023-10-20 18:18:56.181 [bus notice] >3108b5 2023-10-20 18:18:56.181 [bus error] send to 08: ERR: SYN received, retry 2023-10-20 18:18:56.221 [bus notice] 3108b5 2023-10-20 18:18:56.358 [bus error] send to 08: ERR: SYN received, retry 2023-10-20 18:18:56.401 [bus notice] 3108b509012448<00090000000000000000009c>00 2023-10-20 18:18:56.801 [bus notice] >3108b5 2023-10-20 18:18:56.801 [bus error] send to 08: ERR: SYN received, retry 2023-10-20 18:18:56.972 [update notice] received unknown MS cmd: 1008b5110102 / 05033c964678 2023-10-20 18:18:56.972 [bus notice] <1008b51101028a0005033c964678da00 2023-10-20 18:18:57.181 [update notice] sent scan-read scan.08 id QQ=31: 2023-10-20 18:18:57.181 [bus notice] >3108b509012549<00090000000000000000009c>00 2023-10-20 18:18:57.292 [bus notice] >3108b509 2023-10-20 18:18:57.292 [bus error] send to 08: ERR: SYN received, retry 2023-10-20 18:18:57.391 [bus error] device status: eBUS comm error: overrun 2023-10-20 18:18:57.487 [bus error] arbitration start error 2023-10-20 18:18:57.900 [bus notice] <09 2023-10-20 18:18:57.957 [bus error] send to 08: ERR: wrong symbol received, retry 2023-10-20 18:18:58.536 [bus notice] >3108b5<35f5 2023-10-20 18:18:58.571 [bus error] send to 08: ERR: wrong symbol received 2023-10-20 18:18:58.571 [bus error] send message part 2: ERR: wrong symbol received 2023-10-20 18:18:58.571 [main error] error reading message scan.08 id: ERR: wrong symbol received 2023-10-20 18:18:59.162 [bus notice] >3108b5<05fd 2023-10-20 18:18:59.357 [update notice] sent scan-read scan.08 id QQ=31: 2023-10-20 18:18:59.357 [bus notice] >3108b509012448<00090000000000000000009c>00 2023-10-20 18:18:59.455 [bus notice] >3108b5 2023-10-20 18:18:59.455 [bus error] send to 08: ERR: SYN received, retry 2023-10-20 18:18:59.591 [bus error] send to 08: ERR: wrong symbol received, retry 2023-10-20 18:19:00.182 [bus notice] >3108b5<05ff 2023-10-20 18:19:00.381 [update notice] sent scan-read scan.08 id QQ=31: 2023-10-20 18:19:00.381 [bus notice] >3108b509012549<00090000000000000000009c>00 2023-10-20 18:19:00.391 [bus error] device status: eBUS comm error: overrun 2023-10-20 18:19:00.491 [bus notice] >3108b5 2023-10-20 18:19:00.491 [bus error] send to 08: ERR: SYN received, retry 2023-10-20 18:19:00.624 [bus notice] >3108b5 2023-10-20 18:19:00.624 [bus error] send to 08: ERR: SYN received, retry 2023-10-20 18:19:00.760 [bus notice] >3108b5 2023-10-20 18:19:00.760 [bus error] send to 08: ERR: SYN received 2023-10-20 18:19:00.760 [bus error] send message part 2: ERR: SYN received 2023-10-20 18:19:00.760 [main error] error reading message scan.08 id: ERR: SYN received 2023-10-20 18:19:00.811 [bus notice] 3108b509012448<00090000000000000000009c>00 2023-10-20 18:19:01.321 [bus error] send to 08: ERR: wrong symbol received, retry 2023-10-20 18:19:01.391 [bus error] device status: eBUS comm error: overrun 2023-10-20 18:19:01.912 [bus notice] >3108b5<05fd 2023-10-20 18:19:01.958 [bus notice] >3108b5 2023-10-20 18:19:01.958 [bus error] send to 08: ERR: SYN received, retry 2023-10-20 18:19:02.002 [bus notice] 3108b509012549<00090000000000000000009c>00 2023-10-20 18:19:02.391 [bus notice] >3108b5 2023-10-20 18:19:02.391 [bus error] send to 08: ERR: SYN received, retry 2023-10-20 18:19:02.431 [bus error] device status: eBUS comm error: overrun 2023-10-20 18:19:02.671 [update notice] sent scan-read scan.08 id QQ=31: 2023-10-20 18:19:02.671 [bus notice] >3108b50901264a<00090000000000000000009c>00 2023-10-20 18:19:02.785 [bus notice] >3108b5 2023-10-20 18:19:02.785 [bus error] send to 08: ERR: SYN received, retry 2023-10-20 18:19:02.821 [bus notice] 3108b50901274b<00090000000000000000009c>00 2023-10-20 18:19:03.506 [main notice] found messages: 232 (0 conditional on 26 conditions, 0 poll, 10 update) 2023-10-20 18:19:03.621 [bus notice] >3108b5 2023-10-20 18:19:04.355 [bus error] device status: eBUS comm error: overrun 2023-10-20 18:19:04.981 [update notice] received read bai Status01 QQ=10: 45.0;45.0;-;39.0;43.0;off 2023-10-20 18:19:04.991 [bus notice] <1008b51101018900095a5a00804e560000ff0200 2023-10-20 18:19:05.764 [bus notice] >311507 2023-10-20 18:19:05.764 [main error] scan config 15: ERR: SYN received 2023-10-20 18:19:05.802 [bus notice] <07 2023-10-20 18:19:06.921 [update notice] received update-read broadcast outsidetemp QQ=10: 7.250 2023-10-20 18:19:06.931 [bus notice] <10feb5160301400713 2023-10-20 18:19:10.967 [update notice] received update-write bai SetMode QQ=10: auto;48.0;60.0;-;0;0;1;0;0;0 2023-10-20 18:19:10.976 [bus notice] <1008b5100900006078ffff04ff00320001019a00 2023-10-20 18:19:15.005 [update notice] received read bai Status01 QQ=10: 45.0;45.0;-;39.0;43.0;off 2023-10-20 18:19:15.005 [bus notice] <1008b51101018900095a5a00804e560000ff0200 2023-10-20 18:19:16.981 [update notice] received read bai Status02 QQ=10: auto;60;75.0;70;60.0 2023-10-20 18:19:16.982 [bus notice] <1008b51101028a0005033c964678da00 2023-10-20 18:19:18.011 [bus notice] scan 15: ;Vaillant;F4300;0120;2102 2023-10-20 18:19:18.011 [update notice] store 15 ident: done 2023-10-20 18:19:18.011 [update notice] sent scan-read scan.15 QQ=31: Vaillant;F4300;0120;2102 2023-10-20 18:19:18.011 [bus notice] scan 15: ;Vaillant;F4300;0120;2102 2023-10-20 18:19:18.011 [bus notice] >31150704008b<000ab546343330300120210205>00 2023-10-20 18:19:18.121 [bus notice] >3115b5 2023-10-20 18:19:18.121 [main error] scan config 15: ERR: SYN received 2023-10-20 18:19:18.363 [bus error] device status: eBUS comm error: overrun 2023-10-20 18:19:20.971 [update notice] received update-write bai SetMode QQ=10: auto;48.0;60.0;-;0;0;1;0;0;0 2023-10-20 18:19:20.981 [bus notice] <1008b5100900006078ffff04ff00320001019a00 2023-10-20 18:19:25.007 [update notice] received read bai Status01 QQ=10: 45.0;45.0;-;39.0;43.0;off 2023-10-20 18:19:25.008 [bus notice] <1008b51101018900095a5a00804e560000ff0200 2023-10-20 18:19:26.982 [update notice] received unknown BC cmd: 10feb505020400 2023-10-20 18:19:26.982 [bus notice] <10feb5050204000b 2023-10-20 18:19:30.372 [update notice] sent unknown MS cmd: 3115b5090124 / 09003231313131393030 2023-10-20 18:19:30.372 [bus notice] >3115b509012406<000900323131313139303089>00 2023-10-20 18:19:30.481 [main error] scan config 15: ERR: wrong symbol received 2023-10-20 18:19:31.062 [bus notice] >3115b5<35f5 2023-10-20 18:19:31.211 [update notice] received update-write bai SetMode QQ=10: auto;48.0;60.0;-;0;0;1;0;0;0 2023-10-20 18:19:31.211 [bus notice] <1008b5100900006078ffff04ff00320001019a00 2023-10-20 18:19:35.022 [update notice] received read bai Status01 QQ=10: 45.0;45.0;-;39.0;43.0;off 2023-10-20 18:19:35.022 [bus notice] <1008b51101018900095a5a00804e560000ff0200 2023-10-20 18:19:41.001 [update notice] received update-write bai SetMode QQ=10: auto;48.0;60.0;-;0;0;1;0;0;0 2023-10-20 18:19:41.011 [bus notice] <1008b5100900006078ffff04ff00320001019a00 2023-10-20 18:19:42.591 [bus notice] >3115b5 2023-10-20 18:19:42.592 [main error] scan config 15: ERR: SYN received 2023-10-20 18:19:43.401 [bus error] device status: eBUS comm error: overrun 2023-10-20 18:19:44.992 [update notice] received read bai Status01 QQ=10: 45.0;44.0;-;39.0;43.0;off 2023-10-20 18:19:44.992 [bus notice] <1008b51101018900095a5800804e560000ff3500 2023-10-20 18:19:47.002 [update notice] received update-read broadcast vdatetime QQ=10: 20:19:46;20.10.2023 2023-10-20 18:19:47.002 [bus notice] <10feb516080046192020100523dc 2023-10-20 18:19:47.251 [update notice] received update-write bai StatusCirPump QQ=10: on 2023-10-20 18:19:47.251 [bus notice] <1008b512020064ae00000000 2023-10-20 18:19:49.032 [update notice] received update-write bai SetMode QQ=10: auto;48.0;60.0;-;0;0;1;0;0;0 2023-10-20 18:19:49.032 [bus notice] <1008b5100900006078ffff04ff00320001019a00 ```

Dashboard showing Wifi at 90% (-55dBm) Settings are default on the adapter. Docker compose part of ebusd

  ebusd:
    image: john30/ebusd
    restart: unless-stopped
    environment:
      EBUSD_SCANCONFIG: ''
      EBUSD_DEVICE: "ens:192.168.2.74:9999"
      EBUSD_MQTTHOST: "mosquitto"
      EBUSD_MQTTPORT: 1883
      EBUSD_MQTTJSON: ''
      EBUSD_POLLINTERVAL: '10'
      EBUSD_MQTTVAR: "filter-direction=r|u|^w,filter-name=^Flame$|^HcPumpMode$|^ReturnTemp$|^StorageTemp$|^FlowTemp$|^FlowTempDesired$|^Statenumber$|^Hc1ActualFlowTempDesired$|^Hc1HeatCurve$|^Hc1ManualOPRoomTempDesired$|^ActualRoomTempDesiredHc1$|^Hc1MinimalFlowTempDesired$|^Hc1NightTemp$|^Hc1OPMode$|^Hc1QuickVetoTemp$|^HolidayRoomTemp$|^HwcActualTempDesired$|^HwcManualOPTempDesired$|^HwcOPMode$|^OutsideTemp$|^RoomTemp$|^DisplayedHwcStorageTemp$|^Hc1Pump$|^IsInHoliday$|^HolidayStartPeriod$|^HolidayEndPeriod$|^WaterPressure$"
      EBUSD_MQTTCLIENTID: "ebusd-lx0001"
      EBUSD_LOGRAWDATA: ""
    networks:
      - mqtt
      - bridge

Note how the ping goes up after I stopped ebusd. Thats why I suspect some energy saving to apply on the adapter. If there is some, could thos cause spikes during an active connection ?

ech0-py commented 1 year ago

Guess I have the relevant question, will try to ask here instead of creating a new issue. Sometimes during the write operation I receive ERR: SYN received. Is it possible to make retries for such fails on ebusd side? I though that --sendretries=2 (default value) will make the trick, but don't see any retries in logs at all (--log=all:info --log=bus:info)

palonsorodriguez commented 1 year ago

this is the difference to the previous log entry 2023-09-27 22:55:48.436 [bus debug] arbitration won.

the critical delay is the AUTO-SYN that is allowed to appear anywhere between 30ms and 45ms after the last byte seen on the bus. consequently, sending a byte the interface and receiving it back in total may not take longer than 30ms.

with 15ms average ping delay, you're right at the edge of it and the maximum is awfully high, too. whenever you hit such a high delay in the middle of writing something to the interface, you'll see exactly those messages in the log

Hi John, thanks very much for your help.

I did a lot of testing and wasn't able to success with WiFi, despite some times the latency was quite low, well below 15ms.

Trying to reduce the distance/latency in the edge, I did another test with a borrowed raspi using usb instead of WiFi, so ebusd runs at the edge, next to the heat pump (yet as a docker) instead of in my home automation server and that works like a charm. No single message seen lost.

I noticed that with hmu is fast lightning while when talking to bass2 it is quite slower and sometimes I don't receive the updates, tried with r1 in the definition file, but no difference so I'm croning reads every min of the most important variables for me.

For the WiFi connection is there anything I could mod (eg bus latencies). I tried different values but no luck. I feel that I'll need to give up if not
In general, if you see a device that is lazy responding (in my case bass2 for the hwc stored temperature), is there any way to try to read more often? (Other than in the message definition, changing for r1, r3...)

Thanks a lot! Pablo

Fortune95 commented 1 year ago

Hi John,

like Pablo I have the same error pattern when reading, first it doesn't find the data point and then it sends the value back after all. After I changed the interface to USB it works. Additionally a log with USB and one with Ethernet setup.

With USB: 2023-10-24 21:00:48.252 [update notice] sent read bai StorageTemp QQ=31: 45.19;ok 2023-10-24 21:00:48.404 [update notice] sent read 700 z1RoomTemp QQ=31: 22.125 2023-10-24 21:00:48.528 [update notice] sent read bai WP QQ=31: off 2023-10-24 21:00:48.667 [update notice] sent read 700 Hc1Status QQ=31: 0 2023-10-24 21:00:48.819 [update notice] sent read 700 Hc1HeatCurve QQ=31: 1 2023-10-24 21:00:48.970 [update notice] sent read 700 Hc1FlowTemp QQ=31: 31 2023-10-24 21:00:49.113 [update notice] sent read 700 Hc1PumpStatus QQ=31: 0 2023-10-24 21:00:49.244 [update notice] sent read bai FlowTemp QQ=31: 31.19;ok 2023-10-24 21:00:49.384 [update notice] sent read bai ReturnTemp QQ=31: 32.06;65022;ok 2023-10-24 21:00:49.540 [update notice] sent read 700 Hc1ActualFlowTempDesired QQ=31: 0.0 2023-10-24 21:00:55.801 [update notice] received read bai Status01 QQ=10: 31.0;32.0;13.312;34.0;45.0;off

With Ethernet: 2023-10-24 22:26:52.745 [update notice] sent read bai StorageTemp QQ=31: 42.19;ok 2023-10-24 22:26:52.901 [update notice] received unknown MS cmd: 1008b5110100 / 08c80110001f100000 2023-10-24 22:26:53.165 [update notice] sent read 700 z1RoomTemp QQ=31: 22.1875 2023-10-24 22:26:53.415 [update notice] sent read bai WP QQ=31: off 2023-10-24 22:26:53.525 [update notice] received update-read broadcast outsidetemp QQ=10: 11.562 2023-10-24 22:26:53.765 [update notice] sent read 700 Hc1Status QQ=31: 0 2023-10-24 22:26:54.084 [update notice] sent read 700 Hc1HeatCurve QQ=31: 1 2023-10-24 22:26:54.225 [update notice] received unknown MS cmd: 1008b5100305ff01 / 00 2023-10-24 22:26:54.475 [update notice] sent read 700 Hc1FlowTemp QQ=31: 28 2023-10-24 22:26:54.585 [bus error] send to 15: ERR: wrong symbol received, retry 2023-10-24 22:26:55.215 [bus error] send to 15: ERR: wrong symbol received, retry 2023-10-24 22:26:56.065 [update notice] sent read 700 Hc1PumpStatus QQ=31: 0 2023-10-24 22:26:56.205 [update notice] received update-write bai StatusCirPump QQ=10: off 2023-10-24 22:26:56.402 [update notice] sent read bai FlowTemp QQ=31: 28.81;ok 2023-10-24 22:26:56.502 [bus error] send to 08: ERR: SYN received, retry 2023-10-24 22:26:56.615 [update notice] received unknown MS cmd: 1008b5120204ff / 0101 2023-10-24 22:26:56.715 [bus error] device status: eBUS comm error: overrun 2023-10-24 22:26:56.815 [update notice] sent read bai ReturnTemp QQ=31: 29.56;65062;ok 2023-10-24 22:26:57.130 [update notice] sent read 700 Hc1ActualFlowTempDesired QQ=31: 0.0 2023-10-24 22:26:57.255 [update notice] received unknown MS cmd: 1008b513020508 / 00 2023-10-24 22:26:57.475 [update notice] received unknown BC cmd: 10feb510020601 2023-10-24 22:27:01.516 [update notice] received read bai Status01 QQ=10: 28.0;29.0;13.062;32.0;42.0;off 2023-10-24 22:27:01.802 [update notice] received update-write bai SetMode QQ=10: auto;0.0;50.0;-;1;0;1;0;0;0

Doing a ping from the LXC to ebus adapter:

18 packets transmitted, 18 received, 0% packet loss, time 17366ms rtt min/avg/max/mdev = 0.704/0.860/2.307/0.353 ms

Any idea?

Regards, Lars

john30 commented 1 year ago

@palonsorodriguez for the WIFI you could check with the REPL (available e.g. via the firmware page for flashing) if you have disturbing nets around by using the scan command.

anyway, I'm working on gettings ebusd itself into the adapter which would allow to get rid of the difficultly timed wireless transfer in the first place. but that sill takes time

john30 commented 1 year ago

@Xyaren there is no power save active in the firmware.

the issue is that spikes of 50ms like those seen in your ping list will just make it impossible to get the communication done reliably

john30 commented 11 months ago

there was some default power saving applied by ESP-IDF which is now removed in the new firmware 20231217, maybe that helps. also there were many commits to ESP-IDF that may also improve the situation, so please try

palonsorodriguez commented 10 months ago

Hi John, Thanks for your help. I updated to the latest firmware, but still not possible to run with wifi Looks like there's losing communication constantly. I tried different latencies for ebusd, the following test is with 100ms

ebusd | 2024-01-08 22:02:48.126 [main notice] starting initial broadcast scan ebusd | 2024-01-08 22:02:48.126 [bus info] send message: fffe070400 ebusd | 2024-01-08 22:02:48.207 [bus notice] <1076b512030f02025200072702003d02ff031d00 ebusd | 2024-01-08 22:02:48.231 [bus notice] <02c1802400 ebusd | 2024-01-08 22:02:49.158 [bus notice] <7108b5110100b300097f020c61180900003fc800 ebusd | 2024-01-08 22:02:49.159 [bus notice] >fffe ebusd | 2024-01-08 22:02:49.159 [bus error] send to fe: ERR: SYN received, retry ebusd | 2024-01-08 22:02:49.159 [bus notice] >fffe ebusd | 2024-01-08 22:02:49.159 [bus error] send to fe: ERR: SYN received, retry ebusd | 2024-01-08 22:02:49.166 [bus notice] <7108b5110101b20009 ebusd | 2024-01-08 22:02:49.212 [bus info] send/receive symbol latency 3 - 46 ms ebusd | 2024-01-08 22:02:49.224 [bus error] send to fe: ERR: wrong symbol received ebusd | 2024-01-08 22:02:49.224 [main error] initial scan failed: ERR: wrong symbol received ebusd | 2024-01-08 22:02:49.724 [bus notice] >fffe07<fe ebusd | 2024-01-08 22:02:49.727 [bus notice] arbitration won in invalid state ready ebusd | 2024-01-08 22:02:49.782 [bus notice] >ff ebusd | 2024-01-08 22:02:49.893 [bus notice] <fe ebusd | 2024-01-08 22:02:49.953 [bus notice] <07

Thanks

Wolla57 commented 9 months ago

Hi, I have had some problems using the adapter v5 with wifi too (see https://github.com/john30/ebusd/issues/1078 ). I found the following workaround which effects a better wifi connection :

install adapter firmware build 20231217
search an unused/low used WLAN channel (i.e. AVM Fritz!box: WLAN - Funkkanal - Andere WLAN-Funknetze in Ihrer Umgebung)
deactivate WLAN Autokanal/Autochannel and select unused WLAN channel (i.e. AVM Fritz!box: WLAN - Funkkanal - Funkkanal-Einstellungen anpassen)

Good luck !

Wolla57 commented 9 months ago

PS: In my network sometimes there are problems to connect ebusd to the adapter. Also the adapter can't be reached by ping. In this case I send ping permanently and after a (longer) while ping becomes successful and the ebusd connection started also. I don't know if this is a special problem of my network or of the adapter. @John: Do you have any idea ?

john30 commented 9 months ago

is this on the latest firmware 2024-01-06?

Wolla57 commented 8 months ago

Hi John, I updated the adapter to firmware 2024-01-06 and reactivated WLAN Autokanal/Autochannel. Within 1 day adapter/ebusd lost their connection after the WLAN channel changed automatically and the connection didn´t restart. In difference to firmware 2023-12-17 ping worked furtheron.

Note: I use a MESH-WLAN with FRITZ-router and -repeater. Although the repeater has the stronger signal (~70%) the adapter often connects to the router (~40%).

So I reactivated the fix channel solution and after several reboots the adapter connected to the repeater and the connection with ebusd started again. Since 4 days the connection works stabile.

I hope this information helps you.

Thanks to the ebusd team and your support

john30 commented 8 months ago

closing this one as it does not seem to be an ebusd issue in the first place. go on here ebusd-esp32 if needed

john30 / ebusd