Raspberry Pi based CH and HW control

[TerryE]

Background

I've blogged and posted separately about how I currently control my Underfloor Heating (UFH) and Hot Water (HW) systems using a Raspberry Pi (RPi) computer.  This takes input from some digital thermometers, and a couple of digital flow meters (mainly for flow logging) as well as Met office weather forecast data to calculate timings and to switch the power circuits for my Willis heater, the circulating pump and the supply to my two SunAmp PV units.  The initial design choices in my current implementation were to minimise my own learning curve and to mitigate the development risks for me.   For example, I was already one of main the developers of an ESP firmware platform, so it was just easier for me to use a couple of ESP modules to handle all of the external sensor and relay control.  That being said, this latest COVID-19 outbreak underlines our need to have a practical fallback for Jan. 

 

As it happens, both my son and son-in-law work in the IT industry, and both use RPi based home automation systems in their own homes, so either could in principle take over maintenance of our RPi-based system if necessary.  Even so, on reflection my system setup is more complicated than it needs to be.  In particular neither Rob nor Andrew is familiar with the ESP module firmware and development system, so this subsystem is not something that I could easily hand over.  Given that a single RPi could do the entire computer lot quite comfortably, I am now considering dumping the ESPs entirely and slimming down the software stack on this RPi to that only needed to run the CH and HW control.

 

This topic discusses possible approaches to such an RPi-based control system that meets my needs but once documented could also form the basis of an implementation for others.   What I am proposing is to do this in two passes: first more a review and discussion cycle, where input and comment from the likes of @Jeremy Harris, @PeterW, @Ed Davies, @MikeSharp01, @ProDave and anyone else who feels that they can make suggestions and give feedback; the second will be a set of blog posts where I write the entire system up in detail.

Switching the power circuits

I use Solid State Relays (SSRs) to switch the power circuits for my UFH and HW. All power SSRs pretty much all work the same way, and if you want to know more then Big Clive gives a good tear-down / explanation (here) on YouTube. The CKRD2420 modules that I use can take standard (5V) digital inputs and turn on the power side at the next AC zero-crossing (that is with a delay of up to 10 mSec) if the input goes high. These CKRD2420 modules currently retail at ~ £40 each (compared to the £5 ones that Clive reviewed), but this is the premium for a decent quality approved module from a reputable supplier, and ones that my electrician was willing to sign-of on as part of his 240V installation.

 

The Crydom CKR24 Series Datasheet gives their operation parameters: the input side requires a 4V DC minimum on voltage at up to 12 mA to power the SSR internal opto diode, and power-side TRIACs can drive both resistive loads safely and reliably. This 4V minimum exceeds the general purpose digital outputs of 3.3V based RPis, so some form of voltage / current conditioning is needed to control these SSRs, though the input side of each SSR is already opto-isolated from any transients, it is pretty straightforward to boost each GPIO output to 5V and capable of providing a sustained 15 mA.

 

I prefer to keep my discrete components to a minimum, so a good approach is to use a SN7407N hex buffer driver which can drive up to 6 GPIOs from a single 16-pin DIP package. Note that these buffer outputs are open collector and are driven to 0V when the input GPIO is driven low. The SSR input is connected to the buffer output and 5V, and hence the SSR is on when the GPIO is low. When the input GPIO is high, the buffer output floats and is pulled to 5V using an external 4K7 pull-up resistor on each output, giving a 5V + 5V input to the SSR, that is a 0V difference and switches it off.

 

Note that I previously used an I²C-based port extender instead of a hex buffer driver on my ESP8266 implementation because I had less free GPIOs, however the RPi has a lot of available I/O pins so using these allows me to avoid MCP23008 I²C driver and to simplify the RPi software.

 

One aspect that we do need to careful about is the default state of the relays at power on and before any active software control is initiated. All GPIOs are initiated as inputs, with GPIO 0-8 having pull-ups to 3V3 enabled and GPIO 9-27 pull-downs to 0V enabled. Given that we want any SSRs to default to off at power-on, we need to connect any SN7407N inputs to GPIOs 0-8.

 

The other design issue to note here is that the power TRIACs within the SSR are not 100% efficient; they dump roughly half a percent of the switched power as waste heat, and so will generate roughly 15W of heat per SSR when powering a 3kW circuit. Any enclosure will need to operate within safe temperature tolerances at N × 15W heat output and this will require some form of heat dump design.

Collecting Thermometer Readings

The digital thermometers are DS18B20s. These are accurate and cheap. You can string as many as need on a one-wire bus which only uses a single GPIO. This bus is fully supported by the RPi's Linux kernel drivers, so the implementation is easy.

Hall-Effect Flow Meters

