Hi folks,
this is Work in Progress and not finished yet, but I'd like to share some of this in order for feedback and thoughts on how to improve.
I am a beginner with node RED (and java script) so please be kind 
This is a solution to a special thermostat problem (Note: PID will not work here) for heating a water supply with a very slow heating element (a heat pump).
The goals for this are:
- energy efficiency for heating the water (wait as long as possible before turning on the heater) as the heat pump should run at a straight line, as long as possible
- prepare the hot water supply according to schedule(s). This is different from a standard schedule/timer thermostat, as the goal is not to turn on the heater at a scheduled time but to have the water supply readily heated at the scheduled time.
- comfort: enable extra schedules (like party and vacation mode), enable on mobile devices (thus using blynk)
....these top requirements have been fulfilled by an embedded thermostat which was subject to a lightning strike some time ago. Since then a replacement is not available on the market and it has been replaced by a standard heating controller (hysteresis driven) with no schedules.
The family (and the energy budget) needs these features back, so I started to work on my own solution.
- high availability/redundancy (put in some extra safety elements if internet, WLAN/home-net or local building blocks break down)...this is for securing the WAF for sure
The new controller is build on a Wemos D1 mini (ESP8266) device, with
- DS18B20 temperature sensor/probe
- RTC DS3231 module
- RELAIS module
- (optional) OLED display
- (optional) push-button(s)
- case/housing
- tasmota firmware from here: Tasmota firmware
...assembly picture shown below.
The WemosD1mini + Relay-Board+generic board (connecting the DS18B20 sensor(s) is sitting on a triplet-base, inside a sonoff weather-proof housing. The RTC is fly-wired to the generic board GPIO-Pins
The overall architecture looks like this:
....MQTT, node RED and blynk server(s) are deployed as dockers on my local 24/7-NAS.
- the currently deployed, embedded controller will stay in place, still electrically controlling the heat-pump. The reason for this is, that this will draw a lot of current, for which the wemos relais is not rated for. The embedded controller has a potential-free door override switch, which the wemos relais will be used to switch it on/off "remotely".
- tasmota allows for running local rules. Together with the RTC on board, this will allow for basic scheduling should node RED or other "backend components" are not available. There is an example in the wiki, here: tasmota example for local rules as a thermostat
- the tasmota device (wemos) connects to a local mosquitto MQTT server. This server is bridged to a cloudMQTT account, simply allowing for remote connect from anywhere. The MQTT frontend, build with MQTT-Dash App allows for basic controls of the tasmota device.
- local node RED running 4 flows
- integrate the tasmota device (via MQTT) and a small dashboard for debugging
- integrate blynk based App for remote control (currently running on local blynk server)
- schedule(s) management, build around schedex node(s)
- logic for controlling temperature and relais
- Blynk server, serving the blynk app, which compartments/structure is depicted below
The basic Idea:
The main temperature controlling feature is depicted in compartment #3 of the blynk app, showing the next scheduled/active event and the minutes from "now" until this next scheduled event will fire.
Based on the current temperature, the (fixed, end-)target temperature and the (fixed) heating curve from the heat-pump the flow #4 will need to calculate the time it will take to heat the water supply from now and turn the relais ON when the "time-to-heat" is less that the "time-until-next-event".
Once ON, it will need to monitor the temperature until the target temperature is reached and switch the relais OFF again. With a heating schedule active/on the temperature needs to be monitored and heating switched back ON, should the level drop below a certain threshold (normal hysteresis mode).
The actual status:
Flows 1, 2 are up and running...flow 3 is in a basic state, controlling vacation and party mode still needs to be integrated into the determination which of the schedule(s) is active/next.... flow 4 is scheduled for development (told you, this is WiP)
