-
Notifications
You must be signed in to change notification settings - Fork 15
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Read timeouts on most of the variables/parameters [SOLVED] #101
Comments
Hi @cjoe-51 , can you provide the log as described in README troubleshooting? |
I will add the log in a moment. The heating is remote from my location so some steps are necessary. |
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). And in addition here is the ebusd info:pi@pi4Iob:~ $ sudo ebusctl i |
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. |
OK, I will try the PWM. |
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. |
@danielkucera 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 :) |
Hi @cjoe-51 , sorry for late response. |
@danielkucera |
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) ?
The text was updated successfully, but these errors were encountered: