Condensation gas boilers are considerably more efficient when they run at a lower exhaust temperature. This makes ON/OFF thermostats a bad choice, because they tend to run for shorter periods of time at maximum power output.
My boiler supports power modulation through the OpenTherm protocol and since I have already converted my old ON/OFF thermostat to what's basically a pretty interface, it seems that using power modulation to save gas is the next logical step.
An OpenTherm interface needs to be made, and a PID controller would need to be implemented in software to find a good balance between comfort (fast temperature reach + no abrupt swings) and economy (lowest possible gas combustion exhaust temperature).
Why yet another OpenTherm interface?
Great open projects like the great OTGW in which this is largely based, are meant as gateways/mitm, intercepting messages between a real thermostat and a boiler.
OTGW has a "standalone" mode which is probably useful for what I am trying to do, but the PIC code is written in assembly. It's been 20 years since I wrote a single line of that, and that alone is a good reason no to get into it. I think OTGW is great but not if you want to change anything on how it operates.
This will be an OpenTherm/+ master-only device that will continuously cycle through a fixed sequence of messages, to achieve a clear seat of features/goals:
- Query and report relevant status and sensor data (pressures, output, temperatures).
- Receive from the serial, and continuously apply to the boiler:
- whether to enable the central heating or not.
- the central heating set-point.
- the maximum relative modulation the boiler should use.
- A simple fail-safe mechanism that turns the boiler off when there is no serial commands in a long while.
That's it. It will sit there looping and doing that, forever.
The complexity of controlling the set point values in a sensible way (PID, door/window opens,outside temperature compensation, etc.) will be done on a more suitable platform and not in the MCU.