These have a 3-wire connector: GND, 5V VCC and 0 / 5V pulse output. Each output needs to be conditioned to be read safely on a RPi GPIO pin but a a 4.7 KΩ + 10 KΩ resistance divider does this job fine. Note is that the Hall output is again open drain.

 

To Follow

• Physical packaging
• Circuit designs
• Software options: native Python vs NodeRED
• The underlying physics
• Control regimes and options
• Anything else that people want to discuss

Edited February 21, 2021 by TerryE

[MikeSharp01]

@TerryEAll makes perfect sense and great to see. Although I was just playing with a WEMOS this afternoon working with a CO2, Humidity and Temperature sensor block and using the radio and I guess that for remote devices, around the place connected by radio (meshed or otherwise) they will still have a role. 

 

I have a little worry about start up. Although I can see that your approach is reliable it always worries me assuming that that a particular regime will remain part of a design - IE all I/O configured as inputs with a pull up resistor and the default output condition once the processor gets control of the GPIO. In the past I have used a hardware watchdog that disables all control voltages until it receives a signal sequence to open up and if not repeated it shuts down. In this way attaching any scheme behind the controlled devices is no longer a worry as nothing gets power until the correct sequence has been received, and is regularly received by the watchdog.

 

It will be interesting to see your thinking around the native Python / Node Red decision.   

[TerryE]

@MikeSharp01 The thing that I like about the ESP Tasmota or Lua Firmware -- and the Ardiuno sketches for that matter -- is that the H/W libraries just seem to work.  Hooking an ESP or an Ardiuno onto an RPi via the USB serial interface is simple and has no external dependencies.  It just works and I can (and currently do) include simple low level watchdog timers so the system is failsafe: if the RPi dies or disconnects then at worst the house will drop a degree a day or so until this is picked up.  No heating circuits fail on.   The raspberrypi.org documentation on how to use the RPi GPIOs is totally inadequate; you have to mine community resources such as the Adafruit tutorials.

 

I was talking this through with Andrew earlier and in fact he is more comfortable with using the ESPs since he has had some trouble in the past configuring the RPi GPIOs for control use.  He wasn't too bothered about the custom firmware on the ESPs so long I held a couple of ESP modules pre-imaged with the firmware sand held as cold swap spares.

 

In terms of the physical configuration, the ESP setup is neater IMO:  I have I/O front end in an ABS box that is connected to the RPi by a USB connector.  This ABS box has all of the relays, flow meters, and DS18B20s plugging into connectors on it, and yes it also happens to have an ESP module inside.  If I get rid of the ESP with its USB connection then I will need a custom connector containing at least GND + 3.3V + 5V + 7 I/Os connecting to the RPi GPIO header.

 

If I go the ESP route then I can avoid Python altogether and just use NodeRED.  So more thought needed.

Edited March 6, 2020 by TerryE

[MikeSharp01]

7 hours ago, TerryE said:

If I go the ESP route then I can avoid Python altogether and just use NodeRED.  So more thought needed.

I guess the 'systems' approach is the best, just black box everything and connect up the boxes, being careful to ensure inputs are compatible with prior outputs etc. Then you can keep working copies of blocks available for swapping out. I like NodeRed and I do a session on it in our (my) TEC supported Engineering module because it allows you to travel a very long way quickly but it does encourage some fudging at the edges when you need to work around gaps and sometimes the surface gets a bit lumpy because the blocks are square when they need to be a smooth curve - like LEGO really. 

 

 

[TerryE]

It is just under a year since this last post.  The main change that I have made to my system is to add an additional RPi 4 running a standard Home Assistant install with the InfluxDB, Grafana, NodeRED, Mosquitto broker, and Zigbee2mqtt add-ons.  This is a pretty standard Home Automation use-case.

 

The RPi which runs the CH + DHW control has been stripped right back to a base Rasbian + MySQL + NodeRED.  This is integrated into the HA system using the main MQTT broker and a bunch of topics, so the user interface is done entirely through the HA.

 

Quite honestly my current RPi3 + 2 × ESPs is overkill as the entire CH + DHW system would fit happily on a single PiZero, though I would still need some custom glue to drive the SSRs.

 

If I were proposing this setup to anyone else, I would also suggest dropping the SSRs and switch to a standard passive distribution box (the sort that my electrician would understand and comfortable wire), but with separate SonOff power relays reflashed with the Tasmota firmware, which would enable the HA system to control these directly.  The SonOff power relays use a HF152F-T relay which is rated to 16A and can switch the 2.88 kW Willis resistive load for long durations.  IMO, this circuit is a more robust design than the corresponding SumAmp control circuit, for example.

 

The great advantage of this sort of approach is its cheapness and robustness.  The major downside is that the homeowner needs some level of IT literacy and minimal computing skills to configure and to use it.

Edited February 24, 2021 by TerryE