Results 1 to 10 of 15

Thread: Raspberry Pi OpenTherm Weather compensation project

Threaded View

Previous Post Previous Post   Next Post Next Post
  1. #1
    Automated Home Legend
    Join Date
    Sep 2014
    Location
    Scotland
    Posts
    1,845

    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 02:27 PM.

Posting Permissions

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