Home Automation System

Introduction

A natural spin-off from all of our Raspberry Pi, Arduino and ESP8266 projects was the idea of building our own Home Automation System. We wanted to learn to use the best techniques to intelligently control and automate existing household appliances such as:

Solar inverters;
Smart meters;
Smart plugs;
Air conditioners;
Smoke detectors;
Garage door opener;
Video surveillance and
Security systems.

Requirements

We need to monitor and control the appliances in our home.
We need a graphical user interface to access these appliances from our smart phones when we are at home or away from home.
We need real-time alerting of any potential security issues.
We need local automation of these appliances to provide intelligent, energy-efficient, home heating, cooling, safety, surveillance and security.
We need to ensure a high level of cyber security.

Design Decisions

Before we describe the various solutions that we have used, we wanted to write down some of our important design decisions:

Third-party, proprietary, closed-source and cloud-based, solutions: This is a DIY project. We want to learn as much as possible ourselves and will shy away from existing, third-party or proprietary solutions if we can do it ourselves. That rules out existing home automation applications like HomeAssistant, which is very good and open-source and can run locally, but it's not exactly what we want. We have a privacy, security and availability aversion to all cloud-based solutions. All processing must be done in-house and must work even if the Internet connection is down.
Local communications: Home Automation Systems typically comprise a central server, in our case a Raspberry Pi, and numerous, Internet of Things (IoT) devices scattered around the home. These IoT devices can use a plethora of communications techniques such as: WiFi; Bluetooth; Zigbee; LoRaWAN and Cellular. Since all our ESP8266 devices support WiFi, we will just stick to that. They will communicate over what we call our "IoT WiFi network", but it will not be connected to the Internet.
External communications: While away from home we will access our Home Automation System using our smart phones. So the logical approach is to use the cellular broadband network and the Internet for that. In addition we will use the same networks to receive real-time SMS alerts.
Operating System: Typically we will install all our flash-able IoT devices with the same IoT operating system. There are too many embedded operating systems to mention here. We have not done any extensive evaluation, but initial success flashing an ARLEC Grid Connect smart-plug with Tasmota and a Wemos D1-Mini clone with ESPHome was so easy that we decided to check them both out. Tasmota has a nice web interface: Simply select the function of each pin from a drop down. The device reboots and it works. ESPHome requires a YAML script file: Compile and upload an image: The device reboots and it works. They both permit the device to be reprogrammed over the air, which is essential. In the end we chose ESPHome, because it is fully scriptable. What we don't like about it is that it takes 12 minutes to compile an image on a RPi 3 and it uses YAML, of all things, not Python.
Messaging Protocol: To efficiently send commands and receive telemetry in real-time from IoT devices we will use a messaging protocol such as MQTT, AMQP, DDS, XMPP or CoAP. Again, since we had some luck with Tasmota and ESPHome using the Message Queuing Telemetry Transport (MQTT) protocol, we will stick to that. One advantage of using a messaging protocol is that the server and all clients only need to know the IP address of the MQTT Broker and not each other.
Rule Processing: Typically home automation rules are processed by cloud-based servers such as Node-Red or If This Then That (IFTTT). Well, we don't want our rules in the cloud. We can easily write our own Python scripts on our server to automate our IoT devices.
Graphical User Interface: The GUI to monitor and control our home must run on any PC or mobile device. We don't have the time or expertise to write apps for all mobile platforms, so the GUI will have to be accessible on any connected device via a web browser. The GUI web pages will be provided by a web server running on our Home Automation Server.
Cyber Security: There is no real security with IoT devices, so we will use a separate WiFi router to isolate them from our normal home WiFi network and not permit them to have any Internet access. Each IoT device will have a static IP address and will be whitelisted on the IoT router's MAC filter. Strong WiFi access passwords and OTA programming passwords will be used. External access will be limited to the web pages from the Home Automation Server. It will be the only device which spans both networks, but will provide no route between them. For external access we will use a secure VPN. Having trialled both OpenVPN and WireGuard on our iPhones, we chose WireGuard for its smaller footprint and more secure and efficient tunnelling. It works well on all PC and mobile platforms.

Components

The Home Automation System comprises the following components:

NBN Router and Home WiFi Router
Home Automation Server
IoT WiFi Router
Video Surveillance System
Grid Smart Meter
Kettle Power Control Experiment
Solar Inverter and Solar Smart Meter
Security System
Alarm System
Temperature Sensors
Smoke Detectors
Motion Sensors
Smart Plugs
Garage Door Opener
Reverse Cycle Air Conditioners
Uninterruptible Power Supplies

Layout

NBN Router and Home WiFi Router

The NBN Router and Home WiFi Router provides a Local Area Network over both WiFi and Ethernet for our home PCs and mobile devices. It also provides a gateway to the Internet via the National Broadband Network Hybrid Fibre/Coaxial cable connection.

Home Automation Server

The Home Automation Server is the central hub of the system. It monitors and controls the home IoT devices via the IoT WiFi Router; implements intelligent automation rules; provides a web-based, graphical user interface over the Home WiFi/Ethernet Router or over the Internet and broadband mobile network via a secure VPN and, finally, it connects to an SMS gateway (SMS Everyone) providing real-time alerts. It is a Raspberry Pi model 3B+. The Home Automation Service is programmed in Python.

IoT WiFi Router

The IoT WiFi router provides a Local Area Network over WiFi or Ethernet for our home IoT devices. It is completely isolated from the Internet.

Video Surveillance System

The video surveillance system provides CCTV cameras covering different zones of the home, including networked video recording and playback facilities with off-site storage. It connects via the WiFi network.

Grid Smart Meter

As a check of the electricity bill from our utility company, we also monitor their grid smart meter. It has a pulsed LED output. We use our Smart Meter WiFi Interface Module. It has an optical sensor to count the pulses every minute.

Kettle Power Control Experiment

As an experiment, we use a MakerFabs AC Dimmer to control the power to the kettle. It boils the kettle in the morning using only the excess power produced by the Solar Inverter. See our: Kettle Power Control Experiment Interface.

Solar Inverter and Solar Smart Meter

The solar inverter provides information about the electrical energy being provided by the roof-top solar array and the electrical energy being provided to the home and the grid. It connects to a smart meter via a CAN bus cable. All the information is provided over a WiFi network in XML format using a ReST protocol.

Security System

The security system provides monitoring of internal PIR/MW sensors and alerting to an off-site security monitoring centre. To connect it to our IoT WiFi network we had to design an build our own Dual-Zone WiFi Interface Module.

