Page 1 of 2 12 LastLast
Results 1 to 10 of 19

Thread: Raspberry Pi OpenTherm Weather compensation project

  1. #1
    Automated Home Legend
    Join Date
    Sep 2014
    Location
    Scotland
    Posts
    2,361

    Default Raspberry Pi OpenTherm Weather compensation project

    Those of you who follow my long rambling posts know I occasionally like to go on about the theoretical "ideal" world of combining OpenTherm control from Evohome with Weather compensation based on outside temperature measurement.

    Many of you are also probably aware that very few (if any ?) boilers actually allow the simultaneous use of weather compensation and OpenTherm - most just disable the weather compensation module/feature if under OpenTherm control, and even if they didn't they would probably just "truncate" the maximum flow temperature requested by OpenTherm rather than "scaling" the requested temperature, which I believe would give better control. And of course many Boilers don't even allow you to set the maximum flow temperature when controlled via Evohome OpenTherm, making even OpenTherm itself unusable.

    I also have an ancient boiler under TPI control and am not likely to have an OpenTherm boiler any time soon, so the limitations of both no weather compensation and TPI frustrate me somewhat. For example temperature control in times of very low demand (night time bedroom radiators for example) is poor because TPI has such a long response lag compared to OpenTherm. If an HR92 calls for a bit more heat with OpenTherm the boiler is immediately commanded to a higher flow temperature and the room starts to warm up. With TPI the heat output of the boiler is only averaged over a 10 minute period so response is very, very slow when going from one small heat demand to another slightly different small demand.

    So I hatched a crazy and somewhat ambitious plan to solve all of these problems at once without changing boiler - build my own Raspberry Pi based OpenTherm slave and weather compensation system! It's quite a while since I've done a hardware/software project start to finish so even though it's completely over the top I thought it would make a fun project and a great test bed to test some of my theories about weather compensation and so on...

    So here is the basic outline:

    A Raspberry Pi 2 running Raspbian Stretch is the heart of the system. Attached to the Pi is the following hardware:

    1) A 5" touch screen for user interface, to be mounted on the kitchen wall where my BDR91 currently is. I haven't decided exactly which screen yet but probably something like this 800x480 HDMI screen:

    https://www.modmypi.com/raspberry-pi...clear-case-usb

    Using HDMI instead of the DSI interface on the Pi makes it easier to have the screen and the Pi separated somewhat - as the Pi will have some USB devices connected sticking out the sides I may want to hide it away in the boiler closet and just run HDMI/USB/power to the screen through the existing hole in the wall the BDR91 currently uses.

    2) An OpenTherm interface that can do the heavy lifting of implementing the OpenTherm protocol for me and just allow me to poll it for information. I haven't got very far into researching this part of the project yet, this may be a candidate:

    https://www.nodo-shop.nl/en/openther...m-gateway.html

    One thing I'm unsure about is this interface is intended to be a "passthrough" device to be inserted between the thermostat (master) and boiler, (slave) only modifying some parameters on the fly, however I would require the interface (or software in the Pi) to actually implement a full generic OpenTherm slave for the Honeywell OpenTherm bridge to talk to, and then I pull data from the interface such as requested flow temperature from the Evohome and use this information in my software running on the Pi. As it's a programmable PIC it seems like it's at least theoretically possible.

    3) A wireless outdoor temperature sensor. Last Christmas Santa bought me one of these:

    https://www.bresser.de/en/Weather-Ti...er-5-in-1.html

    As it's mounted on a longish pole on top of my garage and has a proper sun guard for the temperature sensor it does a very good job of getting true outside temperature and is also very fast to respond to changing conditions. The unit transmits to the receiver/display unit on 868.3Mhz. I wondered if it would be possible to somehow receive and decode that signal and it turns out it's not actually that difficult!

    First you need an 868Mhz receiver or an SDR (software defined radio) that can tune to that frequency range. Completely by accident I discovered that an RTL based USB DVB tuner that I have kicking around not being used is capable of being turned into a full software defined radio that is suitable for the task. The one I have is similar to this one, although mine is black and doesn't actually say SDR anywhere on it:

    https://www.linuxtv.org/wiki/index.php/Astrometa_DVB-T2

    The driver is already present in Raspbian and you only need to install the rtl-sdr package to use it as an SDR.

    The next piece of the puzzle is some software to operate the SDR and attempt to decode the signal from the weather station. A little bit of digging turned up an excellent project called rtl_433 which despite the name also supports 868Mhz devices:

    https://github.com/merbanan/rtl_433

    This works with rtl-sdr and has a long laundry list of supported outdoor sensors including my Bresser unit. In fact it also supports an older weather station I have as well! If you already have an outdoor wireless weather station sensor chances are this software will support it. I set this up running as a systemd service and I configured it to give json formatted output that looks like this:

    Code:
    {"time" : "2019-04-25 12:45:06", "model" : "Bresser-5in1", "id" : 160, "temperature_C" : 15.000, "humidity" : 51, "wind_gust" : 1.400, "wind_speed" : 2.100, "wind_dir_deg" : 292.500, "rain_mm" : 62.400, "mic" : "CHECKSUM", "mod" : "FSK", "freq1" : 868.399, "freq2" : 868.276, "rssi" : -12.144, "snr" : 12.757, "noise" : -24.901}
    The sensor provides other information like wind speed and direction, humidity etc but I won't be using those. I'm currently running this on my existing munin evohome graphing system in place of the weather.com weather report temperature as a test and it's working great, and unlike the report which only changes every few hours and is to the nearest 1C, my own sensor updates about every 30 seconds and has a 0.1C resolution...

    4) One wire protocol temperature sensors - one for the flow pipe on the boiler immediately where it comes out of the heat exchanger and one on the return line. While I technically only need the flow temperature it's so easy to add additional one wire sensors, so why not measure the return as well for more information ? I currently use an external digital flow temperature thermostat on my boiler with the sensor strapped to the flow pipe (and built in analog stat turned right up) so i would just add another sensor here.

    5) Two GPIO controlled mains relays - one to replace the BDR91 to actually switch the boiler on and off, and a second "fail-safe" relay to switch the system back to the regular external flow thermostat that is there now in the case that the Pi crashes, won't boot etc. I wouldn't want a software bug or crash to cause me to have no heating when I'm away from the house....

    Pretty easy to do that really - you configure the fail-safe relay so that the default power state of the GPIO pin controlling it is that the relay is off - in that off mode the original digital thermostat is switched into circuit and controls the boiler. (As I would no longer have a boiler control BDR91 I would have to use the switches on the heating and hot water zone valves in this fail safe mode)

    In the systemd service that starts the core logic that switches the boiler control relay you add an ExecStartPost that switches on the GPIO line for the fail-safe relay, switching control over to the Raspberry Pi. If the service crashes an ExecStopPost can switch the GPIO line back to put it back into failsafe mode again. So during development stopping the service would be enough to put the heating back into traditional control.

    To allow for the situation where the device hard freezes I would enable the hardware watchdog in the Pi - after a forced reset the GPIO line will go back to default and turn off the fail-safe relay again. So the system should be 99% failsafe in the event that the Pi or software running on it malfunctions.
    Last edited by DBMandrake; 25th April 2019 at 01:27 PM.

  2. #2
    Automated Home Legend
    Join Date
    Sep 2014
    Location
    Scotland
    Posts
    2,361

    Default

    On the software side I plan a simple, plain "evohome style" user interface written in Python probably using guizero/tkinter. Nothing fancy just big finger sized buttons with a simple click interface. (No multi-touch etc) This lets it be used on cheaper single touch resistive touch screens which most 5" screens are.

    Information on screen will be things like outside temperature, Evohome requested flow temperature, weather compensated "adjusted" flow temperature, actual flow temperature and return temperature, boiler relay status and so on. There would be a settings screen where the slope and cutoff of the weather compensation can be adjusted to suit the house and boiler, and also a "fall-back" flow temperature that it will use if it loses contact with the outdoor sensor for a long time.

    A temporary "clothes drying" override could be added too, as could a separate flow temperature for hot water reheat. Flow temperature on/off differential would be adjustable.

    The core logic would also probably be in Python and would largely just poll information from the OpenTherm interface to find out what the Evohome wants, modify those requests based on the outdoor temperature sensor and weather compensation configuration, and then switch the boiler relay on and off to meet that target flow temperature.

    Is a project like this overkill ? Hell yes! Fun though, and I already have the Raspbery Pi 2, the DVB tuner and the Bresser outdoor weather station, which is most of the total expense.

    I could envisage a similar version of the project designed to work with an actual OpenTherm boiler - in that case you no longer need the boiler control relay or the 1 wire sensors. The Opentherm interface would be pass through but modify the requested temperatures based on outdoor temperatures etc.

    I don't know if this project will actually see fruition or not - at the moment I'm researching individual chunks of it without fully committing due to the cost of some elements required, such as the Honeywell OpenTherm bridge. The outdoor temperature sensing is already completed, the UI prototyping in guizero is part done, but the main unknown is how best to implement the OpenTherm slave, and I suspect the OpenTherm side will be the major stumbling block.

    I know a few of you are pretty knowledgeable on embedded devices so any feedback of course is appreciated especially on the OpenTherm protocol and implementations of it on the Raspberry Pi or interfaces that can connect to a Raspberry Pi.
    Last edited by DBMandrake; 25th April 2019 at 01:39 PM.

  3. #3
    Automated Home Legend top brake's Avatar
    Join Date
    Feb 2015
    Location
    the edge of the cloud
    Posts
    837

    Default

    weather compensation and OpenTherm load compensation are not mutually exclusive bedfellows

    if you have an OpenTherm boiler and setup the heatcurve on the boiler UI to match the boiler to the application then connect an OpenTherm room controller they will work in harmony together.

    The OpenTherm room controller will communicate with the boiler 2 way - the boiler will share the outside temperature over the OT bus along with boiler operational parameters.
    The OpenTherm room controller will consider all this data as part of its adaptive control algorithm and arrive at a modulation and flow temperature command.
    Some OpenTherm room controls allow you to set the heatcurve at the installer settings too, for example Honeywell Home T4M
    I work for Resideo, posts are personal and my own views.

  4. #4
    Automated Home Legend
    Join Date
    Sep 2014
    Location
    Scotland
    Posts
    2,361

    Default

    Quote Originally Posted by top brake View Post
    weather compensation and OpenTherm load compensation are not mutually exclusive bedfellows

    if you have an OpenTherm boiler and setup the heatcurve on the boiler UI to match the boiler to the application then connect an OpenTherm room controller they will work in harmony together.
    That's the theory, but there's lots of reports on here of that not working, with many boilers simply disabling/ignoring the input from the outdoor temperature sensor when connected to an OpenTherm master like Evohome.
    The OpenTherm room controller will communicate with the boiler 2 way - the boiler will share the outside temperature over the OT bus along with boiler operational parameters.
    The OpenTherm room controller will consider all this data as part of its adaptive control algorithm and arrive at a modulation and flow temperature command.
    Some OpenTherm room controls allow you to set the heatcurve at the installer settings too, for example Honeywell Home T4M
    Does any of this apply specifically to Evohome with the OpenTherm bridge though ?

    If a boiler with an outside temperature sensor passes the outside temperature reading back to the Evohome via OpenTherm, will it actually make use of that information ?

    We've been previously told that Evohome does not make any use of outside temperature measurements in its control algorithm.

    This is all academic for me of course as I don't have an OpenTherm boiler, the main point of my project is to emulate an OpenTherm boiler and at the same time give additional flexible control within that implementation that is not usually possible with commercial implementations. Any algorithm I can think of I can code up in Python and add to the core logic or user interface in a very short time.
    Last edited by DBMandrake; 25th April 2019 at 01:35 PM.

  5. #5
    Automated Home Legend top brake's Avatar
    Join Date
    Feb 2015
    Location
    the edge of the cloud
    Posts
    837

    Default

    Quote Originally Posted by DBMandrake View Post
    That's the theory, but there's lots of reports on here of that not working, with many boilers simply disabling/ignoring the input from the outdoor temperature sensor when connected to an OpenTherm master like Evohome.

    Does any of this apply specifically to Evohome with the OpenTherm bridge though ?

    If a boiler with an outside temperature sensor passes the outside temperature reading back to the Evohome via OpenTherm, will it actually make use of that information ?

    We've been previously told that Evohome does not make any use of outside temperature measurements in its control algorithm.

    This is all academic for me of course as I don't have an OpenTherm boiler, the main point of my project is to emulate an OpenTherm boiler and at the same time give additional flexible control within that implementation that is not usually possible with commercial implementations. Any algorithm I can think of I can code up in Python and add to the core logic or user interface in a very short time.
    i can only attempt to explain what is possible with the OpenTherm protocol; what will and will not happen with specific appliances and controllers is a seperate matter

    if an evohome is not connected to an appliance using OT it cannot use OTC data as part of its control algorithm (for example internet weather data)
    I work for Resideo, posts are personal and my own views.

  6. #6
    Automated Home Legend
    Join Date
    Sep 2014
    Location
    Scotland
    Posts
    2,361

    Default

    Quote Originally Posted by top brake View Post
    i can only attempt to explain what is possible with the OpenTherm protocol; what will and will not happen with specific appliances and controllers is a seperate matter

    if an evohome is not connected to an appliance using OT it cannot use OTC data as part of its control algorithm (for example internet weather data)
    Yes, I'm aware that the OpenTherm protocol allows a boiler to send an outdoor temperature reading back to the thermostat, however the question was whether Evohome in particular will do anything with that outdoor temperature reading if it is sent to it. Previous advice given on here by yourself or Rameses is that Evohome does not use outdoor temperatures in its control algorithm. If this has changed I'm sure we'd all like to know.

  7. #7
    Automated Home Legend top brake's Avatar
    Join Date
    Feb 2015
    Location
    the edge of the cloud
    Posts
    837

    Default

    Quote Originally Posted by DBMandrake View Post
    Yes, I'm aware that the OpenTherm protocol allows a boiler to send an outdoor temperature reading back to the thermostat, however the question was whether Evohome in particular will do anything with that outdoor temperature reading if it is sent to it. Previous advice given on here by yourself or Rameses is that Evohome does not use outdoor temperatures in its control algorithm. If this has changed I'm sure we'd all like to know.
    with evohome specifically - watch this space
    I work for Resideo, posts are personal and my own views.

  8. #8
    Automated Home Sr Member
    Join Date
    Apr 2017
    Posts
    98

    Default

    There's no problem at all with having OpenTherm and weather compensation operating together. Our Intergas boiler has both these features and they can be used together or separately at will.

    If only weather compensation is used, then the boiler's own internal compensation curve is employed to control flame size, in line with the current outside temperature. If however an OpenTherm controller is also connected, then the outside temperature data is sent to the controller and the boiler's (adjustable) internal curve is ignored in favour of the one incorporated into the controller - which in our case is a Remeha iSense and has a fully configurable compensation curve.

    In short, any decent modern boiler will have both, as should any full-featured controller.

  9. #9
    Automated Home Legend
    Join Date
    Sep 2014
    Location
    Scotland
    Posts
    2,361

    Default

    Quote Originally Posted by top brake View Post
    with evohome specifically - watch this space
    Quote Originally Posted by blowlamp View Post
    If however an OpenTherm controller is also connected, then the outside temperature data is sent to the controller and the boiler's (adjustable) internal curve is ignored in favour of the one incorporated into the controller - which in our case is a Remeha iSense and has a fully configurable compensation curve.

    In short, any decent modern boiler will have both, as should any full-featured controller.
    This is exactly the problem though - Evohome doesn't currently support this. If you connect an OpenTherm boiler with weather compensation to an Evohome system, weather compensation is disabled and ignored. Evohome's current OpenTherm implementation leaves a lot to be desired.

    Anyway I don't want to get too bogged down in the weeds here or have the thread derailed too much as this thread is about a project to emulate an OpenTherm boiler in a system that only has a regular non-OpenTherm boiler, and in the process provide a lot of additional flexibility including weather compensation. It's not really about how Evohome behaves with an actual OpenTherm boiler today, nor how it might behave with a theoretical future firmware update.

    In my Opentherm slave emulation I could choose to either pass the outside temperature reading to the OpenTherm thermostat and see what it does with it (currently nothing in the case of Evohome) or deliberately not pass the outside temperature via Opentherm, and perform the weather compensation myself - which is my preferred option as it is then fully under my control. The system would be flexible enough to support either approach and switching between them to compare how they behave.

    The point of it is to be a test bed with flexible instrumentation and programmable behaviour as much as anything else.
    Last edited by DBMandrake; 26th April 2019 at 07:00 AM.

  10. #10
    Automated Home Legend paulockenden's Avatar
    Join Date
    Apr 2015
    Location
    South Coast
    Posts
    1,719

    Default

    You could base your project on Cyril's daughterboard and an Orange Pi Zero.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •