Closed zarch1972 closed 6 months ago
It seems some other heat pump users have experienced other erratic behaviour very recently - may or may not be related. In their cases, I believe the the heat pump would cycle on and off. https://github.com/john30/ebusd/discussions/1203 causing a fall in flow temperature over a relatively short period of time.
They found the issue when they started to use the repo 08.hmu.csv (which has had some recent commits). Your scenario may be different if you are using a fork of these but maybe the Jones files had had the new changes incorporated too? Reverting to older files, or setting --readonly appear to return to stable operation. Version of ebusd was not discussed in their thread.
Also did you do your refresh of the Jones forked files longer than two days ago? They have made a new commit within the last two days - and it says:
Removed ImmersionHeater related registers in 08.hmu.csv to avoid possible instability issues indicated by some
It's just a thought...
Interesting - I have also been seeing strange hot water behaviour, and using ebusd almost since day one of my Arotherm 5K installation a couple of months ago.
Thought it was maybe a Vaillant problem, maybe due to me not using the extra controller (Sensoconfort). I'm just operating the basic controller from HomeAssistant via ebusd.
As well as unexpected drop outs of water heating (initially assumed it was defrosting but now milder), the worst aspect is stopping the compressor, but keeping the pump running in water heating mode, causing the tank to cool significantly as heat is extracted to the external pipes and unit. I was going to put a rule in HA to switch off water heating when this was detected!
I'm still on 23.2 so don't think 23.3 is to blame. but I'm using config based on https://github.com/john30/ebusd-configuration/pull/377 from rmalbrecht as this seemed to work better for me than JonesPD at the time.
I also changed it to poll pretty frequently which maybe made this worse.
Was about to try latest from rmalbrecht and maybe JonesPD to see the latest state of play.
I'm pleased though its hopefully not a problem with the Arotherm itself. I don't have external heat sensors etc so hard to log behaviour without ebusd.
Fingers crossed its something like polling ImmersionHeater registers as mentioned by @JonesGW-MGD
@stevebirch - hopefully you get the bottom of this! Interesting you are still on 23.2 as helps maybe narrow the issue? (Of course doesn't rule out @zarch1972 has a different issue..)
Thanks for the replies. To add, it's not only on hot water that there were problems. But heating also.
You can see all these off/on cycles here. These are causing by something to do with ebusd i'm sure.
This was Thursday with ebusd running. No, they aren't defrosts, it was too warm outside for that and you don't see the flow/return flip-flopping here which it does when defrosting.
And this is yesterday with ebusd switched off. This is how my system should run. Long and slow with no stop/starts.
i have had the same phenomena since friday lunchtime.
I deactivated the EBUS today and then everything is running normally again, before that the compressor went off and on every 5 minutes
Same issue for me, been running for a year no issues but after updating HP cycling started. I am running docker image as well. As soon as I start the docker it starts cycling about 15 mins. I have stopped the image cycling stops. So it's not a hardware issue
Can anyone confirm what older image is working?
Glad to see it is not just me.
Can anyone confirm what older image is working?
I was running 23.1 with no problems prior to upgrading @jayis007
Just tried v23.3 to see if this makes any difference, it hasn't made any difference. ASHP Still bouncing
excatly the same behavior here (already discussed it a bit over at #1203 ) except for the fact that it's not depending on the eBusd version (using only 23.3 here) but the version of the configuration used (08.hmu.csv)
Heating System here: AroTherm Plus VWL 75/6 + UniTower Plus VIH QW + senso comfort VC730 + sensoNet VR921
What I was able to find out until now is:
Start with new configuration (08.hmu.csv) 9909b3a AND Home Assistant integration (--mqttint): Heatpump On/off cycling ~5min Log: current_08hmu.log
Start with configuration one commit older ceee6a0 AND Home Assistant integration (--mqttint): HP working as expected Log: old_08hmu.log
Start with new configuration (08.hmu.csv) 9909b3a WITHOUT Home Assistant integration : HP working as expected Log: current_woHAOS_08hmu.log
It's got something to do with the interaction between HA and ebusd. Maybe HA is triggering the polling of some parameters... ?
The following work-around seems to stop the cycling for me:
replace w,
with #w,
at start of lines
replace *w,
with #*w,
at start of lines
Basically, just comment out the new w,,ReadXXXXX
lines.
Is that a config change? Have you got these locally. Can you not check these files in?
Yes, to 08.hmu.csv, example diff: https://github.com/john30/ebusd-configuration/commit/122e82f21405e81ec5ee39ed3b0feaaa9ad57bfa. Local files. I'm also doing limited polling over mqtt using /get (4 topics, 10 second gap between each) and that seems to work fine too.
I have pulled the latest, commented out the writes uploaded the config files to a website using --configpath=https://xgility.eu/ebusd-2.1.x/en but giving an error saying ERR: Element not found. I have even copied the config to local path but it's still an issue in home assistant docker way --scanconfig=/share/ebusd-2.1.x/en
I can confirm the path is correct and I can get to file ok
docker run --name=ebusd --network hassio --rm -p 8888 john30/ebusd --scanconfig -d 192.168.0.139:3333 --configpath=https://xgility.eu/ebusd-2.1.x/en --latency=10 --mqttport=1883 --mqtthost=addon_core_mosquitto --mqttuser=mqtt --mqttpass=Locallogin --mqttint=/etc/ebusd/mqtt-hassio.cfg --mqttjson
Log lines before and after
could someone please go ahead and clearly determine whether it is related to ebusd update or csvs update? I'm pretty sure this has nothing to do with the ebusd version 23.3. digging around with combinations of the one and the other update without coming to a conclusion on either side will not bring this forward.
funny to mention a foreign repository and filing a bug here though ;)
Hi John
Definitely CSV issue. Can this be rolled back. I can't use configpath option either for some reason.
From: John @.> Sent: Thursday, February 29, 2024 9:28:58 PM To: john30/ebusd @.> Cc: Junaid Saleem @.>; Mention @.> Subject: Re: [john30/ebusd] Has 23.3 stopped my heat pump running properly? - 5kW Arotherm Plus (Issue #1205)
could someone please go ahead and clearly determine whether it is related to ebusd update or csvs update? I'm pretty sure this has nothing to do with the ebusd version 23.3. digging around with combinations of the one and the other update without coming to a conclusion on either side will not bring this forward.
funny to mention a foreign repository and filing a bug here though ;)
— Reply to this email directly, view it on GitHubhttps://github.com/john30/ebusd/issues/1205#issuecomment-1971992941, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ADMCLNQVPDPKTPKGYJNOGGDYV6ORVAVCNFSM6AAAAABDYW2PTCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNZRHE4TEOJUGE. You are receiving this because you were mentioned.Message ID: @.***>
Looks like I'm still encountering issues. The tell-tell sign is the heat pump stops even though the energy integral is negative. I don't think there is any reason for this to happen under normal circumstances, and as soon as I stop ebusd it starts-up again. I'm not sure this is purely a CSV issue, as my modified CSV has no 'w' lines, and surely the addition of some new 'r' lines shouldn't result in such behaviour?? Unfortunately, I'm not sure if this problem existed before the recent CSV changes as I wasn't paying such detailed attention to heat pump behaviour as I am now. Also, I'm running 23.2.3. I'm also unclear at this stage, whether the act of polling triggers the issue. I'm also under the impression that the issue isn't triggered immediately, but after some time.
I've reverted https://github.com/john30/ebusd-configuration/issues/316 for the time being. looking at it more closely leaves quite some questions... please check if this eases the situation described here
Done some more testing today to try to pin down the issue. In read only mode, looks good. Turn off read only mode, end up with large -ve integral and pump off. Now, there are some basic things I dont understand. As I understand it, the only write should be to auto discover the config. But in the log I see send poll update messages for things that dont have auto poll enabled. Maybe I misunderstand the log mesg?? The other thing I dont get is if I physically go to the live monitor screen, it doesn't seem ebusd sees any of these messages. Does live monitor not trigger anything over ebus, or cant ebusd see them? I thought it snooped on everything.
Hy, after reading John´s comment from yesterday, i set in HA the Ebusd integration back to autostart and completely restarted HA. The reverted 08.hmu.csv was loaded automatically, as well as other csv for my system. The corresponding data is received correctly.
The heat pump has been working absolutely normally since then!
Best regards Marko
I can also confirm things are back to normal. Could do with knowing how how to load local csv's
From: mthomalla @.> Sent: Saturday, March 2, 2024 5:59:11 AM To: john30/ebusd @.> Cc: Junaid Saleem @.>; Mention @.> Subject: Re: [john30/ebusd] Has 23.3 stopped my heat pump running properly? - 5kW Arotherm Plus (Issue #1205)
Hy, after reading John´s comment from yesterday, i set in HA the Ebusd integration back to autostart and completely restarted HA. The reverted 08.hmu.csv was loaded automatically, as well as other csv for my system. The corresponding data is received correctly.
The heat pump has been working absolutely normally since then!
Best regards Marko
image.png (view on web)https://github.com/john30/ebusd/assets/123564658/d5b3196e-4ca6-4228-97eb-333fa52a2647
— Reply to this email directly, view it on GitHubhttps://github.com/john30/ebusd/issues/1205#issuecomment-1974332871, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ADMCLNT4XASQCAGZQY77G2LYWFTC7AVCNFSM6AAAAABDYW2PTCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNZUGMZTEOBXGE. You are receiving this because you were mentioned.Message ID: @.***>
updated my first post with the log files. Maybe somebody can make more sense of it? I still don't get why and how HA can mess with the message polling as this is defined in the ebusd config file. @john30 let me know what you need to be tried out. Would be glad to help find the root cause here
I think I have observed that my heat pump stopped working after the log showed a bunch of sent poll-read hmu ...
statements. I inspected your logs that both current_08hmu.log and old_08hmu.log show these statements, but not current_woHAOS_08hmu.log.
I am not too familiar with ebusd, but as far as I understood it only actively polls values if the configurations contain a poll priority (see message definition). However both configs the new one (9909b3a) and the stable one (9909b3a) do not have polling configured. Hence, this must be done by the HA integration.
My naive guess is that instead of simply listening, HA is making ebusd read a value that should only be polled by the controller and thus brings the system to a safety stop of sorts.
I dug into the HA integration code and found that ebusdpy (which is used by the HA integration) is issuing the following to read values:
with a ttl
of:
According to the documentation, this command instructs ebusd to actively poll from the bus if the cached values are older than 15 minutes (900 seconds). I believe this leads to the crashes of the heat pump, because there are now two masters (the controller and ebusd) actively polling these values.
If somebody can confirm my theory, I would open an issue at ebuspy to make sure that it never actively polls the bus by default.
I can cast doubt on your theory, or at least it is not the whole picture (maybe it is an additional issue) as I'm not using HA integration (I'm using HA addon, so ebusd in docker, sensors over MQTT). I'm now testing the current (reverted config) but using the newer config names (and entries sorted by ID) to reconfirm everything was previously working before. I then plan to incrementally add back in the new changes until it breaks.
Good catch! However, I think it still can be the same problem. In the mqtt-hassio.cfg, the filter-seen
option is set to 5, which means that values will be polled with a priority of 5. If my assumption is correct, setting the filter-seen
option to 1, should fix the problem, because it prevents ebusd from actively polling read messages.
Oh, that is interesting. So, those new CSV changes could have meant automatic polling was triggered on something new that didn't take too kindly to being polled. I'll do some testing with it set to 1.
It is working well, current cycle > 2 hours. @jkunczik, well done, I think you've nailed it. @john30 I've raised https://github.com/john30/ebusd/pull/1213 for mqtt-hassio.cfg.
Glad to hear! Thanks for testing and opening the pull request. I opened an issue at ebusdpy (CrazYoshi/ebusdpy#10).
Same problem here (Vaillant Arotherm plus 7.5kW), I had over 50 compressor starts per day (usual: 1-3) since upgrading to the current 08hmu version, terrible. Will report back if changing the filter setting in the hassio.cfg file stops the problem.
which one are you refering to exactly @chheiss ?
Can anyone recommend a good working config. Currently running John32 master at ceee6a0 but there are some sensors missing. I do not have flow for example. Arotherm+ 7kw
Thanks pulquero. I am now using your fork and its working nicely but still have a bunch of unknown data and flow sensor is still missing (looking to get liters/minute which I believe should be announced).
The flow rate should be given by LiveMonitorBuildingCircuitFlowRate - I have it working in HA. Check your filter settings.
The flow rate should be given by LiveMonitorBuildingCircuitFlowRate - I have it working in HA. Check your filter settings.
I have no sensors under 'LiveMonitorBuilding...' but some under 'LiveMonitorPower'. What filter settings are you referring to? And is there some channel I can write to you not to fill this "issue" with unrelated messages.
If you like raise an issue on my github against my config.
If you like raise an issue on my github against my config.
I just tried doing so but issues tab is missing. Could it be you don't have issues enabled on your fork?
Anyways I added the filter-name=
flag to the MqttVariable section in the configuration of the integration in HA. Tons of new stuff but nothing under LiveMonitorBuilding..
. I have scanned the mqtt topics several times before (using mqtt explorer) but never seen the flow there either.
Issues enabled.
Issues enabled.
Thank you. I've posted my case there now 🙂
closing as not an ebusd issue in the first place and discussion going on elsewhere
Description
Did ebusd break my hot water runs? (and heating, see later comment)
I have been running an older version of ebusd (23.1) for about a year. Coupled with occasional updates of Jones config files.
decided to upgrade everything.
I upgraded the core ebusd to 23.3 and the Jones files to the latest https://github.com/jonesPD/ebusd-configuration
Since those upgrades my hot water runs started to go wrong.
Here is a trace from my Open Energy Monitor heat meter monitoring.
Actual behavior
You can see wobbles in the hot water runs. Drops etc.
Is there too much polling going on in this new version? Putting too much pressure on the Arotherm controller?
Just guessing really.
Expected behavior
Yesterday afternoon I stopped the ebusd service on the Pi and last night run was rock solid again.
So too much coincidence that I upgraded on Tuesday and things started going wrong. Then I shut it down Saturday and hot water runs were okay again.
13:03 yesterday was a time when it dropped out. see log below.
ebusd version
23.3
ebusd arguments
EBUSD_OPTS="--scanconfig=full --configpath=/home/mick/jones/ebusd-configuration/ebusd-2.1.x/en -d ens:/dev/ttyAMA0 --latency=60 --loglevel=debug --mqtthost=carbone.lan --mqttport=1883 --mqttint=/etc/ebusd/mqtt-hassio.cfg --mqttjson --mqttvar=filter-direction=r|u|^w"
Operating system
Debian 12 (Bookworm) / Ubuntu 22-23 / Raspberry Pi OS 12 (including lite)
CPU architecture
x64
Dockerized
None
Hardware interface
Adapter v3 RPi
Related integration
No response
Logs
2024-02-24 00:13:03.613 [bus debug] ERR: read timeout during receive command ACK, switching to skip 2024-02-24 00:13:04.011 [network debug] dead connection removed - 0 2024-02-24 00:13:04.364 [bus debug] ERR: read timeout during receive command ACK, switching to skip 2024-02-24 00:13:05.115 [bus debug] ERR: read timeout during receive command ACK, switching to skip 2024-02-24 00:13:05.115 [bus info] poll cmd: 3176b51405052903ffff