Alarm System

The alarm system comprises a internal screecher, external strobe light and siren. To connect it to our IoT WiFi network we had to design an build our own Alarm WiFi Interface Module.

Temperature Sensors

The temperature sensors accurately measure the inside and outside air temperature. They connect via the WiFi network. They comprise our ESP-01S WiFi Interface Module with a Dallas Semiconductor DS18B20 temperature sensor.

Smoke Detectors

The smoke detectors alert to the presence of fire in the home or garage. They are modified battery-operated smoke detectors. They connect our IoT WiFi network via our Smoke Detector WiFi Interface Module.

Motion Sensors

The motion sensors alert us to the presence of visitors entering our property. They connect our IoT WiFi network via our Motion Sensor WiFi Interface Module.

Smart Plugs

The smart plugs control the power to various household appliances. They connect via the WiFi network. We use our ARLEC Grid Connect WiFi Interface by flashing the units with the ESPHome operating system and Athom Smart Plugs with Energy Monitoring that come pre-flashed with ESPHome. In both cases we developed our own YAML configuration files.

Garage Door Opener

The garage door opener connects to our Merlin MR850 roller-door opener. It connects to our IoT WiFi network via our Garage Door Opener WiFi Interface Module.

Reverse Cycle Air Conditioner

The reverse cycle air conditioners are used to heat and cool the home. The air conditioning mode (heating, cooling or dehumidifying) and the set temperature can be set over the WiFi network in CSV format using a ReST protocol.

Uninterruptible Power Supply

The Uninterruptible Power Supply provides battery backup for all critical systems. We use safe, lead-acid, standby batteries maintained on a trickle charge.

Web Pages

The Home Automation Server includes a Python (Flask/Waitress) web server displaying the following pages. The screenshots show the Control, Display and Cameras page designed to fit our iPhone screens. At the top of each page are a set of page navigation buttons. The blue button indicates the currently selected page.

Control Page

Display Page

Cameras Page

Control Page

The Control page shows Information, Power Zones, Security Zones, Air Conditioning and System Status group boxes.

The Information group box shows: The date and time; solar power generated and exported, home power usage and power imported from the grid; temperatures inside and outside as well as in the hallway and garage.

The Power Zones group box shows: Power indicator/buttons for our PC, radio, kettle, car battery chargers and the garage door opener. Grey indicates the power is off (or the garage door is closed). Blue indicates that the power is on (or the garage door is opened).

The Kettle power zone is an interesting experiment: The kettle (if filled with water and switched on) is programmed to turn on in the morning when the excess solar power exported is greater than 450 W. The 2.4 kW kettle is limited to draw only 400 W using an AC lamp dimmer. This ensures that we can get a morning cup of tea without importing any power from the grid.

The Security Zones group box shows: Alarm indicator/buttons for ten security zones. Grey indicates the zone is not armed, blue indicates the zone is armed. The number displayed below the name indicates the number of times the zone has been triggered since the last time the reset button was pressed. When an armed zone is triggered, an alarm sounds and an SMS message is automatically sent to our iPhones.

The Air Conditioning group box shows: Five modes of operation for our reverse-cycle air conditioning system. Blue indicates the selected mode. The auto mode is an experiment, which turns on the air conditioning in the appropriate mode for the inside and outside temperatures. It advances the temperature setting from the initial ambient value to the final setting by one degree at a time only when the house has achieved the previous increment and only if there is sufficient excess solar power to do so. It turns off the system when there is insufficient solar power. This provides the most efficient heating or cooling by minimising the large initial inrush of energy caused by just manually setting the final desired temperature. To override the auto setting is a manual mode with adjustable temperatures.

The System Status group box shows: The server and client IP addresses.

Display Page

The display page shows a table and graph of home automation information intended to permit the assessment of system performance.

The table shows the energy supply, export, usage, import, costs and savings for now, today, yesterday, this month this year, this month last year, this year and last year. All values are prorated to the current date and time.

The graph shows coloured areas for energy supply, export, usage and import over the last 24 hours, together with the history of peak solar supply taken on this day in all previous year. The inside and outside temperatures are also shown as a dotted line.

Cameras Page

The Cameras page shows the real-time video and audio (with some latency, of course) from two CCTV cameras. Note: The image was taken before the camera had been properly mounted.

Interfaces

To connect various appliances to our home automation system via our new IoT network we had to design and build several interface modules and use them in various ways:

Dual-Zone WiFi Module

We wanted to connect our home security system, which has 5 dual Microwave/Passive Infra-Red (PIR) motion detectors, around the house, to our home automation system via our IoT WiFi network. We have a 4-zone, NX-4 Security System, which is configured for zone-doubling to support up to 8-zones. To achieve this, each zone input can be connected to two sensors, each with a different value End-Of-Line (EOL) resistor. The zone inputs change from being a simple 2-level analog input to being a 4-level analog input. We found that the voltages, indicating which sensors are active, are actually quite precise and they have to be measured as a ratio of the supply voltage. We looked at various Arduino configurations and decided that we would need a 5-channel analog to digital converter, with 5 analog voltage inputs and 8 digital outputs, followed by a WiFi-enabled device with 8 digital inputs. This could not be achieved in one device. So a 3.3v 8MHz Atmega328 Pro Mini board was used as the analog to digital converter and a ESP8266 D1-Mini board was used as the WiFi interface. One of the input channels accurately measures the supply voltage. The security system UPS provides a battery-backed 12V power supply. The processor boards have an on-board 3.3V regulator, but to be kind to them, we would feed them from a regulated 5V supply.

Dual-Zone WiFi Module Hardware

The two boards were mounted on a prototyping board with its own 5V regulator:

Dual-Zone WiFi Module

The input wires of the Dual-Zone WiFi Module are colour-coded as follows: Brown, red, orange, yellow: Dual-Zone Inputs 1-4. White: 12V. Black: Ground. The Green LED indicates power. The Red LED indicates that one or more zones are active. Annoyingly, the ESP8266 D1-Mini board is also affected by boot-up problems on several of its I/O pins. Hence, only 5 of the 8 digital outputs of the Atmega328 Pro Mini board could be supported. Luckily, in our home, we only have 5 PIR detectors!

Dual-Zone WiFi Module Software

The software for the D1-Mini board was an ESPHome YAML script.

The software for the Pro-Mini board was written in C++ with the Arduino IDE. Here is a excerpt:

