Vaillant VCW 244 keeps resetting the desired flow temp to the temp knob of the front panel

[connyg]

I have a Vaillant VCW 244 heating system, used for heating only, not for water. It's without additional controller, just the built in standard control panel with "i", +, - and the Kaminkehrer button, plus the round dials for water temp and heater flow temp.
Attached on the Ebus connector a Ebus to Wifi Adapter Module by Danman:
https://www.elecrow.com/ebus-to-wifi-adapter-module-v5-2.html

I use it in Home Assistant with the community provided add-on.
The Add-on receives data and publishes it via MQTT, I get a whole catalog of sensor values.

After some research and trying I found out that I need to update the value "FlowTempDesired" and that I need to do that via MQTT.
That does change the value in the heater, BUT it gets reset after a few minutes to the temperature that dialled in with the knob on the front panel of the heater.

I would assume that the Vaillant heater would keep the Ebus value if it was aware that it is controlled by an Ebus controller.
I assume that this is what I can see checking the D.90 register value using the "i" button on the front panel.
But this D.90 shows "0" which says: no Ebus controller present.

I have read through installation manuals, there are hints that if I install an Ebus controller I should bridge the "RT 24V" connector.
In that doc it shows as a connector with 2 poles.
It seems that's the 7-8-9 interface, in my case, if I researched correctly. I don't have any RT 24V port with just two connectors.
So I tried to bridge the 7 with 8 or 9 - 7 is the temp set pin, 8 and 9 are GND and 24V.

But then observing the behavior of the heater it would set the desired temp to 0 if I bridge to GND and to 90 degrees if I bridge to 24V - as it should behave.
If I then set the temp via Ebus, it's again reset to 0/90 after a few minutes.
So the bridging of RT 24V does not make any difference.

Is there any other way to tell the heater that it is supposed to stick to what the Ebus says?

In some other place (don't remeber where) I found a hint that it would discover and accept controllers with an address < 10.
Tried to set the ebusd address to 1, but did not make a difference.

Of course I could set the value like every minute. But to me that's a hack, not a solution - feels like I just keep overriding the behavior of the heater and I am not sure if it's supposed ot be that way.

Kind regards,
Conny

P.S. Documentation around the Ebus adapters, ebusd, ebusd-configuration, the setup in Home Assistant is a nightmare.
All fully in the details only, a few setup instructions differ vastly, it takes a few hours of reading to understand how things play together.
Once you are through the forest it becomes clearer. But as a newbie you have no idea where to start and what to believe.

[connyg]

Meanwhile I understand that the "FlowTempDesired" register is "read only", I dived in the workings of the configuration files and identified my device.
And I find that this is an issue for many who try Ebus adapters with ebusd, there is lots of discussions about similar scenarios.

So I tried to find another value that is writable and that I can modify.
I found in the config files that "FlowsetHcMax" is writable, but not shown in the list of registers polled / synced by ebusd, they are not shown in Home Assistant.
There is a filter set for ebusd that suppresses all writable values, but the alternative settings of the filter didn't work for me (yet).
If I modify the FlowsetHcMax via MQTT directly, that works, the value is changed if I re-poll it.

The heating behaves a bit strange, though, and that does make sense to me, in the end:
If I modify the FlowsetHcMax - that's the maximum flow temperature that shall be used by the heater - and turn the flow temp knob on the heater to the full right (max desired temperature), then the desired temperature, when polled from the heater, is always a few degrees below the maximum temperature.
That makes sense as the desired temp needs some hysteresis to swing, it can't swing around max, it needs to swing below.
So if I want to have a flow temp of 50 degrees for the current -5 C of outside temperature, then I need to set the FlowsetHcMax to 75 degrees to achieve a FlowTempDesired of 50 when polling it.
But I have the impression that now the heater heats to more aggressive "spikes" in flow and backflow as it did before.

So I don't feel really good about going this route.

Next I will try to clone the ebusd-configuration files and set the FlowTempDesired to writable.
Alternatively implement that "SetMode" command that seems to be supported by the heaters, but is usually not in the config files.
I wonder if that should be, could be a feature in ebusd to support the SetMode wherever applicable.

[connyg]

Cloned the config files, modified FlowTempDesired to writeable.
When setting FlowTempDesired e.g. to 40 degrees via MQTT it does now write it, according to the ebusd log.
But when I read it back it, then it's again 50 - which the heater sets itself.
So that's not the way to do it.

[connyg]

Now trying the SetMode route.
Following
john30/ebusd-configuration#170 (comment)
and
john30/ebusd-configuration#388

[connyg]

Oh! I discovered that SetMode is implemented in hcmode.inc!

[connyg]

After lots of testing, fiddling, researching in the config files I got the SetModeOverride that I added myself to the heater model config in CSV to work:

ebusd/bai/SetModeOverride/set
with payload:
0;44;56;0;0;0;0;1;0;0;0;0

Strangely at start the SetMode (that's already in the hcmode.inc) did fail for "invalid numeric parameter" or something.
Later it was just ignored - I don't what changed.

This is all very complex and weird, if you don't understand the internals. I start to get some idea how it works, but still too little to be sure what fails.
However, that's a starting point now. Puh, what a lot of effort.

[connyg]

And now - as my heater just reset the temperature to the know-set one again - I am finally back to the original question:
How do I override the front panel knob temperature?

It seems the paramters that are access mode "uw" in the config files are parameters that need to be updated latest every 10 minutes by the controllers.
So I assume I need to send my desired temperature via SetMode every few minutes to keep it.

[connyg]

It is working the correct way now, with my custom SetModeOverride added to the CSV configuration file.
Somehow I could not get the SetMode in hcmode.inc to work yet.
But as it's the same I stop tinkering here.

I am resending the desired temperature every 5 minutes with a Home Assistant automation. The front panel dial knob is set to 50 degrees, I am sending 52 degrees from home assistant. The desired temperature polled via ebusd is stable at 52 degrees. Nice.

Next I will calculate the new desired flow temperature every 5 minutes on basis of the outside temperature, the original goal of all this.

In the attached chart is to be seen that now the heater behaves as desired and swings a few degrees around the desired temperature. In the first half there are these weird 70 degrees spikes that were caused by setting FlowsetHcMax.

[connyg]

Added the HACS template "CompCurve":
https://github.com/rawnsley/CompCurve
that provides the heat curve calculation from a given outside temperature and config parameters (like which heatcurve factor to use) and reflects the calculated, proposed flow temperature in a sensor variable.
For this I created a sensor helper extracting the outside temperature value from the weather object in home assistant, that's the source of the outside temperature for CompCurve.
I think I would not have been difficult to implement the heatcurve calculation myself, but this looked ready to go and save 2 hours of work plus testing / refining and it did.

That CompCurve calculated flow temperature is now used for the SetMode update every 5 minutes and with this, my heater is finally controlled dynamically on basis of the outside temperature.