ebusd/HA: Enabled writable entities, accidentally overwrote parameters

[lost18966-commits]

Hi everyone,

I integrated my heat pump into Home Assistant via MQTT, using the eBUS Adapter C6 Shield and the ebusd add-on. Until now I only had sensors. To be able to write values as well, I added the extra ebusd option --mqttvar=filter-direction=r|u|^w (the bundled mqtt-hassio.cfg with --mqttjson is active). After that, number/select entities showed up in HA.

Unfortunately, I then changed two sliders on the dashboard without knowing the original values first:
SetFlowTempMax and
SetFlowTempMin in the circuit hwc.

Both sliders were at the left stop afterwards.

I assumed that touching the slider would show me the original values. It didn’t; they showed “unknown”.

The HA history shows “unknown”, and the ebusd log has no entries from before my change.

This is what ebusd shows in the terminal (ebusctl find -c hwc -w -V):
hwc Load = no data stored [ZZ=25, active write]
hwc OperatingMode = no data stored [ZZ=25, active write]
hwc Party = no data stored [ZZ=25, active write]
hwc Save = no data stored [ZZ=25, active write]
hwc SetFlowTempMax = value=20 °C [Temperatur] [ZZ=25, lastup=2026-10-17 16:33:24, active write]
hwc SetFlowTempMin = value=17 °C [Temperatur] [ZZ=25, lastup=2026-10-17 16:33:44, active write]
hwc SetMode = no data stored [ZZ=25, active write]
hwc SetTempDesired = no data stored [ZZ=25, active write]
hwc Timer_* = no data stored [ZZ=25, active write]

Also, ebusctl read -f -c hwc SetFlowTempMax only returns ERR: element not found. So these messages seem to be write-only, with no read variant.

I haven’t touched any of the other writable hwc messages (no data stored).

My questions:
What exactly do SetFlowTempMax and SetFlowTempMin in the hwc circuit limit (e.g. the flow temperature during storage charging)?
Is there a way to read the current or original values via eBUS, e.g. through another message or a raw hex command?
Does anyone know which default values are typical for this system, or where to find them in the device menu?
Does the controller reset these values by itself, or do they stay like this until someone changes them?

Heat pump: Vaillant geoTHERM VWS 81/3

What I have found out in the meantime:
Both messages are write-only. They can be read via hwc Params (from ebusd-configuration, hwcmode.inc). That shows me the current state in the unit:
hwc Params = 48;hwc;22;17;20
mc Params = 20;19;0.20;mixer;21;0;15;43;0

The last two values of hwc (17 and 20) match exactly what I wrote. The unit accepted them, and they were not reset even after a good two and a half hours. For the mixer circuit (mc), which I did not touch, the values are 15 and 43 °C.

I don’t know the original values, because I had never read this message before. A before/after comparison of all display menus via video shows no change apart from one altered setback temperature (which I have restored).

After a restart (power cycle via the circuit breaker, controller RebootCounter 5713 → 5714), the values are still 17/20.

Function test (hot water set to “On”):

The compressor started after about 2 minutes, ehp HeatPumpStatus = water.
ehp SetMode: hwcflowtempdesired=40 °C, so well above my 20 °C.
Condenser temperature rose from 22 to 47 °C. The high pressure reached about 27.8 bar (the high-pressure switch trips at 30 bar according to the manual), then dropped to 12.6 bar, and the system continued with status heat.
ehp Currenterror is empty, and there is no new entry in the error log on the display.

The two values apparently don’t hinder hot water charging, probably because my system has no mixer and charges directly via the heat pump. I’m not sure, though.

My questions:
What values do you have for hwc Params (last two fields) and mc Params? Is there a typical default value for the hot water module?
Do SetFlowTempMax/Min in the hwc circuit have any effect on hot water charging on a geoTHERM with EHP00 and no mixer, or are they ignored?
Is a high pressure of almost 28 bar during hot water charging normal with this storage tank?

Thanks for any hints!

[lost18966-commits]

How to read these values on your own system (inside the ebusd container/add-on terminal):
ebusctl read -f -c hwc Params
ebusctl read -f -c mc Params

[woody5350]

Hope this helps.
It is from my Vaillant GeoTherm VWS 101/2

[woody5350]

I have just had the heat pump replaced after 14 years. The engineer said it has become weak and wasnt generating the right pressure differential. The error I was getting was Refrigerant Pressure too high, at about 30 bar, which is where it trips out.

Here are last 24 hours operation for mine after replacement 2 weeks ago.

[lost18966-commits]

Hi @woody5350

Thank you very much, that helps a lot!

I had accidentally overwritten SetFlowTempMax/Min on my VWS 81/3 (now reads 48;hwc;22;17;20). Your values (43;hwc;22;15;80) match what another user posted for a VWL 82/3, and my own Home Assistant history shows the desired flow temperature of the DHW circuit was 80 before I changed it. So I’m considering restoring it to 15/80.