//The security system has 4 physical zones inputs (1-4) each connected to up to two sensors

const float Ri = 3240.0; //This is the measured internal pullup resistor, in ohms, on each physical zone in the security system:

//In dual-zone mode each physical zone input supports two zones, one low and one high as follows:

//Input 1: Zones 1 & 5, Input 2: Zones 2 & 6, Input 3: Zones 3 & 7, Input 4: Zones 4 & 8

//Each sensor comprises a Normally-Closed contact and a series End-Of-Line resistor.

const float Rh = 3750.0; //The EOL resistance on the high zone sensor, in ohms. The high zone is active when Rl is NOT present.

const float Rl = 6970.0; //The EOL resistance on the low zone sensor, in ohms. The low zone is active when Rh is NOT present.

const float Rp = 1.0 / (1.0 / Rh + 1.0 / Rl); //The EOL resistance with both sensors inactive, in ohms.

//The constant K is used to calculate the actual zone input voltage from the analog read value

//Given the Arduino supply voltage and the input resistive-divider values

const float Vcc = 3.3; //The Arduino Pro Mini supply voltage

const float Amax = 1023.0; //The analogRead values range between 0 and Max for voltages between 0 and Vcc

const float R1 = 47000.0; //The chosen voltage divider resistor connected to the zone input

//R2 = R1 / (Vs / Vcc - 1) = 15132; //The required voltage divider resistor connected to ground

const float R2 = 15000.0; //The chosen voltage divider resistor connected to ground

const float Vmax = Vcc * (R1 + R2) / R2; //The maximum permitted zone input voltage

const float K = Vmax / Amax; //A constant to convert analogRead values to zone input voltages

//Get the current supply voltage

vs = K * analogRead(A5); //Read the zone input voltage and wait for it to stabilize

//Here are the formulas for the dual-zone input voltage in each case, in order of decreasing voltage:

//vb = vs, so not included here

vl = vs * Rl / (Ri + Rl); //Low zone active

vh = vs * Rh / (Ri + Rh); //High zone active

vn = vs * Rp / (Ri + Rp); //No zone active

//To identify active zones we require 3 threshold voltages half way between Vb & Vl, Vl & Vh and Vh & Vn. They are: Vsl, Vlh and Vhn.

vsl = (vs + vl) / 2.0;

vlh = (vl + vh) / 2.0;

vhn = (vh + vn) / 2.0;

//Get the current zone activation state

zone = 0; //Reset the zone activation state

for (int i=0; i<4; i++) { //For each zone input

float vz = K * analogRead(inputPin[i]); //Read the zone input voltage and wait for it to stabilize

if (vz >= vsl) {zone += 0b00010001 << i;} //Set both zone bits

else if (vz >= vlh) {zone += 0b00000001 << i;} //Set the low zone bit only

else if (vz >= vhn) {zone += 0b00010000 << i;} //set the high zone bit only

}

Alarm WiFi Module

Our home security system is connected to an inside screamer alarm and an outside siren alarm and an outside strobe alarm light. We wanted to control these devices, individually, along with other power zones from our smart phones. So we needed a WiFi processor with 3 digital outputs. Easy! Copying the design of our Dual Zone WiFi Module we would use a ESP8266 D1-Mini board as the WiFi interface, again with a 5V regulator. We knew that we could use up to 5 of the D1-Mini outputs and program it with ESPHome YAML script. The outputs would be connected to 12V external devices, so we would need three high-voltage, high-current outputs. The easiest solution was to connect each of the external devices to 12V and use three N-channel enhancement-mode MOSFETS to pull them to ground.

Screamer/Siren/Strobe WiFi Module Hardware

The ESP8266 D1-Mini board was mounted on a prototyping board with its own 5V regulator:

Alarm WiFi Module

Screamer/Siren/Strobe WiFi Module Software

The software for the D1-Mini board was an ESPHome YAML script.

#This ESPHome alarm.yaml file configures a D1-Mini board to provide 3 GPIO outputs on pins D5, D6, D7.

#It publishes and subscribes to MQTT topics over the WiFi network via the MQTT broker on the Home Automation System.

#It publishes MQTT topics "p18", "p19" and "p20" providing the state of the output

#It subscribes to MQTT topics "s18", "p19" and "s20" to receive "on", "off", "toggle" and "state" messages.

#To upload: esphome run alarm.yaml

#Set up constants

substitutions:

#Uncomment the name and ip_address of the Smart Plug to be programmed or use the command line -s directive

zone: '0' #PC Smartplug

ip_address: '192.168.2.20'

name: 'alarm'

alarm_zone: '18'

siren_zone: '19'

strobe_zone: '20'

alarm_pin: 'D7'

siren_pin: 'D6'

strobe_pin: 'D5'

to_alarm: 'p${alarm_zone}' #The topic for receiving messages from the server

from_alarm: 's${alarm_zone}' #The topic for sending messages to the server

to_siren: 'p${siren_zone}' #The topic for receiving messages from the server

from_siren: 's${siren_zone}' #The topic for sending messages to the server

to_strobe: 'p${strobe_zone}' #The topic for receiving messages from the server

from_strobe: 's${strobe_zone}' #The topic for sending messages to the server

on_message: '1'

off_message: '0'

toggle_message: 'x'

state_message: '?'

#Set up core functionality

esphome:

name: ${name} #The name of this device

#compile_process_limit: 2 #Reduce the number of cores to use. Necessary for RPi 3

#Set up processor and board

esp8266: #Use the ESP8266 platform

board: d1_mini #The WEMOS D1 mini clone

#Set up WiFi

wifi:

ssid: <SECRET> #This network is isolated from the Internet, but has an MQTT broker

password: <SECRET>

manual_ip:

static_ip: ${ip_address}

gateway: 192.168.2.1

subnet: 255.255.255.0

#Enable a fallback access point in case the WiFi connection fails

ap:

ssid: ${name} #Use the device name as the SSID

#Enable the captive portal for the WiFi access point

captive_portal:

#Enable logging

logger:

level: NONE

logs:

mqtt.component: NONE

#Enable programming Over The Air

ota:

- platform: esphome

#Enable Message Queuing Telemetry Transport

mqtt:

broker: 192.168.2.2 #The IP Address of the MQTT broker

port: 1883 #The port number of the MQTT broker

on_message: #When a message is received from the MQTT broker

- topic: ${to_alarm} #When a message is received from the server

payload: ${on_message} #When an on message is received

