-
Notifications
You must be signed in to change notification settings - Fork 1
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
Communication errors #53
Comments
With the latest firmware on my ebus adapter I experienced a similar issue, not sure if it's 100% related to your problem. |
I'm digging into the logs (/var/log/ebusd.log) and noticed [bus errors] at the same time as the clicking in the VWZ AI happened. Among the regular log entries messages, these things are logged:
I'm commenting out every entry in the csv files for everything my system does not have (like the immersionheater, zone 2 and 3) or I am not interested in. Running for an hour now and the [bus error] don't appear. Let's run it over night and see if the comm error reappears |
Running over night still yields [bus errors]: 2024-03-29 00:04:43.181 [bus error] poll basv Hc1ActualFlowTempDesired failed: ERR: read timeout Bus arbitration errors concern me a little bit. |
hard to tell without knowing which firmware you're using actually. |
Currently on Build: [20240317] I saw the symptoms about a month ago and then switched to the JonesPD repo. I've switched to --configpath=https://cfg.ebusd.eu and ran the ebusd again, bus errors still occur: 2024-03-30 11:12:32.805 [mqtt error] decode basv z1Timer.Saturday: ERR: invalid position 2024-03-30 11:56:27.313 [mqtt error] decode basv z3CoolingTimer.Wednesday: ERR: invalid position 2024-03-30 11:53:16.150 [update error] unable to parse poll-read basv z2CoolingTimer.Friday from 3115b524050303010104 / 00: ERR: invalid position The errors occur less than before but that may also be the result of the VWZ AI csv file missing: 2024-03-30 10:20:26.549 [main error] unable to load scan config 76: no file from vaillant with prefix 76 found |
Running for a while noticed a bus error signal lost: 024-03-30 15:08:48.280 [mqtt error] decode basv SFMode: ERR: invalid position |
a read timeout and some arbitration losses are nothing unusual for such a bus, the rest is just messages noting that the response does not match the definition, so someone would need to fix those. is the signal loss permanent or does it come back shortly after that? if using wifi, switching to another transport (ethernet or usb/rpi) might help |
Ok, those read timeouts are nothing to worry about then. Updated to 20240330 yesterday, does the update have any effect on the symptoms:
The signal lost happened twice today:
Any advice on these events? |
sounds a bit as if you had more than one ebusd instance running, please check that |
you might want to try the newest version just released as there were tons of commits related to wifi in ESP-IDF again |
With the latest ebusd Adapter firmware, the "Kommunikationsfehler" error message which stopped my heatpump from working, disappeared. I am running it 2 weeks without this error message. Before I had this error message caused by the connected ebusd adapter multiple times a day, which blocked my heatpump. @mintgroen can you confirm this behavior too? |
please check with the new version 20240505 just published if this is still the case |
Last week I had the same issue for a few times, after ebusd had been running for 5 months on my Vaillant VWL 75/6, with VWZ AI and sensocomfort 720, |
This morning (12/6/2024) I had another F9998 failure of the heatpump. I am wondering if this error might be connected to a certain batch of ebusd adapters. Hope it helps tackling the problem |
F.820 Verbindungsfehler: Pumpe GebäudekreisIch hatte eine Zeit lang ganz viele Kommunikationsfehler, das lag aber eindeutig feststellbar am esp32, nachdem ich dort das WLAN sowie den Access-Point deaktiviert habe und nur noch über Ethernet gegangen bin, waren diese Fehler weg. Ich habe im gleichen Zuge auch die nicht benötigte LED Signalisierung deaktiviert, also praktisch alles was auf dem esp32 asynchron irgendwie läuft, damit der Kommunikationsprozess nicht beeinträchtigt wird. Gestern kam jedoch zufällig der Error "F.820 Verbindungsfehler Pumpe Gebäudekreis" zurück. Dieser könnte aber auch auf einen Bug in der Vaillant Platine zurückzuführen sein, wie er hier beschrieben wurde. |
Yesterday i upgraded the firmware of ebusd to the latest version (1451a) as advised by John; however, a few hours after that the F9998 error was back. As I still needed the heating pump for heating ; I disconnected ebusd completely from the system. This morning after reconnecting (Start PI with EBUSD connected), the relay in VWZ was switching on and off my CV-circuit heating pump irregularly, for no reason! Disconnecting ebusd stopped the pump from switching. Relay stopped flattering as well. reconnecting I a few hours later and then after startup connecting EBUSD, seems OK for now Still I can not get correct entries for live monitor to read the exact status of the heat pump ( running, idle, deicing....) |
the live monitoring stuff is known to be highly problematic. I had updates to those merged in to the csv webservice and as several users claimed instability, i've reverted it. |
Thanks. I still have the following Livemonitor sentences running , as I got continuous read errors on the original descriptions (CurrentYieldPower and CurrentConsumedPower, but will retry after I now got rid of all the other read errors; these have worked before): Values from Live Monitor,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,*r,,,,,,B51A,05,,,,,,,,,,,,,,,,,,,,,,,, (from :https://github.com/john30/ebusd-configuration/pull/316/files). So far no reading errors and no F9998 failure. |
not sure where the bold sentence came from and this is a comment sentence only (forgot to copy the #) |
After a few weeks of fine running,, I again experienced a communication failure today, so I removed the last Livemonitor sentences that were active to get current power and current yield. (see above) As such this is strange as the original definition worked without errors up to about april this year |
My installation:
Vaillant AroTherm+ 105/6, VWZ AI (only 1 temp sensor + ebus), Thermostat VRC 720f, VR912 (sensonet gateway). Ebusd is connecting to the ebus interface over WiFi, powered by an ipad USB plug, 5v connected to the header.
Since some week I noticed strange behaviour of the heatpump, stopping at regular intervals while there was no reason to stop (like defrosts or target room temp reached) and the starts were way before the energy integral reached 0.
The p1 data also reflected what the flow temperature was showing:
I initially thought it was a buggy/still hanging automation or something that I removed after testing. The symptom could be stopped by changing the ebusd to read only or stop the ebusd. since I would like to work on some automations in the future, I tried to work around the (HA?) issue by removing the ebusd from HA and migrating the ebusd to a 2nd rasperry (running RaspberryOS) and changed th csvs to the JonesPD repo.
After running for some days I noticed that the heatpump stopped working completely so I checked the VWZAI, error F9998 was on the display:
I disconnected the ebus interface, restarted VWZ AI. But I needed to power down/up the Arotherm to get the system back online. Let the system run for a week, no comm errors occurred.
After some advice on Tweakers I tried switching the power supply. Tried another 2A USB plug and switched to the USB cable to power the interfase, after some hours:
One thing that I noticed is that a relay in the VWZ AI is clicking, once every 10s, maybe 3-4 times and then again after about 10 minutes. (similar to the compressor stops above). That is strange because I don't have anything connected or configured at the 230v relay control? Could be 2 related or seperate (csv misconfig?) issues?
And again, disconnected the ebus interface and the system is again running without any comm errors or clicking relay.
Do you have a clue what to do to resolve (both) issue(s)?
The text was updated successfully, but these errors were encountered: