Read timeouts on most of the variables/parameters [SOLVED]

[cjoe-51]

I have the ebus adapter v.6.1. Its connected through router to the Pi running ebusd SW (v.24.1., before 23.2).

In fact there still don't exist good configuration files for my regulator VCR 720/3. However the initial procedures after starting ebusd seem to run well, without any errors and (using symlink to 15.ctlv2.csv) it looks like there is available plenty of parameters for read and write.
My problem is that I'm able to read only few of those (+ there are available few which are broadcasted by itself). This way I'm able to get the external temperature, actual internal temperature, waterpressure and few others. For most of the items I however don't get any value but "read timeout", "invalid position" or some other negative answer :( This does not differ much for different versions of the config files.
For my present needs Id be happy to have access to the requested day temperature, to be able to read and write.
Unfortunately such parameters like z1DayTemp or z1HeatingRoomTempDesiredManualControlled or other (depending on configuration version used) belong to the (larger) part of parameters which do give Read timeout :(

When discussing this in the John30/ebusd-configuration forum i received among other a recommendation 1/ not to use WiFi connection nor Ethernet but only USB or UART. 2/ not to use ebus HW adapters other than the official from John30.
What can you say to this? Is it true that with the HW from Daniel Kucera its not possible to successfully read/write all the parameters available for a specific heater and regulator? Why some of the parameters are read systematically without any problem and others systematically not? Whats different on the data that Wifi connection could prevent reading those? I expect that reading is done fully and only by the ebus adapter and that WiFi connection is then used only for sharing the already received values with the ebusd SW . Or is it like the second recommendation that the Daniel Kucera,s adapter is not capable of communication properly (or fast enough) ?

[danielkucera]

Hi @cjoe-51 , can you provide the log as described in README troubleshooting?
Did you try to fine tune PWM value?
If you wish, and you are from EU, I can borrow you adapter from john to verify it's not in the adapter.

[cjoe-51]

Hi @cjoe-51 , can you provide the log as described in README troubleshooting? Did you try to fine tune PWM value? If you wish, and you are from EU, I can borrow you adapter from john to verify it's not in the adapter.

I will add the log in a moment. The heating is remote from my location so some steps are necessary.
In the meantime - I personaly dont thing that the arguments in the reccommendations are valid (nor the wifi nor the unoficial adapter in your case).
With regards to the PWM I havent changed it as the LED looked good and the connection and log seemed to be ok for me. (My original premise was that when I'm able to read some data, then the communication is set well). I will give it a try when I will go there.
My personal suspicion is now however more targeted to the power source. Im feeding the adapter from the ebus bus. Which is great. But when thinking about where could be difference between some parameters read perfectly and some not then I can imagine that some the data packages can be short for some parameters but long for others. When the power would be so so, then may be reading longer packages may exhausts the power too much ... Do you have experience that the power feeding from ebus can cause systematic Read timeouts?

[danielkucera]

Yes, that makes total sense. I hope we see something in logs. Errors, reconnects, etc.

[cjoe-51]

Yes, that makes total sense. I hope we see something in logs. Errors, reconnects, etc.

Im enclosing the log (only the part after changing ebusd config and restarting ebusd).
ebusd__150125_debug.log

And in addition here is the ebusd info:

pi@pi4Iob:~ $ sudo ebusctl i
version: ebusd 24.1.24.1
update check: OK, broadcast.csv: different version available, vaillant/broadcast.csv: different version available, vaillant/hcmode.inc: different version available
device: esp-ebus.local:3335, TCP, enhanced
signal: acquired
symbol rate: 45
max symbol rate: 101
min arbitration micros: 1
max arbitration micros: 17
min symbol latency: 7
max symbol latency: 17
scan: finished
reconnects: 0
masters: 3
messages: 957
conditional: 3
poll: 0
update: 15
address 03: master #11
address 08: slave #11, scanned "MF=Vaillant;ID=BAI00;SW=1103;HW=7603", loaded "vaillant/bai.308523.inc", "vaillant/08.bai.csv"
address 10: master #2
address 15: slave #2, scanned "MF=Vaillant;ID=CTLV3;SW=0709;HW=3704", loaded "vaillant/15.ctlv3.csv"
address 31: master #8, ebusd
address 36: slave #8, ebusd

[danielkucera]

I see quite a lot of errors there. Athough there are 0 reconnects, I would try to power the device via USB-C. If you want to try something remotely first, you can try adjusting the PWM value config.

[cjoe-51]

OK, I will try the PWM.
Thank you

[cjoe-51]

How sensitive is the PWM setting? If there should be some safe boundary like let say 6 or 10 points then its not working. Below 90 and above 220 there is no signal. Between those it works for basic info but the difficult parameters give Read timeout. Btw the implicit value 130 is exact in middle. Around that from 125 to 140 I tested each point. The other area by 5.

[cjoe-51]

@danielkucera
Well in the end the source of readout errors was in powering the adapter from the ebus.
After powering it through the USB connector (and taking out the respective jumper!) it seems to operate fine finally!
My recommendation - do start all setting up with the adapter powered from external powersource. Only after everything works perfectly you may try whether your ebus will be able to provide enough power. My does not.

Comment - I was lulled into a false sense of security by the fact that the adapter seemed to cooperate well with the ebusd sw in such way that it was possible to get basic parameters (external temperature, internal temperature, and some other system temperatures ... even system waterpressure). I thought, that when for some parameters the ebus communication works that it should work for the others. And therefore I left the adapter to be powered from the ebus and continued unsuccessfully searching the problem in configuration files etc. The adapter is located just next to the regulator, so it was nice to let it power from the ebus as there is no powersocket near the regulator ... Well, it was a trap for me :)

[danielkucera]

Hi @cjoe-51 , sorry for late response.
I am sorry you had to spent so much effort making it work but it is a valuable experience.
I am thankful to you for sharing it, I'll be able to better help other users.
If it's something you would be interested in, I can offer you another adapter for free.

[cjoe-51]

@danielkucera
Not at all. You vere responding quickly and Im happy that this was solved.
I can now remotely monitor basic parameters of the heating system an I can remotely change the requested temperature. Thats what I needed.as most important.
And I can confirm that your HW works great.

[mar3k]

@cjoe-51 I am so glad I found someone with similar experience as myself! I've been setting up ebusd with WIFI adapter for a few weeks and getting frustrated with different kind of problems. Initially after tuning it for a few days I got it working (many read timeouts but did the minimum I wanted). But then strange issues started appearing (erased energy data for day/yesterday/this/lastmonth on both boiler and vrc720 regulator; started reporting -40 outside temperature; etc etc). Tried restarting the adapter, tried tons of EBUSD config options, modified csv config files ... no luck.

Few days ago I switched to a closer router (before -80-90 dBm rssi; now -50-60 dBm rssi), worked a bit more stable from the beginning) but again changed to report -40 degrees temperature.

Two days ago I changed to USB power and everything started working perfectly. However the next morning I noticed "Generic I/O error" in logs and had to restart the adapter as it stopped working (not found http://esp-ebus.local/status). Now it's working well for ~30 hours so fingers crossed it'll be stable.

@danielkucera I think it may be worth emphasizing (or even recommending) to use USB power instead of relying on ebus only in the documentation of the adapter. Might save some frustration to other users.

[cjoe-51]

@mar3k. nice to hear that!