then:

switch.turn_on: alarm_switch #Turn on the switch and publish the state

- topic: ${to_alarm} #When a message is received from the server

payload: ${off_message} #When an off message is received

then:

switch.turn_off: alarm_switch #Turn off the switch and publish the state

- topic: ${to_alarm} #When a message is received from the server

payload: ${toggle_message} #When a toggle message is received

then:

switch.toggle: alarm_switch #Togggle the relay

- topic: ${to_alarm} #When a message is received from the server publishing topic

payload: ${state_message} #When a state message is received

then:

mqtt.publish: #Publish an MQTT message

topic: ${from_alarm} #Publish the input state to the server

payload: !lambda |-

return to_string(id(alarm_switch).state);

- topic: ${to_siren} #When a message is received from the server

payload: ${on_message} #When an on message is received

then:

switch.turn_on: siren_switch #Turn on the switch and publish the state

- topic: ${to_siren} #When a message is received from the server

payload: ${off_message} #When an off message is received

then:

switch.turn_off: siren_switch #Turn off the switch and publish the state

- topic: ${to_siren} #When a message is received from the server

payload: ${toggle_message} #When a toggle message is received

then:

switch.toggle: siren_switch #Togggle the relay

- topic: ${to_siren} #When a message is received from the server publishing topic

payload: ${state_message} #When a state message is received

then:

mqtt.publish: #Publish an MQTT message

topic: ${from_siren} #Publish the input state to the server

payload: !lambda |-

return to_string(id(siren_switch).state);

- topic: ${to_strobe} #When a message is received from the server

payload: ${on_message} #When an on message is received

then:

switch.turn_on: strobe_switch #Turn on the switch and publish the state

- topic: ${to_strobe} #When a message is received from the server

payload: ${off_message} #When an off message is received

then:

switch.turn_off: strobe_switch #Turn off the switch and publish the state

- topic: ${to_strobe} #When a message is received from the server

payload: ${toggle_message} #When a toggle message is received

then:

switch.toggle: strobe_switch #Togggle the relay

- topic: ${to_strobe} #When a message is received from the server publishing topic

payload: ${state_message} #When a state message is received

then:

mqtt.publish: #Publish an MQTT message

topic: ${from_strobe} #Publish the input state to the server

payload: !lambda |-

return to_string(id(strobe_switch).state);

switch:

- platform: gpio

id: alarm_switch

restore_mode: always off

pin:

number: ${alarm_pin}

inverted: False

on_turn_on: #When the relay is tuned on

- mqtt.publish: #Publish an MQTT message

topic: ${from_alarm} #Publish a message to the server

payload: ${on_message} #Publish the on message

on_turn_off: #When the relay is turned off

- mqtt.publish: #Publish an MQTT message

topic: ${from_alarm} #Publish a message to the server

payload: ${off_message} #Publish the off message

- platform: gpio

id: siren_switch

restore_mode: always off

pin:

number: ${siren_pin}

inverted: False

on_turn_on: #When the relay is tuned on

- mqtt.publish: #Publish an MQTT message

topic: ${from_siren} #Publish a message to the server

payload: ${on_message} #Publish the on message

- delay: 10s #Turn the siren off after 10 seconds

- switch.turn_off: siren_switch

on_turn_off: #When the relay is turned off

- mqtt.publish: #Publish an MQTT message

topic: ${from_siren} #Publish a message to the server

payload: ${off_message} #Publish the off message

- platform: gpio

id: strobe_switch

restore_mode: always off

pin:

number: ${strobe_pin}

inverted: False

on_turn_on: #When the relay is tuned on

- mqtt.publish: #Publish an MQTT message

topic: ${from_strobe} #Publish a message to the server

payload: ${on_message} #Publish the on message

on_turn_off: #When the relay is turned off

- mqtt.publish: #Publish an MQTT message

topic: ${from_strobe} #Publish a message to the server

payload: ${off_message} #Publish the off message

ESP-01S WiFi Module

We wanted to connect some temperature sensors, smoke detectors, motion sensors and a garage door opener to our home automation system via our IoT WiFi network. The natural solution was to use these tiny, cheap ESP-01S Espressif 8266 breakout boards. These have an ESP8266 processor, 1MB of RAM and a WiFi interface on board.

ESP-01S - Esspressif 8266 Breakout Board

These ESP-01S breakout boards have 4, 3.3V, General Purpose Input/Output (GPIO) pins. However, since we needed to connect real-world devices like a 12V power supply, a 12V switch input, a 12V relay output and a DS18B20 one-wire temperature sensor, we had to design and build our own ESP-01S WiFi Module to mount the ESP-01S breakout board together with extra interface components.

ESP-01S Boot-Up Investigation

One drawback with the ESP-01S breakout board is that the only available GPIO pins can be quite temperamental when the device is booting up. Some GPIO pins pulse high or low for up to 150ms and some can't be pulled low while booting (and some do both). So deciding which GPIO pins to use can be quite a challenge. Most users encounter these problems and simply apply workarounds using heavy filter capacitors on the GPIO pins. This is not an appropriate solution, of course.

To fully investigate the situation, we provided a 4k7 Ohm pull-up resistor on GPIO pins 0 to 3. We set each pin as a non-inverting output and alternately set the output high and low after boot up at the earliest possible opportunity. This was to discover the full extent of the boot-up waveforms. For those interested in the ESPHome YAML configuration, this is done using an on_boot event in the esphome section and turning on or off the outputs at a priority level of 600 - just after the GPIO pins are configured. In all cases the output waveform did not stabilise for 150ms after boot. Here are the boot-up waveforms that we recorded:

GPIO 0 Set High and Low After Boot

GPIO 1 Set High and Low After Boot

GPIO 2 Set High and Low After Boot

GPIO 3 Set High and Low After Boot

ESP-01S Pin Usage

Here are our design decisions:

GPIO3 is unusable as an output as the low level was above 1V, but it is the only pin that can be low on boot. So we used it as an input.
GPIO2 can be used as an I/O pin for the DS18B20 one-wire bus, or as SCL for an I2C bus, but must be pulled high on boot.
GPIO1 is not needed in our design, but must be pulled high on boot. It can be used as SDA for an I2C bus in conjunction with GPIO2, and in hindsight we should have provided a separate pad for it. The pad for pin 2 of R2 can be used instead.
GPIO0 can be used as an output, but only with a properly designed Low Pass Filter (LPF) to stop the boot-up pulses propagating to the output, and it must be pulled high on boot.