Your pressure graph is interesting too: on my unit the high-side pressure also reaches about 27.7–27.8 bar during the hot water charge, and sits at about 9–10 bar when the compressor is off. So that looks the same as on your new heat pump, which is reassuring.

Thanks again, and I hope the new unit keeps running well!

[lost18966-commits]

Hi @woody5350
Thanks again for the quick answer! The pressure view is a great idea, I rebuilt it right away in Home Assistant (High side / Low side / Differential, plus a 24 h history). At the moment it shows 12.95 bar high and 4.93 bar low, so about 8 bar differential. The chart is still empty because I only just set it up, I’ll post an update once it has a full day of data.

It wasn’t that easy though: the pressure values (CompPressHigh / CompPressLow) are not published to MQTT by ebusd on their own, they only show up once they’ve been read. I solved it with an automation that sends a read request (.../get with payload ?) every 30 seconds, and MQTT discovery sensors on top of the replies. The differential is a template helper.

[woody5350]

Glad to help. I use Chatgpt to do all the logic stuff and find it really good at investigating issues.
I am currently trying to establish virtual on demand hot water buttons so I can stop my circulating pump running all day. I am getting different advice on whether I can reliably use ‘set mode’ to simple turn the pump on and off on demand.

[lost18966-commits]

Good luck with the on-demand button idea, that sounds like a nice way to save energy. Unfortunately I can’t say anything reliable about “set mode” for the circulation pump, my setup is read-only for now and I haven’t tried it.
One experience that might be useful though: I accidentally overwrote two hwc parameters (SetFlowTempMax / SetFlowTempMin) with a wrong write and that’s how this whole thread started. So with anything that writes, I’d first read the current value, write once, read it back, and keep a note of the original values so you can restore them. It also helps to check in ebusctl that the message is really a plain on/off for the pump and doesn’t also change a stored parameter.

[woody5350]

Good advice. I have since found that my boiler has an instant overide connection designed for precisely for controlling the circulation pump. Just need to select a suitable remote relay :-)

[woody5350]

In the process of establishing the most effective method of controlling the ciculation pump, it decided to create a dashboard for updating all the timers. I thought you might find this useful?

[lost18966-commits]

Yes, very useful, thank you! The screenshot gave me the idea for an overview of all timer programmes.

I didn't install the ZIP (I prefer to keep my setup read-only), so I built a read-only version for now myself: a single Markdown card in HA that reads the existing ebusd entities (hwc / mc / cc Timer_, with from/to, _2/_3 and daysel) and shows one table per programme: Day | Period 1 | Period 2 | Period 3 | Selection, today's row in bold.

Thanks again for all the help. I also wrote the two parameters back to the heat pump earlier:
hwc Params is now 48;hwc;22;15;80 (min 15 / max 80), read back and checked, and the neighbouring values are unchanged.

Step 0
ebusctl read -f -c hwc Params -> 48;hwc;22;17;20

Step 1
ebusctl write -c hwc SetFlowTempMax 80 -> done
ebusctl read -f -c hwc Params -> 48;hwc;22;17;80
ebusctl read -f -c hwc OperatingMode -> Auto
ebusctl read -f -c hwc StorageTempDesiredStart -> 48.00
ebusctl read -f -c hwc StorageTempDesiredStop -> 65.00

Step 2
ebusctl write -c hwc SetFlowTempMin 15 -> done
ebusctl read -f -c hwc Params -> 48;hwc;22;15;80

[woody5350]

GSHP_Programme_Scheduler_v2_0.zip

You will find a comprehensive installation instructions in the Readme

[woody5350]

I havent managed to find the write controls for the holiday programme yet. On my to do list...

[lost18966-commits]

Getting HolidayPeriods into HA via MQTT (untested draft, read-only)

ebusd only publishes a message to MQTT after it has been read once, so you need a read trigger plus a sensor.

Check that it reads: in the ebusd terminal run ebusctl read -f -c uih HolidayPeriods. Mine returns 01.01.2003;-.01.2001;01.01.2003;-.01.2001 (placeholders, no holiday set; looks like start1;end1;start2;end2).
Trigger a read: in HA create a UI automation (time pattern, e.g. every 15 minutes) with the action mqtt.publish, topic ebusd/uih/HolidayPeriods/get, payload ?. This only reads, it never writes to the heat pump.
Look at the payload: in HA open Settings → Devices & services → MQTT → “Listen to a topic” and subscribe to ebusd/uih/HolidayPeriods. The payload format depends on your ebusd MQTT settings (single string or JSON with fields).
Create the sensor: add an MQTT sensor (discovery or UI) on that topic. Use a value_template matching what you saw in step 3, and split the string with .split(';') into start/end dates.

[woody5350]

Thank you. Interestingly it would appear the holiday timer logos is not so obvious. Start 1 is couple with End 2 and Start 2 is couple with End 1…. It was reported previously in a Vaillant forum.

Have changed my mind of the approach to on demand and will implement a flow sensor independent of HA. ha will monitor it, but turning on a tap will activate the pump is a closed circuit fashion. Not sure why they didn’t work natall it that way in the first place.