Heating in winter in The Netherlands is mostly done with central heating (CH) units that burn natural gas. The central government started last year a campaign to prompt citizens to switch to some form of renewable energy to warm their homes. Natural gas will be phased out ultimately 2050. In that year homes are expected to be kept warm through heat pumps or via district heating systems. The former are low-temperature systems by design while because of capacity expectations the latter will deliver to homes mostly medium-temperature heat. People still living in poorly insulated homes consequently may suffer from heat poverty. Quite apart from all sorts of projections to the future it is very attractive today for economic reasons for private home owners to commit to home insulation.
Figure 1: Flow diagram of the designed setup.
In a well insulated home the temperature of the water coming from the CH boiler doesn’t have to be that high. Too high water temperatures cause transport heat loss and therefore efficiency loss, i.e., higher costs. In other words: investments in home insulation should be followed up by moderation of the operating CH temperatures. This will extra reduce costs and at the same time benefit the environment. Knowing what water temperatures are across the CH system during the heating season can be helpful in a later stage in the energy transition. The decision whether or not to simply replace an existing gas-fired boiler or to install a low-temperature electric heat pump will among others depend on the heat demand which translates into (maximum) system operating temperatures.
So far so good! In order to collect data how well my CH system performs throughout the heating season I constructed a logging system with two Dallas DS18B20 temperature sensors, one attached to the pipe that transports water from the CH boiler throughout the home (‘CH-supply’) and one on the return pipe (CH-return). The sensors are connected to a ESP8266 based microcontroller board (Lolin NodeMCU). The NodeMCU reports to a Thingspeak server on the internet that stores the data in a log file (schematic, figure 1). Two 4-digit 7-segment LED displays connected to the microcontroller board show the actual data provided by the sensors.
2 x Dallas DS18B20 temperature probe
1 x Lolin NodeMCU ESP8266 microcontroller board
2 x TM1637 4-digit 7-segment led display
1 x 4.7 kΩ resistor
1 x 6.8 kΩ resistor
three-stranded wire (22AWG)
1x ESP8266 base
box and wire, micro usb cable
Temperature sensors: Dallas DS18B20
The DS18B20 is a versatile, accurate (accuracy ± 0.5oC), advanced temperature sensor that works with one-wire technology. The sensor is Arduino (5V) and ESP8266 (3.3V) compatible. One big advantage of this device is that it can be mounted amazingly far away from the microprocessor board, up to a distance of at least 20 meters. Other sensors, e.g., those working under the I2C protocol, must be mounted quite close to the microcontroller board. This distance feature is vital here since the sensors are mounted on pipes that are some distance away from the NodeMCU and the accompanying permanent power source. Actually, the 5V DC power supply (via the micro usb connector) of the NodeMCU is drawn from the wifi router box, which saves a 230V AC power outlet and a power adapter. The distance between the temperature sensors and the microcontroller board (5 meters) is bridged with a three-strand cable: power, data and GND. On both ends of the data wire a pull up resistor is mounted: on the DS18B20 end a 6.8 kΩ resistor, and on the NodeMCU end a 4.7 kΩ resistor. The 6.8 kΩ was determined empirically.
The DS18B20 and its wiring with an Arduino is discussed in more detail in a previous paper*
The DS18B20 sensors (labeled sensor_00 and sensor_01) were taped to the CH pipes: sensor_00 to the supply pipe and sensor_01 to the return pipe. Next a cuff of foam pipe insulation was placed over the sensor locations. Wires from the sensors to the NodeMCU were installed neatly out of view.
Microcontroller board: NodeMCU ESP8266
In a previous paper** I discuss the construction of an ESP8288 NodeMCU monitoring station reporting and logging the temperature of only one location in the CH system. The sensor in that project is also a DS18B20; its recorded temperature is displayed on a 4-digit, 7-segment TM1637 led display. That design has been in continuous operation from its assembly. The current design, being an expansion of that original design, consists of reporting temperatures measured at two locations. This requires a second DS18B20. I wanted also a second display to have the opportunity of direct visual inspection. An alternative could be to display the two measured temperatures alternating on the existing TM1637 display, to use an OLED display, or use a ‘luxury’ 320×480 pixel TFT display that has sufficient space to show multiple meters***. A final choice could be to rely completely on the Internet. TFT screens are relatively power hungry while in my experience OLED displays have a limited life time. Because most logging is done out of view behind the doors of a cabinet and because logging is a 24/7 activity the most elegant solution would be to add a 7-segment TM1637 led display next to the existing one. The challenge was to find out whether a second TM1637 display can be connected to the NodeMCU (and be programmed to work).
Figure 2. Components and wiring of the monitoring/logging station: DS18B20 sensors (sensor_00 and sensor_01), Lolin NodeMCU ESP8266 microcontroller board, and two 4-digit 7-segment led displays showing actual temperatures registered by the probes.
The NodeMCU ESP8266 microcontroller board is an economic and robust platform that easily connects via wifi with the internet. Because of its good compatibility with Arduino type peripheral equipment and because it can be programmed through the Arduino IDE, existing sensors can be used and existing sketches adapted to the specific monitoring. I had an additional base board for the NodeMCU available because these allow easy replacement of the microcontroller board if necessary. The assembly of microcontroller board / base board was placed inside the same plastic container of the previous project**, with the displays mounted on the lid of the box (figure 3). Openings in the box allow wires getting in and out.
Thingspeak and sketch
ThingSpeak is a service offered on the internet by MathWorks. According to its developers: “ThingSpeak is an open source IOT application with an API (application programming interface). ThingSpeak encompasses the creation of sensor logging applications, location tracking applications, and a social network of things with status updates” (source: wikipedia – search term <ThingSpeak>).
In order to use ThingSpeak, one has to register to obtain an API key / password combination. Next, channels can be created and configured at www.thingspeak.com to receive and display data. In this example, data are exported from the NodeMCU board to a channel at ThingSpeak named ‘DS18B20’.
The instructions in the sketch consist of three groups:
1. Connect via wifi to the local area network (SSID, password),
2. Identify yourself to ThingSpeak (API ID),
3. Cycle through the routine of acquiring and displaying temperature data. In the present project data is relayed every five minutes via wifi to the router and forwarded to a server run by ThingSpeak. Here the data is stored for later consultation, display and retrieval. Data files can be downloaded in csv format and imported in a spreadsheet.
Two 4-digit seven-segment led displays connected to one Arduino
With some types of display it can be quite challenging to connect multiple units to one Arduino. The TM1637 is an exception. The library, <TM1637Display.h> offers the option to create multiple instances of ‘a display’. In the variable definition section of the sketch the following expressions declare both displays (displays labeled here ‘A’ and ‘B’):
// TM1637 section
// 7-seg display A connection pins – display A is CH supply
#define CLK_A 13 // GREEN wire – D7 – equivalent to Arduino pin 13
#define DIO_A 12 // YELLOW wire – D6 – equivalent to Arduino pin 12
// 7-seg display B connection pins – display B is CH return
#define CLK_B 4 // GREEN wire – D1 – equivalent to Arduino pin 4
#define DIO_B 5 // YELLOW wire – D2 – equivalent to Arduino pin 5
TM1637Display display_A (CLK_A, DIO_A); // define display 1 instance
TM1637Display display_B (CLK_B, DIO_B); // define display 2 instance
Each display requires two pins of the NodeMCU: CLK (clock) and DIO (data input-output) (fig. 2). These are the wires indicated in green (CLK) and yellow (DIO). In the comments in the sketch the digital pins for connection with a classical Arduino are indicated. Further they need connection to 3.3V DC power and GND.
In the sketch the DS18B20 sensors are called to report their current temperature. Values are stored in variables ‘temp_00’ and ‘temp_01’. The instructions to send the contents of ‘temp_00’ and ‘temp_01‘ to their respective 7-segment led displays are:
The complete sketch is supplied at the end of this paper.
Figure 3 shows the fully assembled monitoring station, placed in a plastic box inside the electricity meter cabinet of my home, with various wires running to peripheral components. A chart constructed from log data collected during a few days in January, 2020 and extracted from a downloaded log file from the Thingspeak server, is shown in figure 4. The period involved had mild outside temperatures for the time of the year (day temperature 6 oC and night temperature down to 2 oC; dark cloudy days with some drizzle – one of these days had a sunny spell.
Figure 3. Completely assembled and operational monitoring station: led displays mounted on the lid while the NodeMCU sits in the box. The left displayshows the supply temperature, right display the return temperature.
As can be seen in the registration in figure 4, the temperature of the CH supply pipe (red graph) increases rapidly in the early morning from night set-back temperature (15 ºC) to a temperature hovering around 50 ºC and then in approximately 10 cycles cools a little bit and returns to the 40-50 degrees mark. In the morning of day 2 the sun started to shine which reduced demand for heat until 15:00 when low clouds returned. At 23:00 the central thermostat switches to night temperature and temperature in the supply pipe drops rapidly. Outside night temperature was a few degrees above freezing point, no wind. The temperature of the return pipe remains remarkably stable around 21 ºC.
Figure 4. Logging graph: four 24-hour periods in a row in January of the temperatures of the CH supply pipe (red) and CH return pipe (blue).
The graphs nicely show the effect of night set-back. The central thermostat is programmed at 15 ºC room temperature at night (period starts 23:00) and 19.5 ºC room temperature during the day and early evening (period begins 06:00). When the CH boiler switches to night set-back and the temperature in the supply pipe drops, room temperature drifts from 19.5 ºC to approximately 17ºC in the early morning (when it freezes outside), thanks to the thick sub floor insulation, the high heat capacity of the floor itself (underfloor heating in the living room, radiators elsewhere), high-performance thermal insulating glass, and the thermal insulation of walls and roof. The beginning of the day period is set intentionally at 06:00 to allow the floor heating to do its work for one hour before the inhabitants of the home get out of bed. The temperature of the water in the return pipe surprisingly does not change much, hovering day and night around 20 ºC, drifting to 15 ºC during night set-back. Sunshine, if available in winter, is trapped in the form of heat inside the home. This reduces demand for CH heat – as can be deducted from the chart, day 2.
The log files available at the Thingspeak account are downloaded every month and imported in a spreadsheet program (LibreOffice).
The dual-CH pipe temperature monitoring station described here is and expansion of a previous IOT cloud-reporting temperature logging project**. It is currently in 24/7 operation and will remain so during the rest of the current heating season. At some point in late spring the station will be switched off and remain so during the summer season. Figure 4 is extracted from the January 2020 log file.
The principal components of the monitoring station are two DS18B20 temperature sensors, an ESP8266 NodeMCU board, and two TM1637 4-digit seven-segment led display units. The NodeMCU connects via wifi to my router and sends data to a Thingspeak server (www.thingspeak.com). The NodeMCU and the router are located in the same cabinet that also houses the electricity and gas meters. The distance between the temperature sensors and the NodeMCu (five meters) is bridged by a 22AVG three-stranded cable. This works perfectly. The 6.8 kΩ resistor at the sensor end of the connecting cable is mounted as close as practically possible to both sensors, that is where the wires coming from the sensors are properly combined and soldered to the ‘data’ strand of the connecting 22AVG cable. The value of this resistor was empirically determined (4.7 kΩ was not sufficient to get a stable signal). In other projects that included temperature reporting with multiple DS18B20 sensors a 20 meter long category 5 LAN cable was used to connect the sensors with an Arduino; here a single 4.7 kΩ pull up resistor close to the Arduino sufficed.
With one temperature registration per sensor logged every five minutes to the server at Thingspeak, with the server adding a timestamp and an incremental number, every 24h period will accumulate 24 x 12 x 4 = 1,152 data points. In one month, 1,152 x 31 = 35,712 data points will have been collected. The log file is downloaded to a local hard drive every month. My spreadsheet program accepts import of 35,712 data points without problems. The 5-minute upload period to Thingspeak is sufficient to obtain nice graphical representations of the temperature events (see figure 4). Importing massive amounts of data into a spreadsheet can become problematic when shorter upload intervals are defined. Actually there is ample space, both in physical sense (the NodeMCU) and in software terms (sketch, log file requirements) to allow addition of a third temperature sensor. I am considering adding a sensor that records the temperature outside the home. Reason for this is that CH temperatures go up and down with reference to the temperature outside the home. Display of outside temperature on an extra 7-segment led display is not critical but, if necessary, may be achieved via pins D5 and D8.
You must (of course) fill in your own wifi SSID and password, and the API key for your channel at Thingspeak.com to have the data displayed and logged at Thingspeak .
*Floris Wouterlood – The DS18B20 temperature sensor – implementation with an Arduino. Thesolaruniverse, August 17, 2017
** Floris Wouterlood – Constant monitoring/logging via a NodeMCU ESP8266 and the internet of central heating water flow temperature. Thesolaruniverse, August 17, 2018
*** Floris Wouterlood – Multi temperature-humidity sensing with an Arduino Nano – TFT display: sketch updated.