ESP-01S WiFi Module Schematic Diagram

Here is the schematic diagram of our ESP-01S WiFi Module. U1 is the ESP-01S with 4 I/O pins, GPIO 0 - 4. U2 is a 3.3V regulator, which can handle up to 15V input. U3 is a Dallas Semiconductor DS18B20 one-wire temperature sensor. R1 - R4 are pull-up resistors on all I/O pins. Q1 is an input MOSFET, which can handle up to +/- 20V on its gate. Q2 is the LPF in conjunction with R7, R8 and C3. Q3 is an inverter, Q4 is an output, which can handle up to 60V at 115mA.

ESP-01S Module Schematic Diagram

ESP-01S WiFi Module LT Spice Simulation

To ensure the Low Pass Filter worked well under all conditions we used LT Spice to model and simulate its operation. Here is the LT Spice schematic: The GPIO provides 3.3V pulses. A 12V external supply is connected to Q3 via a 120 Ohm resistor, limiting the current to 100mA. We designed the LPF to remove up to 230ms of input pulses - a 50% margin on our measurements.

LT Spice Schematic of the Low Pass Filter output circuit

The LT Spice simulation is shown below. The GPIO waveform is shown in green. The output waveform is shown in blue. A 3.3V 230ms GPIO pulse is generated at 1s to simulate the boot-up pulse. A 3.3V 1s GPIO pulse is generated at 2s to simulate a normal GPIO output waveform. We can see that the 230ms pulse at boot-up does not propagate to the output, while the normal GPIO output does, except that it is shortened by about 230mS, which is OK. The main usage of this output circuit is to pulse a garage door opener, for about 1s, while making sure that the garage door is not operated at boot up.

LT Spice Simulation of the Low Pass Filter output circuit

ESP-01S WiFi Module Printed Circuit Board

The PCB top-view is shown below. The ESP-01S is mounted on the bottom side of the PCB.

ESP-01S WiFi Module Top View

The PCB side-view is shown below. In practice the plastic spacer on the header is removed and the ESP-01S is mounted flush. Depending on the application, some of the components may be optional.

ESP-01S WiFi Module Side View

Power Supply

The AMS-1117 3.3 V regulator on the ESP-01S WiFi interface module gets pretty hot with the module running on 12 V. It dissipates nearly 1 Watt! In fact, when put a temperature-sensing module in the ceiling, running off 12 V, it locked up when the temperature hit 34 C and had to be rebooted. So, if you want to run the module on voltages higher than 5 V we recommend adding an external 1 W Zener diode. For 12 V operation we use a 1N4737 7.5 V 1 W Zener Diode in series with the power supply.

Electromagnetic Compatibility

We knew that tiny microprocessors don't like to be nearby high-power radio transmitters. So we suspected that putting these modules in the ceiling, at the end of long, twin-line, DC power cords, only 6 m below our transmitting antenna was likely to be a problem. However, when we found that our temperature sensor WiFi modules returned erroneous results during our daily 40 m net on 7105 kHz, we knew we had to do something about it. We usually transmit single side-band at 400 W PEP. Even for continuous carrier this level at our antenna's height this is perfectly safe for humans, according to VK3UM's EMRCalc, but apparently not so for ESP8266 processors and DS18B20 temperature sensors.

We tried all the simple solutions, up to and including two series uncoupled 470 uH inductors with two parallel 0.1 uF capacitors on the end of the power cords. They had no effect and we still received erroneous temperature readings whenever we transmitted. Then we did some research into using two coupled inductors on a single toroidal ferrite cores. There are two common configurations for coupled inductors used in RF chokes for RFI/EMC applications: Common mode chokes (where the windings are out of phase) and the, less popular, differential mode chokes (where the windings are in phase) and sometimes a combination of both. Since the processor was at the end of the power line with no ground connection we presumed that the only mode of RF susceptibility was to differential mode RF signals on the twin-leads (Note: Using twisted-pair cable may have been a better solution).

So we wound our own coupled, differential-mode, choke on an FT37-43 toroid. 30 cm of enamelled copper wire produced about 21 turns for each winding with enough wire to spare for connection. That is 154 uH according to this on-line calculator. We added some 0.1 uF capacitors and some screw terminal blocks on a small piece of Veroboard (Note: If you have ever tried to solder wires in the ceiling, you will understand the need for screw terminal blocks). Even with this lower inductance value, the devices worked a treat - problem solved. P.S. you should also connect DS18B20 temperature sensors with shielded cable, no longer then a metre.

Differential Mode EMC Filter

Smoke Detector WiFi Interface

We wanted to connect two smoke detectors to our home automation system via our IoT WiFi network. These detectors are very basic, 9V battery-powered models. Internally, they use a MC145012 chip which, according to the data sheet, is a "Photoelectric Smoke Detector IC with I/O and Temporal Pattern Horn Driver". Importantly, pin 7 is a 9V, Input/Output pin, allowing multiple smoke detectors to be daisy-chained together. It is pulled to 9V when smoke is detected. We carefully opened the unit and removed the photo-electronic smoke detector module. We soldered two fine wires to MC145012 pin 7 I/O and pin 14 GND, using dobs of hot-melt glue to secure the wires. Reassembling the unit, we soldered the other ends of the fine wires to our ESP-01S WiFi interface module, which conveniently fitted inside the case above the 9V battery compartment. This module only needed the components for a digital input. As the input device is 2N7002 MOSFET there would be no loading on the MC145012 I/O pin. The unit was powered from the battery-backed 12V power supply from our DAS NX4 security system.

Basic 9V Battery-Powered Smoke Detector

Underside of the Photo-electronic Smoke Detector Module showing soldered wires

Assembly of the unit with our ESP-01S WiFi Interface Module

Motion Sensor WiFi Interface

We wanted to connect four microwave motion sensors to our home automation system. We reused our ESP-01S WiFi module to connect the sensors to our IoT WiFi network. However the sensors were AC mains powered with a AC mains output normally used to control a lamp. For safety, the interface required an opto-coupler to isolate the sensor output from the input of the ESP-01S WiFi module. The ESP-01S WiFi module also required a 5V DC mains power supply. The wiring of the sensor can be seen in the following image. The optocoupler and power supply can be readily found on eBay.

220 V AC Optocoupler

220 V AC to 5V 1A Power Supply

Microwave Motion Sensor with Power Supply, Opto-Coupler and ESP-01S WiFi Module

