Presentation

rWCHC is a project aimed at implementing a versatile weather-compensated central heating controller. The goal is to provide smart, accurate and optimal temperature control based on outdoor temperature variations, building structure and occupant habits, in order to maximize comfort and reduce power usage (minimize both the impact on the environment and the energy bill). The system is designed to be scalable and remote operable (via internet connection).

This project is composed of two parts: a custom-designed hardware module to perform the actual power control on heating appliances, and a software module which is meant to run on a Raspberry Pi host to perform all computations and enhanced logic control. The rPi host also provides power to the hardware module which doesn’t need an external power supply.

This project stemmed from my need for a reliable and highly configurable controller after having had a bad experience with a brand-name device.

This webpage is work in progress

Licensing

This project falls under a different licensing scheme than the rest of this website. Please read this section carefully.

  • The hardware part (incl. firmware) of this project is currently all rights reserved until I figure out a proper license.
  • The software part (excl. firmware) is licensed under the GPLv2.

Disclaimer

The information and methods described herein are provided “AS-IS” WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED. Use the concepts, examples and information at your own risk. There may be errors and inaccuracies, that could be damaging to your devices. Proceed with caution, and although it is highly unlikely that accidents will happen because of following advice or procedures described in this document, the author does not take any responsibility for any damage claimed to be caused by doing so.

Design goals

My design goals are simple. The system should be:

  • Safe
  • Reliable
  • Versatile
  • Affordable
  • KISS design

This is reflected in the list of features.

Features

The system is geared toward a “set and forget” approach, only requiring some attention at initial setup time.

The hardware features are:

  • Up to 15 freely assignable RTD 2-wire sensor inputs
  • Up to 12 freely assignable Triac output channels, single phase with a maximum current budget of 5A total (fuse protected)
  • Up to 2 freely assignable Relay output channels, potential free (rated 5A/250VAC max each)
  • 1 2x16 alphanumeric LCD display with backlight control, fully R/W addressable
  • 2 freely assignable tactile switches
  • 1 piezo buzzer for audible feedback (switch click and alarm)
  • 1 raspberrypi-compatible header connector for interfacing with an rPi
  • Automatic failsafe fallback in case of disconnection from the host controlling software
  • Host powered (no external power supply)

Presently, the following features are implemented in software:

  • Weather-compensated operation, with virtually unlimited number of building models:
    • Building temperature behavior modelling via inertia time constant
  • Virtually unlimited number of heating circuits with any of the following features:
    • Per-circuit, independent target ambient temperature
    • Per-circuit building model assignment
    • Direct heating circuits
    • Mixed heating circuits, with 3-way mixing valve:
      • Support for multiple types of valve control algorithms: bang-bang, successive approximations, PI controller
      • Support for temperature deadzone in all algorithms
      • Support for actuator deadband in all algorithms
    • Support for multiple types of heating curves (currently only linear and bilinear approximations are implemented)
    • Support for ambient temperature modelisation in the absence of an ambient sensor
    • Support for accelerated cooldown and boost warmup transitions
    • Support for water temperature rate of rise control
    • Support for optional circuit ambient temperature sensor
    • Support for optional circuit water return temperature sensor
    • Support for automatic circuit turn-off based on outdoor temperature evolution
    • Support for timed cooldown at turn-off
    • Support for min/max limits on circuit water temperature
  • Virtually unlimited number of DHWT (Domestic Hot Water Tanks) with any of the following features:
    • Support for boiler-integrated tanks
    • Support for automatic switch-over to (optional) integrated electric-heating
    • Support for single and dual sensor operation (top/bottom) with adaptive histeresis strategies
    • Support for timed feedpump cooldown at untrip with temperature discharge protection
    • Support for 5 charge priority models (no priority, parallel or absolute; with heat request selection)
    • Support for forced manual charge
    • Support for charge duration cap
    • Support for DHW circulator pump
  • Type-agnostic heat source support (currently only boiler type implemented) with any of the following features:
    • Support for consumer shift (e.g. to accelerate warmup after a cold start or to evacuate excess heat)
    • Support for consumer delayed turn off (to prevent heatsource overheating after last run)
    • Boiler type heat source implements:
      • Automatic frost protection in all operation modes
      • Support for minimum burner on time to reduce wear
      • Support for adaptative trip/untrip histeresis with low and high temperature limits
      • Support for automatic boiler “sleeping” turn-off based on last heat request time
      • Support for several automatic turn-off strategies
  • Support for multiple RTD temperature sensors variants (currently Pt1000 and Ni1000)
  • Support for automatic summer switch-over based on outdoor temperature evolution, with summer maintenance of pumps and valves
  • Support for time accounting of all operations (i.e. “on/off since, total on/off time, number of power cycles”, etc)
  • Support for pump cool down timeout
  • Support for several global operation modes (full off, comfort, eco, frost-free, manual…)
  • Support for limited user-hardware interaction:
    • Global operation mode change via switch
    • Display of individual sensor temperature
  • Foundation of a simple D-Bus interface for remote control
  • Foundation of a simple permanent storage interface for state persistence and data logging

Provisions in the software have been made to later support the following additional features:

  • Support for individual (per circuit/DHWT/heat source) operation mode
  • Circuits:
    • Support for transition timing optimisation (anticipated cooldown, boost warmup timing…)
    • Support for zone valves
  • DHWT:
    • Support for periodic anti-legionella high heat charge
    • Support for solar heating
    • Support for DHWT cascade, with priority
  • Heat sources:
    • Support for heat source water return temp limitation
    • Support for virtually unlimited number of heat source, with cascading
    • Support for other types of heat sources (e.g. heat pumps or heat exchangers for district heating…)
    • Support for boilers with 2-stage burners
  • Support for multiple instances (chaining/cascading)
  • Support for full remote control
  • Support for smart scheduling
  • Support for data logging and stats
  • Support for HomeKit

In the longer term the system would make use of presence indicators (e.g. sensors) to self-learn the occupants habits.

The software is pure C, and is currently not formally released as it’s under rapid development.

Hardware

To be completed

The hardware implementation reflects several constraints:

  • Safety: the hardware must be safe to use and have safe failure modes
  • Power budget: the hardware must be entirely powered from the rPi’s power rails, which have a limited capacity
  • Power usage: the hardware must consume as little energy as possible, in both the logic section and the power control section
  • Robustness: the hardware must cope with interferences (including high energy transients), in particular coming from the mains
  • Flexibility: the hardware must be adaptable to a variety of installation configurations
  • Form factor: the hardware must be as small as possible to reduce production costs and associated costs (casing)

For the current prototype, the choice of THT with a limited number of SMT devices has been made for greater ease of assembly. The current device uses common components (which are easy and cheap to procure), with the exceptions of a specific high performance analog switch, a level-shifter IC for interfacing with the rPi’s GPIOs, and a PIC microcontroller.

Layout

Here’s a compact two-sided through-hole prototype layout that fits on 150 x 100 mm PCB.

board

Software

rwchcd linux daemon

A daemon is being developped for controlling the device. It is entirely written in C. Most of the computation is done in integer arithmetics to reduce the load on the Raspberry Pi.

Daemon files

The daemon is currently unreleased but available from the following GIT repository. The code is abundantly commented. I would welcome anyone willing to help me in developping this software :)

The daemon documentation (automatically generated) is available here.

Picture of a completed unit

This prototype unit has 4 (“snubberless”) Triac channels and 2 Relay channels implemented and is fitted in a custom-made clear acrylic case.

front
back