WiFi Thermostat - ESP8266 / ESP32

WiFi thermostat project was created as a 1:1 clone to the Ethernet thermostat project with identical functionality. It uses the popular IoT microcontrollers ESP8266 and ESP32 from Espressif Systems, which cover the operation of the WiFi thermostat and bring a number of options to extend the original concept. For this reason, ESP8266 and ESP32 do not use advanced web server implementations, which can be used e.g. asynchronous web server ...

• ESP8266 / ESP32 microcontroller (generic chip / Devkit board)
• DS18B20 sensor
• 4,7 kohm pullup resistor
• electromagnetic relay SRD-05VDC-SL-C / SSR relay OMRON G3MB-202P

HTML pages running on ESP8266 / ESP32:

• / - root page containing the form, current logic output for the relay, current and target temperature, hysteresis
• /action.html - processes values from the form, writes them to the emulated EEPROM memory, redirects the user back to the root page
• /get_data.json - distributes data on current temperature, reference temperature and hysteresis to a third party (computer, microcontroller, other client ...) in JSON format - can be used with an example JSON client that can send data to MQTT Broker, for example to home automation

From side of client --> server architecture used in project WiFi thermostat, there is used identical HTML code of individual subpages is used as in the case of the Ethernet thermostat. ESP works as a web server and receives requests from clients in the LAN, to which it can respond to the request with HTML code / JSON data structure and also run the "backend" code to perform the functionality. Temperature measurement and system logic (decision logic for relay control) are performed independently of the web server and client connections.

The web interface of the WiFi thermostat allows you to visualize the current measured temperature, the current set values for the target (reference) temperature and hysteresis. The set values can be changed via the HTML form, where they can be overwritten in the input fields and, by confirmation, start the redirection and subsequently the "backend" code, which permanently stores the data in the EEPROM memory. Because ESP microcontrollers do not have EEPROM memory, the part of flash memory on which the EEPROM is software emulated is used.

Writing to the EEPROM is realized only when datas are sent via HTML form, which extends the life of the emulated EEPROM. Emulated EEPROM have lifespan like flash memory, that means up to 10,000 transcripts. If identical data is entered via the form as entered in the EEPROM, the data will not be rewritten again, because function EEPROM.update() will read offset contents first. The Arduino Core, in which the implementation is designed, allows you to emulate 4 to 4096 B of flash memory on the EEPROM.

The ESP8266Webserver for ESP8266 and Webserver for ESP32 libraries allow easy retrieval of arguments and values from an HTTP POST request. The original Ethernet thermostat uses only HTTP GET request for data transfer due to the difficulty of taking arguments due to the unavailable implementation in the Ethernet library. The Ethernet thermostat uses a parser designed by me, which parses the GET request based on the key and value. In the figure below, identical request processing with two keys: fname, fname2 and processing of their assigned values into a variable.

Since the WiFi thermostat is distributed only in the form of compiled firmware (.bin), it was necessary to find a way to configure its WiFi adapter. I used the WiFiManager library, which is fully compatible for ESP8266 and ESP32. WiFiManager allows you to run the microcontroller in AP mode (access point) if it does not connect to the preset WiFi network within a certain time. After connecting to the WiFi network, the microcontroller switches to STA (station) mode and the application program - WiFi thermostat - starts executing.

The application program is delayed until the WiFi adapter has a valid configuration, i. until it is connected to a WLAN. WiFiManager also stores this information in non-volatile memory after writing the SSID and password. The next time the microcontroller is started, WiFiManager will use this data to connect to the WLAN. When the microcontroller is in AP mode, it starts broadcasting the WiFi_TERMOSTAT_AP SSID without a password as an open network (it can also be secured with a password with WPA / WPA2-PSK encryption). After connecting the client (computer, smartphone) to the access point, the client obtains an IP address from the network range 192.168.4.0/24.

192.168.4.1 has a standard microcontroller, which is also equipped with a web interface - Captive Portal to which it redirects HTTP client communication. The call to open the Captive Portal will also be made available to the client on the smartphone by notification. In the web interface it is possible to select an available WiFi network within range of the microcontroller and configure it. After a successful connection to the WiFi network and switching the microcontroller to STA mode, the WiFi thermostat obtains an IP address from the standard range of the WiFi network to which it is connected via DHCP.

The web interface of the thermostat is available at this IP address, where it can be configured. As the IP address changes after exceeding the Lease Time DHCP pool, the thermostat is often available at different IP addresses. For this reason, an implementation was created for the mDNS record, which allows access to the thermostat via a domain name that is mapped to the currently assigned IP address by the DHCP service.

When the thermostat is started, the stored data in the emulated EEPROM memory is automatically checked. If there are no valid data (float / int) on the predefined offsets, the initial setting of the control data is performed -> target temperature 20.25 ° C, hysteresis 0.25 ° C, so that the thermostat can operate immediately.

WiFi thermostat is based on the original firmware for Ethernet thermostat. The goal of the thermostat has always been to control the output automatically based on the measured, target temperature and hysteresis. In the summer months, however, it was useless to power the relay to control the boiler. For this reason, an experimental implementation was created which, in addition to the standard automatic control, also offers a manual mode by which the output can be hard-coded on / off.

Advanced HTML pages in experimental implementation of WiFi thermostat:

• /zap.html - permanent output on in manual mode
• /vyp.html - permanently turn off output in manual mode
• /automat.html - change mode to automatic (uses hysteresis and target temperature)
• /manual.html - change mode to manual (permanent output control ON / OFF hard)

This type of control is also suitable for permanent output shutdown and operation of the WiFi thermostat in the manner of a thermometer, for example in summer, or it can also be used for air conditioning (cooling), but with inverted relay logic, i. relay on when output is on, relay on when output is off. This implementation does not include an mDNS record. The implementation also has a modified logic compared to the standard firmware, as it must also distinguish the operating mode of the logic - automatic / manual mode.

Language mutations
WiFi thermostat has a standard and extended firmware with mDNS recording also available in English, including output to a UART monitor. Experimental firmware with manual mode is not available in English.

WiFi Thermostat project is available on Githube, where you will find complete instructions for downloading the firmware and uploading it to the ESP8266 / ESP32 microcontroller via the ESPTOOL tool: https://martinius96.github.io/WiFi-termostat/. The thermostat is currently in the latest planned version - 1.0.4. There are also implementations for the project for identical microcontrollers / Arduino + Ethernet Wiznet called JSON client.

JSON client can connect to the thermostat, obtain the current control data, the current temperature in JSON format. It can parse data and then transfer it to predefined topics on MQTT Broker. The Slovak public MQTT Broker for developers IoT Industries Slovakia is used as a model. It is possible to enter a subscription for individual melters and implement e.g. to home automation and Loxone, Domoticz, Hassio systems for visualization of the current temperature also in its own dashboard with recording, e.g. Grafana.