Microwave Motion Sensor Assembly

Smart-Meter WiFi Interface

We wanted to check our Utility-Company's Smart-Meter readings as they didn't seem to correlate with our own Solar Inverter Smart-Meter. A simple way to measure the supply from the grid was to count the flashes of the Utility-Company's Smart-Meter LED. All we had to do was to connect a Light-Dependent Resistor (LDR) to our ESP-01S WiFi Module and write some ESPHome YAML script to make it count the pulses over 1 minute intervals. It then sends the count over the IoT WiFi network to our Home Automation Server.

The Utility-Company's Smart-Meter is an i-Credit 500 with an LED pulse rate of 3200 pulses per kWh.

Hardware

We used a back-to-back LDR and LED. The LED flashes in response to the Smart-Meter LED flashing (which is no longer visible).

Smart-Meter WiFi Interface Assembly and Schematic Diagram

Software

The ESPHome YAML script for this ESP-01 pulse counter is shown below (abridged). It was tested up to 6000 pulses per minute, well beyond what the smart-meter produces.

#Pulse meter component counts pulses on the input pin

sensor:
- platform: pulse_meter             #Do not use pulse_counter: It does not work.
   pin:
     number: ${input_pin}
     mode: INPUT_PULLUP
   id: my_pulse_meter
   internal: yes
   total:                            #Create a total count
     id: my_total_count

#Timer component accurately runs every 60 seconds
time:
- platform: sntp
   id: sntp_time
   timezone: Australia/Melbourne
   servers:
    - 192.168.2.2
   on_time:
     - seconds: /60                  #Wait for 60 seconds
       then:
         - mqtt.publish:             #Publish an MQTT message
             topic: ${to_server}     #Publish the local time and the total count over the last minute
             payload: !lambda |-
               char str[11];
               sprintf(str, "%s,%d", id(sntp_time).now().strftime("%H:%M").c_str(), int(id(my_total_count).state));
               return str;
         - pulse_meter.set_total_pulses:                        #Reset the total count
             id: my_pulse_meter
             value: 0

ARLEC Grid Connect Smart Plug WiFi Interface

We wanted to connect four ARLEC Grid Connect Smart Plugs to our home automation system via our IoT WiFi network. Unfortunately, when purchased, these units only work with a cloud-based app, so we had to reprogram them with the ESPHome operating system. The hardest part of doing that was opening the plastic case. It required an uncommon, tri-star, security bit tool. We managed to find one on eBay. We opened the case and undid a few more Phillips screws to remove the circuit board.

ARLEC Grid Connect Smart Plug and Special Tri-Star Driver

To reprogram the device we used a USB 3.3V to serial converter to suit the TYWE2S module mounted on the printed circuit board. We first soldered coloured wires to a SIP socket that fitted on to the converter pins. The colours used were: Red - 3.3V; Black - Ground (2-wires); Orange TXD and Green RXD. It is very important to set the serial converter output voltage to 3.3V.

USB to 3.3V Serial Converter

We then noted the connections of the TYWE2S module and soldered the other end of the coloured wires to it

TYWE2S ESP8266 WiFi Module

Four of the coloured wires soldered easily to the edge connector of the TYWE2S module, noting that the TXD and RXD wires had to be cross-connected. However one black ground wire had to be soldered to the I00 pad on the bottom side of the module. This wire was to set the TYWE2S module into programming mode.

Soldering USB 3.3V Serial Converter Wires to TYWE2S

The USB to serial converter was then connected to the Raspberry Pi and an ESPHome command (e.g. esphome -s zone 0 -s ip_address 192.168.2.6 run plug.yaml) was used to program the TYWE2S using the YAML configuration file shown here. When the USB programming was complete, the programming ground wire was unsoldered from the TYWE2S module and the USB power was cycled to permit a normal boot up. Once the unit booted up, the same ESPHome command was used to test OTA programming by selecting that mode when prompted. Once that was confirmed, all the coloured wires were unsoldered from the TYWE2S module and the circuit board was replaced in the case (with those super-secure screws to prevent any further tampering).

Garage Door Opener WiFi Interface

We wanted to connect our Merlin MR850 garage door opener to our home automation system via our IoT WiFi network. However using our ESP-01S WiFi Interface Module required some additional interface circuitry. The reason is that the MR850 runs on around 33V DC and all I/O signals share that voltage. The MR850 output was 33V when the door was open. The MR850 input had to be connected to 33V, momentarily, to open or close the door. Unfortunately, the 2N7002 input MOSFET on our ESP-01S WiFi Interface Module only handles +/- 20V on the gate. And the 2N7002 output MOSFET on our ESP-01S WiFi Interface Module is active-low and pulls the output to ground, not to 33V. So we added a voltage divider on the input and an LH1510 optocoupler on the output.

Garage Door Opener Modifications

Kettle Power Control Experiment Interface

Improving our home energy efficiency requires maximum solar-power utilisation and minimum grid-power utilisation. This is quite tricky to do in a domestic situation with basic on/off appliances. Note that exporting excess solar-power to the grid is a waste of energy as the feed-in tariffs are so low these days. Of course a lithium battery storage system would solve this problem, but we have not installed one for environmental and cost-recovery reasons (more on that later).

So, as a small experiment, we tried to get our Home Automation System to control our electric kettle, specifically to see if we could get it to use only the excess solar power. The result was a complete success: The kettle now turns on automatically in the morning as the sun rises and solar generation exceeds the base load in our home. Its power consumption is carefully controlled so as not to exceed the available solar power. Its maximum temperature is regulated to 90 degrees C. In fact, it works all day like a solar-powered urn.

To control the kettle we use a MakerFabs WiFi AC Dimmer unit. It is modified to include a Dallas DS18B20, One-Wire temperature sensor cable, which is connected to the Pin 10 (GPIO25) of the ESP32-WROOM-32E module. The unit is configured with an esphome yaml file and it connects to our Home Automation Server over our IOT WiFi network using MQTT.

In order to get the AC Dimmer to output the required power level, we needed to calibrate it and then use a piecewise-linear approximation to set the drive level correctly. The dimmer drive level goes from 90 to 20 degrees, representing the thyristor turn-on phase-angle prior to the next zero-crossing of the AC half-cycle. It automatically turns off at 0 degrees. Note: The thyristor has insufficient voltage to turn on when the drive is below 20 degrees. So the relationship between the required power level and the drive level is therefore not linear. We discovered our kettle draws 1800 W at full power and the minimum power at 20 degrees drive was 60W. Here are our calibration results in five-degree steps:

