Closed alpxp closed 1 year ago
I can only imagine that the timing is special for this recov device. you could check that now with the current firmware as stated here: https://github.com/john30/ebusd-esp32/issues/14
Here is the output of the ebus -v
error: unable to load from NVS
init_ebus: already switched to enhanced eBUS mode on TCP port. updating verbosity.
init_ebus: clock frq 80000000 div 33 1/3, src clk 4
init_ebus: detected: 2412 Hz on 18 edges with 1989 +/1989 - edge width, 969 H/1019 L pulse width, i.e. 404 us H/425 us L period
I don't know how to judge. Does this look ok?
Update: After starting ebusd I get:
init_ebus: clock frq 80000000 div 33 1/3, src clk 4
init_ebus: detected: 2434 Hz on 1023 edges with 1988 +/1988 - edge width, 969 H/1002 L pulse width, i.e. 404 us H/418 us L period
init_ebus: master 8 0x31 delay=196 us [195-201]
init_ebus: master 14 0x73 delay=4556 us [4556-4556]
with 2434 Hz, which is that 1.4% off of 2400? If I understood your explanation correctly this could be the problem? Is there a way to fix it?
This is strange, I have also been having problems and just tried adding --loglevel=debug
and it has also sprung to life!
I am also using an adapter 5 via USB with a Vaillant boiler initial scan result: 08;Vaillant;BAI00;0202;8001
.
I adjusted the baud rate using the new feature (+24) and it didn't seem to make a difference.
init_ebus: clock frq 80000000 div 33 1/3, src clk 4
init_ebus: detected: 2424 Hz on 19 edges with 1979 +/1979 - edge width, 1001 H/977 L pulse width, i.e. 417 us H/407 us L period
init_ebus: master 8 0x31 delay=198 us [197-203]
init_ebus: master 11 0x03 delay=147 us [147-197]
I've found an issue hidden in the ESP32-C3 UART that reports a falsy non-TX-readiness. this seems to be an issue especially if ebusd handles the traffic too quickly as it seems to be the case on your host without the debug logging.
could you check with the new firmware 20230917 just released?
I confirm that with the new firmware the issue is resolved. Quick test showed identically good behaviour with and without debug log. Thank you
Description
I have a weird situation where ebusd works stable only when I add
--loglevel=debug
to the arguments. Without the debug flag it takes very long to discover the device and most of the communications end up withERR: read timeout
. Must be some hidden configuration differences between debug and production modes?Actual behavior
with
EBUSD_OPTS="--scanconfig -d ens:/dev/ttyACM0 --scanconfig=08 -c /etc/ebusd/"
the device discovery may take very long and most (but not all) of reads/writes fail, i.e.$ ebusctl read -f -c recov TempOutsideAir
end up withERR: read timeout
see Log-no-debug below.When I add
--loglevel=debug
to the EBUSD_OPTS, the communication is stable. i.e. with-d ens:/dev/ttyACM0 --loglevel=debug --scanconfig=08 -c /etc/ebusd/
most of reads are successfully. see Log-debug below.I tried playing with
latency
andreceivetimeout
parameters for production runs but saw no improvements. i.e. to be concrete--latency=10 --receivetimeout=50
does not help.Expected behavior
The communication quality is not expected to depend on log level. Also a stable communication with with the adapter is expected.
ebusd version
23.2
ebusd arguments
EBUSD_OPTS="--scanconfig -d ens:/dev/ttyACM0 --scanconfig=08 -c /etc/ebusd/"
Operating system
Debian 11 (Bullseye) / Ubuntu 20-21 / Raspbian 11 / Raspberry Pi OS 11 (including lite)
CPU architecture
x64
Dockerized
None
Hardware interface
adapter 5 via USB
Related integration
No response
Logs
Log-no-debug:
Log-debug: