set_opentherm_parameter

[ikoz]

Is there an example of how to use the set_opentherm_parameter service and what is possible using it?

[msp1974]

John, there is currently not an example in the documentation and what it can or cannot do is very variable based on your boiler. We added this service to allow some of our community to experiment with changing these parameters (note: not all of them can be changed, not all of them do anything).

There is some good chat on our forum from people who have opentherm boilers playing with settings and how they control things (both boiler side and Wiser side). There is also knowledge that the WIser opentherm implementation is somewhat basic at present.

Below is an example and link to our forum (I don't have an opentherm boiler so questions are prob best posted on forum to get you the best help/advice). I would always recommend downloading a diagnostic output from the HA integration to see the opentherm data you have and the structure. With this and the below example, I hope it will make sense.

service: wiser.set_opentherm_parameter
data:
  endpoint: preDefinedRemoteBoilerParameters
  parameter: maxChSetpointLowerBound
  parameter_value: "350"

https://community.home-assistant.io/t/drayton-wiser-home-assistant-integration/80965/2211

[ikoz]

@msp1974 thank you very much! I have tried altering maxChSetpoint and maxChSetpointUpperBound (inside preDefinedRemoteBoilerParameters) but it looks like it doesnt succeed in my case:

"Failed to call service wiser.set_opentherm_parameter. Error setting parameter. This is an invalid parameter/endpoint or maybe a parameter that cannot be set".

Likely because maxChSetpointReadWrite is false in my case (while maxChSetpointTransferEnable is true)

However, I think i had success with the following:

service: wiser.set_opentherm_parameter
data:
  parameter: chFlowActiveUpperSetpoint
  parameter_value: 595

This indeed changes the CH active upper setpoint locally in wiser to 59.5C and is reflected in later diagnostics.
Note this only worked if the parameter_value does not have quotes (by default HA developer UI mode puts quotes in that).

I think this does what I need it to do -to allow wiser to modulate with a custom temperature as upper setpoint limit, no matter what the boiler's upper setpoint limit is.
I'll test some more but it looks like this works so I'll likely not need to use an OpenTherm GateWay device inbetween wiser and the boiler to achieve the same goal.

[msp1974]

Great. Will close this issue for now.

[andyblac]

@ikoz can you explain how you did this, I want to change my MAX Flow rate. I am new to HA so a step by step guide would be really appreciated.

here is what i have

[ikoz]

@ikoz can you explain how you did this, I want to change my MAX Flow rate. I am new to HA so a step by step guide would be really appreciated.

here is what i have

In your case you can see the following from your picture:

1. preDefinedRemoteBoilerParameters.maxChSetpointTransferEnable is true
2. preDefinedRemoteBoilerParameters. maxChSetpointReadWrite is true

This means that the hub can (A) read your boilers max CH setting (this is what has been set up in your boiler side) and (B) that it can actually adjust your boiler's max CH setting as well.

What you need to do is probably the one of the following:

Option1:

service: wiser.set_opentherm_parameter
data:
  endpoint: preDefinedRemoteBoilerParameters
  parameter: maxChSetpointUpperBound
  parameter_value: 600

Calling the wiser.set_opentherm_parameter service to set preDefinedRemoteBoilerParameters.maxChSetpointUpperBound with value 600 should set the max CH flow temp to 60C on the boiler side (and then the hub should read this setting and set it as chFlowActiveUpperSetpoint.

Option2

service: wiser.set_opentherm_parameter
data:
  parameter: chFlowActiveUpperSetpoint
  parameter_value: 600

Calling the wiser.set_opentherm_parameter service to set chFlowActiveUpperSetpoint with value 600 should set the max CH flow temp to 60C on the wiser side, which may likely be reflected to the boiler side as well in your case.

The above service calls can be done for testing using the developer tools UI in HA or you could make them part of your automations (e.g. when external temp sensor is X then set upper setpoint to Y).

If it works you should be able to see chFlowActiveUpperSetpoint is what you have set. Then wiser will use this value to calculate what the flow temp setpoint should be at 100% demand.

Just note that you likely dont want to be adjusting these max values all the time; I dont think that adjusting them according weather compensation is a great idea actually. In Opentherm mode, the system will ever work at 100% demand (so near the max flow temp) for small periods of time (when starting from cold). Then demand will drop and temperature will also drop. Meaning that if your max flow is quite low, your system will spend most of its time at much lower temps than your max, resulting in inability to heat.

Typically CH system modulate their temperature EITHER using demand OR the external temperature, not both. My advise is that doing both together may not be end up in a very efficient system.

Of course you could take a more light-weight approach: Under normal weather then max flow temp could be 65, but when external temp is near 0 then max flow could be 80.

But again, in general, with opentherm you actually want the max flow temp to be quite high, typically more than 70, so that the system heats up quickly from cold. Then it'll drop by itself - the system shouldn't stay at high temp for a long time, unless the house is very cold.

In my case I am using these settings for a different reason: One part of my system is underflow heating that has a automatic mixer to keep its temperature at 45; meaning that when this is the only part running there's no point in heating the water higher than 45, as it'll mix it down anyway.

[andyblac]

thanks for replying, where do I add this command ?, where is the developer tools UI, sorry still learning HA

[andyblac]

found it, sorry did not see it in the left menu, now...

setting maxChSetpointUpperBound to 700 did not show any change, setting chFlowActiveUpperSetpoint to 700 did chnage the value, but after about 5 seconds it changed back to default 80˚c, and maxChSetpoint had not effect either.

although chFlowActiveUpperSetpoint was at 35, prob why Wiser was not going as low as tado˚ did, I tried setting chFlowActiveUpperSetpoint to 200 and it has worked and is now staying at 20˚c, and boiler is now modulation down ro around 26˚c again with no issues.

it strange why the upper limit can't be changed. any idea ?

[andyblac]

@ikoz any ideas ?, also where do I find the list of parameter variables that can be used ?. i.e. maxChSetpoint where did you get that from ?

[ikoz]

where do I find the list of parameter variables that can be used ?. i.e. maxChSetpoint where did you get that from ?

You'll have to download the wiser integration diagnostics file. It's a json file with lots of info, look at the section under "opentherm".

If setting chFlowActiveUpperSetpoint to 700 changes the max flow temp to 70 but only temporarily, this means that:

1. The command sets the max flow temp that wiser hub uses to 70
2. This setting is overwritten the next time the hub pulls the max flow temp from the boiler
3. The wiser hub does not send the 70 setting to the boiler in order to set it at the boiler side. This makes sense, since chFlowActiveUpperSetpoint is the 'local' active upper setpoint on the hub.

If setting preDefinedRemoteBoilerParameters.maxChSetpointUpperBound to 700 does not change anything even though preDefinedRemoteBoilerParameters.maxChSetpointReadWrite is True, that means that

1. for some reason the hub cannot transfer this setting to the boiler (perhaps a bug or unsupported by wiser)
2. using preDefinedRemoteBoilerParameters.maxChSetpointUpperBound is perhaps not the correct approach - but I dont know what else it could be. Maybe try remoteBoilerParameters.maxChSetpointUpperBound or something else, but I'm just guessing. Possibly this is not yet supported by the wiser hub at all, even though your boiler supports it.

So in your situation the most likely approaches are

1. Set up an automation to keep setting chFlowActiveUpperSetpoint to 700 every time it changes. This is not great, but it should work.
2. Get an opentherm gateway device and put it in place between the hub and the boiler. This is very technical and DIY and would likely be tricky if you're not experienced.
3. Just set the max temperature flow you want on the boiler, if you want that to be constant and not changing. This is probably the easiest way to go - it should be possible in the boiler settings to do this - at least it is on my boiler.

[andyblac]

@ikoz thanks for the reply, as I have a Baxi 836, and it has no setting on the boiler itself, guess my only option is a OTG. As the dials on the boiler for Flow and Water are disabled when in OpenTherm mode.

[ikoz]

@ikoz thanks for the reply, as I have a Baxi 836, and it has no setting on the boiler itself, guess my only option is a OTG. As the dials on the boiler for Flow and Water are disabled when in OpenTherm mode.

The dials are usually the 'setpoint setting', a 'user-facing' option to set the expected setpoint.

This is a different setting to the 'max allowed setpoint' which is what you want, and may be configurable in internal boiler settings somewhere. Depends on the boiler, but on mine this is in installer-only settings.

Look at it this way: Using the dials, the boiler allows you to configure the setpoint between an upper and a lower limit. You want to configure the upper limit, not the dial setting. Opentherm takes charge of the setpoint setting, thats why it's disabled.

[andyblac]

hmm, wonder how i change it then, there nothing in "service mode" either, my boiler has no menus at all.

[ikoz]

hmm, wonder how i change it then, there nothing in "service mode" either, my boiler has no menus at all.

thats unfortunate. In that case the upper limit is probably only configurable using opentherm, but there's a chance that the wiser hub does not support configuring it (I thought it would). In that case the opentherm gateway or the home-assistant automation to reset it continiously are probably your only options. Or using a different opentherm thermostat.

[andyblac]

I came from tado˚ where they had a option in the installer web page for editing the Upper point. Their OpenTherm does seem alot better, but the rest of there stuff is bad (no local schedules etc,) My only option then as you say is either an OTG or move to Weather Compensation. I thought OT would give better efficiency, but atm, Wiser in OT is using more gas than it did using tado.

[andyblac]

btw here is my diag

    "OpenTherm": {
      "chFlowActiveUpperSetpoint": 803,
      "chFlowActiveLowerSetpoint": 200,
      "dhwFlowSetpoint": 550,
      "dhwEnable": true,
      "featureActions": {
        "ModulationOnboarding": true
      },
      "Enabled": true,
      "transmitter": {
        "messagesSentCount": 1802082
      },
      "receiver": {
        "decodingErrorsCount": 42024
      },
      "operatingMode": "OTplus",
      "preDefinedRemoteBoilerParameters": {
        "dhwSetpointTransferEnable": true,
        "maxChSetpointTransferEnable": true,
        "dhwSetpointReadWrite": true,
        "maxChSetpointReadWrite": true,
        "dhwSetpointUpperBound": 600,
        "dhwSetpointLowerBound": 350,
        "dhwSetpoint": 490,
        "maxChSetpoint": 803,
        "maxChSetpointUpperBound": 800,
        "maxChSetpointLowerBound": 200
      },
      "ch1FlowSetpoint": 320,
      "ch1FlowEnable": true,
      "ch2FlowSetpoint": 350,
      "ch2FlowEnable": false,
      "operationalData": {
        "RelativeModulationLevel": 0,
        "MinimumModulationLevel": 27,
        "ChPressureBar": 12,
        "DhwFlowRate": 0,
        "Ch1FlowTemperature": 322,
        "ChReturnTemperature": 316,
        "Dhw1Temperature": 324,
        "MaximumCapacityKw": 30,
        "BoilerExhaustTemperature": 32,
        "SlaveStatus": 2
      },
      "roomTemperature": 187,
      "roomSetpoint": 185,
      "TrackedRoomId": 1
    }

[ikoz]

It's odd, preDefinedRemoteBoilerParameters.maxChSetpointUpperBound set to 700 should do the trick. Did you do it using yaml, without quotes? I found that doing it using the UI adds quotes and doesnt work sometimes. You'll need to have parameter_value: 700 in yaml mode.

As you say if that doesnt work, OTG is probably the only option.

With regards to efficiency, there are two things in play:

1. Minimum modulation: As you see in the settings the minimum modulation of your boiler is 27%. This means that the gas consumption if the load is low is going to be 27% of the total at best. On your 36kw boiler this means that the minimum output is 10kw no matter what. Newer boiler can modulate down further, which means they are much more efficient when load is small, which is the most common case, especially on micro-zoned systems using smart thermostats.
2. Demand percentage: Opentherm works using load compensation; you'll get 100% demand when the house is cold and your setpoint is 1.5 to 2 degrees higher than the room temperature. It may be worthwhile to not let the rooms cool down so much, so that demand is not 100% for a long time. E.g. at night instead of 19C you can set back to 17.5 instead of 17. This will keep heating on for longer but at lower demand % and thus lower output, instead of requiring higher output for longer when the setpoint is 19 but real temp is 15. That said, this is at odds with the 'high minimum modulation' problem described above.

Tado works in a much similar way as wiser, i dont see why it'd be more or less efficient.

Weather compensation works in a different way; instead of ranging the setpoint within a day from high to low depending on the load demand %, it ranges the setpoint much less frequently depending on external temperature. So the setpoint is largely the same for the whole day. On a cold day the setpoint can be 75C for the whole day, while on a warm day it may be 50.

In general though, the exact setpoint temperature does not matter that much for effiency compared to the start-stop cycling and minimum modulation. A boiler with low minimum modulation running at 75C is likely going to be more efficient when the load is small compared to a high-minimum-modulation boiler running at 50C.

[andyblac]

in tado˚, my flow temp rarely got above 45˚c, if outside temps where above 3˚c, wiser seems to go full burn ( for 30 mins, then. throttle back) if demand is 1.5˚c room target temp above current temp regardless of outside temps, maybe tado has AI that sets the upper point depending on weather ?, so it like best of both WC / OT.

[andyblac]

example

maybe it worth trying to set target temp to 17.5˚ at 6am, then 18.0˚c at 7am, then 18.5˚c 8am, instead of 18.5˚c at 7am. so it does not put high demand on OT.

[ikoz]

Yes I now wonder if tado uses weather to lower the upper bound; I have not seen any evidence that wiser does that explicitly.
Weather is used implicitly: On a hot day the room will get up to temperature faster, thus demand will get lowered faster.

As far as i've seen when wiser system demand is 100% then the setpoint is equal to the upper bound, whatever the upper bound is. Then the setpoint is lowered proportionaly with demand %. So assuming upper bound is 80 and lower 20, range is 60, so at e.g. 70% demand wiser will request 62C setpoint. The idea is that demand drops fast (due to high upper setpoint) and then stays low for longer to maintain heat, thus your system should only stay at high temp for a small period of time. Lowering the upper bound means that system will take longer to heat up from cold, thus spending more time at higher temp.

[andyblac]

I was under the impression "low and slow" was the most efficient way these days ?, maybe why tado˚ controls the "Upper" limit?.

[andyblac]

here my daily gas usage this month using Wiser.

here is last month using tado˚ (it was alot cold last month)

[ikoz]

I was under the impression "low and slow" was the most efficient way these days ?, maybe why tado˚ controls the "Upper" limit?.

Low and slow is the most efficient IF the boiler can do it! But your boiler can't cope much as far as I can tell.

The spikes you see in flow temperature in your graph is likely your boiler cycling, which increases cost. The demand is low at these periods, so the requested temperature is 40 to 50C.

The boiler starts, at the lowest modulation possible (27%) and heats the water. But because the lowest modulation is quite high (10kw) it heats it fast. Then return temp increases too (because your load is small) and the boiler turns off, so that water temp does not exceed your (low temp) setpoint. Then it has an anti-cycling delay and starts again, and repeats this loop for a long period. This constant firing-stopping increases consumption actually. In an ideal world, an efficient boiler can maintain a 45C flow temperature without cycling. This is boiler with newer combi boilers that have a wider modulation range (e.g. can modulate down to 5 or 10% of total output, instead of 23-27% which is the norm on older combis). The total output being 'oversized' doesnt help either; you'd only need a 36kw boiler if you want to fill a bath with hot water and at the same time use a shower. In all other cases a 36kw boiler is significantly overize for most UK properties, more so if you actually do microzoning and dont heat the whole house all the time.

Its worth thinking about actually operating at slightly higher temperatures to avoid this, but still stay under the condensing limit (return less than 55C). And also increasing the load somehow to avoid the micro-zoning issue (if one room only calls for heat, considering opening more iTRVs so that there's more output, lowering the return temperature).

[andyblac]

this is why i have asked wiser for a option to disable "Call for heat" so i can let rooms have no control on heat demand but control the TRV opening / closing, atm "passive mode" still has an effect on heating "demand" and thus effects the boiler output, it would be great if this integration could do this, but i dont think it is possible with the hub's api.

[ikoz]

this is why i have asked wiser for a option to disable "Call for heat" so i can let rooms have no control on heat demand but control the TRV opening / closing, atm "passive mode" still has an effect on heating "demand" and thus effects the boiler output, it would be great if this integration could do this, but i dont think it is possible with the hub's api.

If a iTRV is not assigned to any HW relay then it should not affect demand (There's a "none" option). That effectively disables 'call for heat'.
Or if you have a kit3 hub and assign those iTRVs to the second heating relay. Due to lacking wiser opentherm support any demand from devices assigned to CH2 on a kit3 hub is not considered in total demand calculations, at least not currently.

Or you could always use non-smart TRVs and leave them at setting 4 or 5, then they should be mostly open all the time as passive devices. or just put caps on the trv valves and leave some of them fully open.

[andyblac]

yeah, I only have a Kit1, coming from tado this a feature i miss, you could just disable the room's zone controller, so it became a TRV with smart temp valve control. I was hoping this integration would have another option like "passive mode" but to go 1 step further and totally disable "call for heat" and just open / close the TRV valve according the schedule target temps.

[ikoz]

yeah, I only have a Kit1, coming from tado this a feature i miss, you could just disable the room's zone controller, so it became a TRV with smart temp valve control. I was hoping this integration would have another option like "passive mode" but to go 1 step further and totally disable "call for heat" and just open / close the TRV valve according the schedule target temps.

Just try to set those rooms to "none" Channel in the wiser app settings and see what happens. That together with passive mode via the integration should do what you need (passive without affecting total system demand %).

[andyblac]

hmm, looking in the Room setting you can actually set the "Channel type" to None, this would do as tado did, I wonder if this coud be be done in the integration ?, and set a switch to enable / disbale the channel type.

[andyblac]

yeah, now if we could control via schedule this would be fantastic.

[andyblac]

hmmm, setting Office to "none" the room has now disappeared from main page in wiser, app, how do i get it back ?.

edit:
ok, i see in setting -> rooms,

[ikoz]

Yes it doesnt appear in the main page but you can still access it in Settings->Rooms. The integration can still see it too.

The integration definitely can (and does) read which rooms are assigned to which channel, but I dont know if the channel assignment itself can be controlled via the API. That's a good question for @msp1974. This would be useful only if you want to sometimes let the room affect total demand and sometimes not. If you just want a room to never affect demand the you can just set it once in the wiser app.

[andyblac]

yeah, like my Media Room, it only used at night, but during the day you have to walk through it to get to the hall / staris, so it nice to keep at lower temps during the day (only heat if another was calling for heat), but at. night heat the room to target temp.

[andyblac]

let see what @msp1974 says, maybe he can look into it, and if possible, i could create a issue request for it. But, I really appreciate all your help and advise on this today, thanks.

@msp1974 do you think it would be possible to add some code to create an Entity for each room to allow us to control the "Channel Type" (options depending on the number of channels on the HubR i.e. (None, Channel 1, Channel 2, Channel3)), this could then be set via the Schedule Card, like you showed me before for "Passive mode"

[andyblac]

update: when setting Channel to None, the TRV schedule does not work, the TRV valve does not open according the the target temp in the schedule.

And when set to None, the integration can not change temps on iTRV you get the follow error
Failed to call service climate/set_hvac_mode. Unknown error communicating with Wiser Hub 192.168.3.44 for url http://192.168.3.44:80/data/v2/domain/Room/3 with data ('RequestOverride*: {'Type': 'Manual', 'SetPoint': 196)}. Error code is: 400

so it seems, when Type = None, then iTRV is disabled.

[ikoz]

update: when setting Channel to None, the TRV schedule does not work, the TRV valve does not open according the the target temp in the schedule.

And when set to None, the integration can not change temps on iTRV you get the follow error Failed to call service climate/set_hvac_mode. Unknown error communicating with Wiser Hub 192.168.3.44 for url http://192.168.3.44:80/data/v2/domain/Room/3 with data ('RequestOverride*: {'Type': 'Manual', 'SetPoint': 196)}. Error code is: 400

so it seems, when Type = None, then iTRV is disabled.

That's not great, I remembered I had done this in the past (before setting up my hub with opentherm) and it worked. It definitely works when you have a 3channel hub and assign the 'passive' TRVs to channel3 instead of none.