Power level (Watts): 60, 70, 80, 107, 122, 172, 234, 307, 421, 585, 763, 1005, 1234, 1476, 1800
Drive level (Degrees) : 20, 25, 30, 35, 40, 45, 50, 55, 60, 65, 70, 75, 80, 85, 90

The ESPHome dimmer.yaml file is here.

Uninterruptible Power Supplies

We wanted our home automation system to continue to function through power outages, at least for a few hours. So we needed a battery backed Uninterruptible Power Supply (UPS). The UPS has 40 Ah of 12 V AGM batteries, a 12 V battery charger and a DC/DC Converter Unit. The later provides 53.5 V at 3 A for the Network Video Recorder, 12 V at 2 A for the NBN and IoT WiFi routers and 5.1 V at 2A for the Raspberry Pi Home Automation System Controller. It has a Low Voltage Disconnect circuit to prevent full discharge of the batteries. The charger is tested to handle both the continuous operating current (2 Amps) and the full charging current (8 Amps) when power is restored after the batteries have been discharged.

UPS DC/DC Converter Unit

UPS with Batteries

Power Supply - Charger

Programming

We used an old Raspberry Pi Model 3B as our Home Automation Server. It runs a Mosquitto MQTT broker so that our server and all of our IoT devices can publish and subscribe messages without having to know individual IP addresses. We used the Raspberry Pi to program the ESP-01S WiFi Modules with ESPHome. We then created Python scripts, the main one running as a service on the Raspberry Pi, to gather data and apply home automation rules. A brief sketch of the process is as follows:

Raspberry Pi configuration

Starting with a fresh install of the Raspberry Pi OS with desktop, open a terminal window and run the following commands (you can copy and past them into a terminal window)

#Install the Python IDE and the MQTT broker

sudo apt update

sudo apt -y full-upgrade idle3 mosquitto

#These days Python must run in a virtual environment so that each user gets their own Python libraries

#The virtual environment has to be activated before each use

#When activated, the Linux prompt then changes from:

#<username>@home:~ $ to (env) <username>@home:~ $

#Create a virtual environment for Python called env in your /home/<username> directory

cd ~

python3 -m venv env

#Activate the virtual environment. Use source to ensure environment variables are persistent.

source ~/env/bin/activate

#Now install the latest version of PIP and the required python libraries into your virtual environment

pip3 install --upgrade pip paho-mqtt esphome

#Configure the Python Idle3 shortcut to auto-activate the Python virtual environment

#Click Raspberry | Programming

#Right Click IDLE (using Python-3.11)

#Click Properties | Desktop Entry

#Enter /home/<username>/env/bin/python3.11 -m idlelib.idle

#You no longer have to activate the virtual environment if you run Python Idle3

#The following commands need to be executed as root, so now you become root

sudo -i

#Create the MQTT Broker mosquitto.conf file

#This command puts the following lines, up to EOF, into the file

cat > etc/mosquitto/mosquitto.conf << EOF

# Place your local configuration in /etc/mosquitto/conf.d/

# A full description of the configuration file is at

# /usr/share/doc/mosquitto/examples/mosquitto.conf.example

pid_file /run/mosquitto/mosquitto.pid

persistence true

persistence_location /var/lib/mosquitto/

log_dest file /var/log/mosquitto/mosquitto.log

include_dir /etc/mosquitto/conf.d

listener 1883

allow_anonymous true

EOF

#Start the mosquitto service

systemctl restart mosquitto

#To test MQTT:

#Open a new terminal window for the subscriber

mosquitto_sub -h localhost -p 1883 -t MyTopic

#Open a second terminal window for the publisher

mosquitto_pub -h localhost -p 1883 -t MyTopic -m Hello World

#Hello World should appear in the subscriber window

ESP-01S WiFi Module Programming

ESPHome is an operating system for the ESP-01S (ESP8266 breakout board), and others. It is configured with a YAML file, is compiled and uploaded to the board over the air (Except initially, which must be done via a USB-Serial converter). It boots up the CPU, processes sensors and allows communications via WiFi.

Here is an example ESPHome YAML configuration file for separate ESP-01S WiFI Modules used as inside and outside temperature sensors. They work via an MQTT broker running on the Raspberry Pi. We use simple MQTT topics aligned with the home automation server. E.g. The server subscribes to topic 's15' to read the inside air temperature, which is sent automatically every 60 seconds. The server publishes a '?' message to topic 'p15' to request a update to the the inside air temperature. Here is the ESPHome temp.yaml file:

#This ESPHome temp.yaml file configures a black ESP-01S board fitted 1MB ram and a Dallas DS18B20 temperature sensor

#The temperature sensor is connected via the one-wire bus to GPIO02

#One sensor is for Inside Air Temperatire (IAT) and the other is for Outside Air Temperature (OAT)

#To upload the IAT sensor set the name, zone and IP address of the ESP-01S WiFI Module: esphome -s name iat -s zone 15 -s ip_address 192.168.2.17 run temp.yaml

#To upload the OAT sensor set the name, zone and IP address of the ESP-01S WiFI Module: esphome -s name oat -s zone 16 -s ip_address 192.168.2.18 run temp.yaml

#Set up constants

substitutions:

name: 'iat' #The name of this device

zone: '15' #IAT topic

ip_address: '192.168.2.17' #Static IP address of this device

# name:          'oat'            #The name of this device
# ip_address:    '192.168.2.18'   #Static IP address of this device
# zone:          '16'             #OAT topic

from_server: 'p${zone}' #The topic for receiving messages from the server
to_server: 's${zone}' #The topic for sending messages to the server
state_message: '?'

#Set up core functionality

esphome:

name: ${name} #The name of this device
compile_process_limit: 2 #Reduce the number of cores to use. Necessary for compiling on the RPi 3.

#Set up processor and board

esp8266: #Use the ESP8266 platform

board: esp01_1m #The Black ESP-01 board with 1MB of ram

#Set up WiFi

wifi:

ssid:        <SECTRET>                  #This network is isolated from the Internet, but has an MQTT broker
password:    <SECRET>
manual_ip:
   static_ip: ${ip_address}
   gateway:   192.168.2.1
   subnet:    255.255.255.0

#Enable a fallback access point in case the WiFi connection fails

ap:

ssid: ${name} #Use the device name as the SSID

#Enable the captive portal for the WiFi access point

captive_portal:

#Enable logging

