Binary vs variable valve control

[stevefal]

I'm just shopping for TRVs and wading through all the information, reviews, etc. One factor I can't get a handle on is whether any TRVs have variable valve control, (as opposed to all-ON or all-OFF), and if so, whether integrations such as this take advantage of that control for better, more efficient and hysteresis-free control. Mechanical thermostats do this by design, but I know that at least some electronic products do not.

This desire is based on the assumption that smoother demand curves are better for all components involved, not least of which is my central heat-exchanger controller, which has its own intelligence undoubtedly designed assuming slow-moving, variable mechanical thermostats.

But ultimately I'm sure that variable flow control, when optimized, will be more efficient and stable than a "chopping" model in the context of heating.

[AdrianSosic]

Hi @stevefal, I'm currently running into the same question. Have just ordered one TRV to start playing with it because I also couldn't find any useful information anywhere. I'm 100% with you and I think we are talking about separate requirements here:

• The ability to control valve state in the first place (from a hardware perspective)
• Exposing this control to the user
• Actually making use of it via a smooth valve-opening controller (instead of using just bang-bang control)

None of these three aspects are clear to me at the moment, especially not the first two. But it seem the Sonoff TRV I've ordered doesn't expose the control, at least not in its current firmware.

Could you figure something out in the meantime?

[stevefal]

I ended up going Danfoss and I'm happy with the seriousness of their hardware and implementation. I did not buy a Danfoss hub, but control them via ZigBee using home assistant and the standard thermostat widget.

The Danfoss TRVs control the valve continuously using bimetal or whatever mechanism, with the motorized function controlling its setpoint simply as an alternative to the old fashioned handle driven screw mechanism. To me this is exactly how it should work in a battery powered solution. Ideally the motor never moves, unless I have reason to change the setpoint.