logger:
logs:
mqtt.component: DEBUG

#Enable programming Over The Air

ota:

- platform: esphome

#Enable Message Queuing Telemetry Transport

mqtt:

broker: 192.168.2.2             #The IP Address of the MQTT broker
port: 1883                      #The port number of the MQTT broker
on_message:                     #When a message is received from the MQTT broker

   - topic: ${from_server}       #When a message is received from the server
     payload: ${state_message}   #When a state message is received
     then:

mqtt.publish: #Publish an MQTT message

topic: ${to_server} #Publish a message to the server
payload: !lambda |-

return to_string(id(temp).state);

one_wire:

- platform: gpio
pin: GPIO02

sensor:

- platform: dallas_temp
   id: temp
   address: 0x0200000042495a28
   update_interval: 60s
   on_value:

then:
mqtt.publish: #Publish an MQTT message

topic: ${to_server} #Publish a message to the server
payload: !lambda |-

return to_string(id(temp).state);

Home Automation System Programming

Our Raspberry Pi Home Automation Server is programmed in Python 3. Suffice to say that the scripts subscribe to ESP-01S WiFI Modules, used as sensors, apply home automation rules to the data received and then publish commands to ESP-01S WiFI Modules, or other devices, used to control home appliances. Of course this is all integrated with a Python web server (not described here). The heart to the process is an MQTT library shown below. All you have to do is initialise it and point it to your own callback function to process subscribed topics.

#Home automation system MQTT class library

#For The School Amater Radio Club Network (r) VK3SRC.

#This program:

# Implements a Message Queuing Telemetry Transport (MQTT) client

# Subscribes to WiFi sensor topics

import paho.mqtt.client as mqtt

class Mqtt(object):

def __init__(self, host, port, callback):

#Constructor

self.client = mqtt.Client() #Create an mqtt client

self.client.on_message = callback #Assign a message handler

if (self.client.connect(host, port, 60) == 0): #Connect to the mqtt broker

print('Connected to MQTT broker')

self.client.loop_start() #Start handling mqtt messages

print('MQTT client started')

def subscribe(self, topic):

#Subscribe to an mqtt topic

self.client.subscribe(topic)

def publish(self, topic, message):

#Subscribe to an mqtt topic

self.client.publish(topic, message)

if __name__ == '__main__':

#Test script

def mqttCallback(client, userdata, message):

print(f'MQTT: {message.topic}: {message.payload.decode()}')

mqttIP = 'localhost'

mqttPort = 1883

mqtt = Mqtt(mqttIP, mqttPort, mqttCallback)

mqtt.subscribe('Test1')

mqtt.subscribe('Test2')

mqtt.publish('Test1','Message1')

mqtt.publish('Test2','message2')

Of course, some devices on our IoT network do not communicate via MQTT messaging, notably our solar inverter, smart meter and air conditioners. For these we use the REpresentational State Transfer (REST) architecture. That simply means posting messages to these devices, passing any required parameters in the URL. For example, to get information from our smart meter we post this: http://192.168.2.3/solar_api/v1/GetMeterRealtimeData.cgi?Scope=System. The device responds with a JSON string, which is parsed to recover the desired information.

Efficient Home Energy Utilisation

Part of the reason for building our own Home Automation System was to maximise the efficiency of our home energy usage, partly to reduce energy costs and partly to save the planet. One of the challenges of running a home solar PV system efficiently is minimising the power imported from the grid and using all the available solar power, when it is available, and not exporting it. This is because our utility company export tariffs is so low (0.5 cents per kilowatt hour) and their import tariffs is so high (27 cents per kilowatt hour). As a result we treat any import is a cost and any export is a waste.

Solar Photo-Voltaic Generation System

The installation of a home solar PV system was only the beginning of our journey. We installed a 6 kW (Amateur Radio Friendly) inverter and 8 kW of roof-mounted solar panels. The panels were divided into two Maximum Power Point Tracking (MPPT) strings: East and West, to collect as much insolation as possible, given the available roof space, the single-phase power restriction (6 kW) and shading from nearby trees. We did not install any micro-inverters to reduce Radio Frequency Interference (RFI).

Storage Batteries

We considered installing an integrated battery storage system, but calculated that we would not recover its cost over the lifetime of its batteries. We were also adverse to using environmentally unfriendly and potentially dangerous Lithium batteries. New battery technologies may change our decision in the future.

Hot Water System

We are still considering the use of a heat-pump hot-water system to replace our existing gas hot water system. Apart from the Coefficient of Performance (COP) increase (approximately 2.0 to 3.5 depending on the outside temperature), an electric hot water system can be used as an energy storage system. Unfortunately there is no fine control of the power consumption of the system. Despite government rebates this is still a costly solution.

Another solution was considered: Series electric and gas hot water systems. A conventional electric hot water storage system (with a COP of 1.0) is used as a battery. Its power consumption is finely regulated by an AC dimmer device, to only use excess exported power, as controlled by our home automation system. It feeds the existing gas hot water system, which maintains safe water temperature and has anti-scalding regulators. This system is not conventional, it requires expert installation and certification together with additional non-return and isolation valves.

Lifestyle

To minimise imports we constantly monitor the amount of insolation and our energy usage and have changed our lifestyle, partly, to improve our maximise the efficiency. We:

Postpone, non-time-critical energy usage like clothes washing, ironing and vacuuming to times with high insolation
Heat and cool only essential rooms, not the whole house

Automation

To maximise utilisation of the available solar energy, our home automation system:

Runs intelligent heating and cooling programs to control our reverse-cycle air conditioners.
Runs intelligent kettle-control programs
Permits smart-phone control when at home and when away via a VPN

The key to automatically scheduling the utilisation of the available solar energy is to prioritise and control energy usage. Starting systems and incrementing/decrementing their outputs must be done carefully to avoid costly imports:

Assign increasing export thresholds for automatically starting different systems:

The kettle starts at 60 W export and uses all available export up to 1800 W until boiled
The bedroom aircon starts at 600 W export
The Dining-room/Living-room starts at 1600 W export

Assign export thresholds for automatically incrementing different systems:

For heating:

The bedroom aircon increases 1 degree every 3 minutes when there is 400 W export
The dining-room/living-room aircon increases 1 degree every 3 minutes when there is 500W export

For cooling:

The bedroom aircon decreases 1 degree every 3 minutes when there is 400 W export
The dining-room/living-room aircon decreases 1 degree every 3 minutes when there is 500W export