I have tried to implement ganging and external sensing for my trickier locations, but the solution I tried (can't remember, this project?), but it was buggy and painful to recover from - requiring re-pairing TRVs.

But as I understand it, external sensing will necessarily involve motor action for its core control loop, so controlling ballistics carefully will be essential to preserving battery life, if a power-reasonable solution is possible at all.

[AdrianSosic]

Thanks for the quick reply. I'll have a look at the TRVs. Can you share a link perhaps?

Regarding the control: I think this is something that would be worth implementing into better thermostat. Have you seen any attempts by someone trying?

[stevefal]

Yeah it was Better Thermostat. I'll take another look sometime, in case it's improved.

Here's Danfoss Ally. Note that they also make/made a Bluetooth-only version of the TRV. I have 18 ZigBee. They are more expensive than the popular alternatives, but they are no joke. Danfoss is a serious provider of heating system components going back decades.

https://www.danfoss.com/en/products/dhs/smart-heating/smart-heating/danfoss-ally/#tab-overview

[AdrianSosic]

Thanks for sharing, I'll have a look if they mention anything on the third point (i.e. how exactly their TRVs control the temperature). If I find something, I'll share 👍🏼

[AdrianSosic]

Ok, nice, it seems it offers a lot of flexibilities to control the behavior:

• changing temperatur set point
• controlling valve state
• provide an explicit external temperature (not just an offset)
• changing the "aggressiveness" of the control algorithm (I guess this adjust the PID parameters or similar)

Given the above, I think the approach proposed by @folfy below would be the perfect minimal effort solution, i.e. using the TRVs internal controller but just providing it with the external sensor data.

[nickeeey]

Take a look at the moes ones for zigbee. These have a readout for the opening.
And connect them over zigbee2mqtt.

https://www.zigbee2mqtt.io/devices/BRT-100-TRV.html

But I don't know how smart better Thermostat is to implement / use this.

[AdrianSosic]

Hm, readout alone will not help 🤔 Do you know of any that also supports setting the value?

[nickeeey]

There is a set and write feature the question is, how smart the trv internal is or if there is a Programm to work with that

[AdrianSosic]

Hm, the documentation for the valve position says It's not possible to read (/get) or write (/set) this value 🤔 Can you point me to where you found the set/write feature?

[folfy]

Based on the the Z2M documentation it's only a reported value (as you quoted), so I'd be pretty sure it's just that, no directly setting it, as on most TRVs.

[folfy]

The Bosch TRV is supposed to support manual position control for example, see on the Z2M device page - pi_heating_demand.

On the other hand it might not even be necessary to implement a new control algorithm for manually controlling the actual position - This TRV supports using an external temperature reading (remote_temperature), so no need for external calibration algorithms like we're doing rn in BT. We could just send the temperature sensor value to the TRV, and it would compensate on it's own.

Unfortunately neither option is currently supported/implemented in BT, and since I don't have such TRV, I also can't do it 😐

[AdrianSosic]

Hey @folfy, your suggested approach with the "no calibration" option seems like a good idea. I'm just doing my thought experiments to understand what would possibly be the best/simplest setup for, say, the Danfoss TRV and the specific options it exposes – the same logic can then hopefully be applied to other TRVs that offer an external sensor input.

Can you help me understand the differences of the modes and tell me if the following is correct:

1. Target Temperature Based: Assumes a "dumb" thermostat that knows nothing about external temperatures. So if there is a temperature difference between the room temperature and what the TRV measures, we can only close that gap by requesting the TRV to target a different virtual temperature. Example: Room temperature has stabilized at 19° while TRV is set to 21° --> we instead tell it to target 21° + (21° - 19°) = 23°
2. Offset Based: The TRV is smart enough that there might be a temperature difference and offers an option to inform it about that difference by providing an "offset". So with the example above, we'd keep the requested 21° but also tell the TRV that if it applied its control for that target temperature, it would be off by 2°. So the TRV can itself correct the logic internally. Positive side effect: the shown temperature on the TRV will be 21° instead of 23°
3. No calibration but with external temperature input: Pretty much like 2. but with the difference that the offset is not computed externally (say by BT/homeassistant) but we directly provide the 19° as external measurement to the TRV and it can internally compute the offset and apply the corresponding logic.

Is that roughly correct? If yes, I'm not even sure how scenarios 2 and 3 would effectively differ in the end. Or do you see any differences? I'm asking because if they are effectively the same, one could even go with the existing offset based approach in BT 🤔 Of course, providing the external temperature directly would be more elegant, but I'm just trying to understand the mechanisms conceptually.

[folfy]

Pretty much yes - case 2. has two issues:

• The TRVs still tend to apply their internal correction on top, which on some TRVs it does almost nothing (good for us, we do the compensation), and others it compensates maybe 80-90% of the error (this is hard to determine and model properly then). How well it rly compensates can vary with the setup and also during operation (e.g. flow temperature of the heating system changing or actually being modulated) -> This double-compensation can and does often lead to strong overcompensation, since BT currently always compensates by almost 100% atm. That's why many in the end enable "overheat protection", or you're gonna overshoot your target like crazy.
• Some TRVs tend to consider this "local calibration" more like a static, set-once and forget value. You can set it any time, but it can cause weird issues like the TRV starting some internal calibration routine, not rly properly responding to inputs or regulating at all for a while.

If the external temperature input entity of the TRV is exposed to HA, you can make a very simple automation, to sync a temperature sensor value on any value change or maybe every 14min (since 30min is the timeout in some TRVs like Bosch) to this TRV entity, so I'd say that's the best workaround for now.

[AdrianSosic]

Thanks a lot for sharing the details 🥇 Given the drawbacks of option 2, I agree that option 3 then really is the best solution, especially when the TRV allows to adjust its internal control loop like the Danfoss does via its "aggressiveness" setting 👍🏼 In fact, I even found a blueprint implementing the suggested solution – we'd only need to bring the same logic into BT then to enable all the other nice features it offers.

Still, I'm not sure if I understood your first point entirely. Can you explain again what you mean with "it applies the correction on top"? Because my understanding was that this is exactly what we would have wished for, i.e. isn't the expected contract with the TRV:
I tell you the offset resulting from your control loop so that you can then fully take care of the necessary countermeasures? That is, I would have expected that the TRV fully takes care of the correction, because there is no more "active" correction from the BT side as it would be the case in "target based mode", where we actually would set a different target temperature. 🤔

[folfy]

Good reference 👍
The blueprint + BT in no_calibration mode will work the same as having the feature integrated into BT pretty much. Well, BT will consider different vendors, e.g. danfoss apparently wants it not more often than every 30min, which would be rly slow in a small room, while Bosch wants it at least every 30min, or it would disregard the external value again...

The issue with the "local_calibration" is, that BT tells the TRV "this is how much your internal temperature sensor is off reality", but most TRVs consider it more like a "this is how much additional error you want me to consider on top of what my internal correct already compensated for", where BT atm only supports compensating all or nothing pretty much.

[AdrianSosic]

I get that part with the "additional" error but when looking at this from a closed-loop control system perspective, this is still what I would expect should happen 🤔

Let's perhaps consider this scenario: My target temperature is at 21°, so I pass 21° as desired setpoint to the TRV. The TRV measures some current temperature X° that differs from the target. What value doesn't matter, but let's say its 18°. And then it measures the delta 3°, applies some logic to that delta (e.g. PID controller or whatever) and sets a valve position as result. This affects the measured value, affects the actuator, affects the measurement, etc... So the story continues until we reach a steady state. If the controller is well-designed, that steady state will be reached as soon as the internally measured temperature equals the setpoint, namely 21°. However, the actual room temperature might still only be 19°. So at every time in this closed-loop process, the actual delta between the setpoint and the room temperature is 1) delta measured by the TRV plus 2) the offset between the TRV measurement and the ground truth.

So in that sense, the real epsilon that the TRV should consider to drive its control loop is the sum of the two values, which means applying the offset "on top" if you will. Or where exactly is the flaw in my logic?

[Credo102]

Note i happen to have these for a Hack project i have going on, so i dont use these for actual heating.

I have a https://www.zigbee2mqtt.io/devices/TRVZB.html
where you can set the "Valve opening degree" and "Valve closing degree (numeric)". not directly weather it is open or closed but say you set it to "heat" you can set it to a specific position. it seems the fort of thing you are looking for but i dont know of any system that uses this in its heating.

I also have
https://www.zigbee2mqtt.io/devices/TS0601_thermostat.html
where you can "force" the valve "open" or "closed". the binary option you mentioned.