Home
This wiki summarises a wireless temperature monitoring project using a Waveshare ESP8266 ePaper Development Board and a Wemos ESP32 Development Board, a DS18B20 Thermistor and a Waveshare ePaper Module. Data connectivity is via WiFi interfacing with Google Sheets and Google Apps Script in the Cloud.
The hospitality industry has an ongoing need to monitor conditions of environments in which perishable goods are stored and prepared. Should a freezer door be left ajar it is possible the entire contents may need to be wasted in order to maintain food safety standards.
The objective of this project was to build a small and lightweight temperature sensor device with low current draw and thus longer battery life and easy methods for recharging. The device should operate wirelessly transmitting the ambient temperature to a web server host.
Information and content for this report was gathered from photographs, diagrams and screenshots taken during the project, content sourced from Internet websites and interviews of staff at a Quick Service Restaurant (QSR).
An Agile approach adopted to build a series of prototypes with each device improving incrementally on the previous one. Through use of Agile-type iterative and incremental development rapid prototyping techniques support was gradually added for bringing-up new features and functions and their related hardware components.
**A development sequence and schedule for adding support of new device features was as follows:
- WiFi connectivity
- DS18B20 Temperature Sensor
- ePaper Module
- Google Sheets (POST)
- Google Sheets (JSON)
- Real-time Clock (RTC)
- EEPROM datalogging**
Prototype V1 is a prototype for a Wireless Temperature Monitor in the form of an ESP8266 ePaper Development Board with DS18B20 Temperature Sensor. This ESP8266 ePaper Driver Development Board was purchased from Waveshare which is the same company the ePaper displays and modules used in this project came from. The board together with the DS18B20 Temperature Sensors and the 1.5inch (or 2.13inch) ePaper displays were put together to make Prototype V1 which then served as a learning vehicle for development of features, functions and microcontroller firmware using C language.
**Prototype V1 included the following libraries, features and functionality:
- One-wire protocol and DS18B20 temperature sensor
- SPI and ePaper display
- DS18B20 temperature sensor libraries and functionality
- WiFi and httpsredirect libraries and Google Sheets connectivity88
The ESP8266 ePaper Driver Development Board schematics are available as Open Source Hardware which can provide a basis for the addition of hardware support for ePaper modules to the final custom PCB.
Wireless Temperature Monitor in the form of a Wemos ESP32 Development Board with Waveshare ePaper Module and DS18B20 Temperature Sensor.
Prototype V2 was assembled from a Wemos ESP32 Development Board, DS18B20 Temperature Sensors and ePaper Modules (1.54in and 2.13in) with driver circuitry. Microcontroller firmware from Prototype V1 was modified and improved upon.
**Outcomes from Prototype V2 include the following:
- Transitioned to WiFiClientSecure.h for secure port 403 connectivity.
- Transitioned to httpsredirect version 2 for secure data exchange with Google Sheets. (httpsredirect version 2 was not supported by ESP8266).**
**Third Party Firmware Libraries:
- Library Header (Description).
- WiFiClientSecure.h (WiFi connectivity).
- HTTPSRedirect.h (Google Sheets connectivity).
- ArduinoJson.h (Parsing of return string from server).
- OneWire.h (One-wire protocol interface driver for temperature sensor).
- DallasTemperature.h (Software library for DS18B20 temperature sensor).
- SPI.h (SPI interface driver for ePaper module).
- epd1in54.h (Software library for 1.54inch 200x200 pixel ePaper module).**
An internet-connected device can communicate with a web server or a Cloud service such as Google Sheets. The ability to reliably and securely communicate directly with a third-party Cloud service such as Google Sheets can eliminate the costs of maintaining and securing a dedicated web server.
Uploading of sensor and status data to Google Sheets and subsequent retrieval of date/time and latest device configuration settings required programming in Google Apps Script Editor in the Cloud.
A bar graph may be less misleading than a line graph. This is because line graphs can conceal missing data whereas bar graphs with gaps in data are seen more easily.
With consideration for making improvements to data visualisation, a graph with a horizontal baseline can indicate where a normal or desired data value lies. Any sensor value plotted above the horizontal baseline (pictured below) can be considered to be high and likewise values plotted below the line are low. A further introduction of an additional horizontal line above the normal can indicate the cut-off for the acceptable normal-to-high range. Likewise a third horizontal line below the normal can indicate the cut-off for the acceptable low-to-normal range.
Data tokens encoded in the form of GET parameters appended to a URL string can be intercepted and logged by routers and/or packet sniffing hardware and software located between the device and a cloud service or server. By instead encoding data tokens as POST parameters data interception is more difficult, particularly with an encrypted connection.
End to end encrypted data connections with a cloud service or server assists to mitigate risk of Man-In-The-Middle (MITM) attacks by hackers. The ESP32 module features hardware cryptography functions for enabling strong encryption in device-to-server communications. Unlike the ESP32, the predated ESP8266 module does not feature these security capabilities.
ESP8266 and ESP32 have been integrated with Google Sheets via Google Apps Script in the Google Cloud.
The addition of the 5GHz band could greatly improve signal reliability in noisy environments. Although ESP32 does not currently support the 5GHz band Espressif has stated this feature will likely be included in an ESP32 successor MCU.
Inclusion of an accurate Real-time Clock (RTC) such as the DS3231 may be helpful for maintaining accurate data logging when server connectivity is unavailable. A separate power source for the RTC is optional.
Time synchronisation with atomic clock network time servers via Internet connection.
Local data storage in device non-volatile memory.
OpenSSL certificate generation on the device for use in encrypting connections to a remote server.
For ultra long battery life the addition of low power and sleep modes functionality ould be necessary.
The use of some form of Universal Unique Identifier (UUID) can be helpful for connected master devices or servers to explicitly identify a device as apart from a similar device. The challenge is to enable a device to uniquely identify itself without need for loading of custom firmware parameters or addition of cumbersome jumper switches. A method for this may involve hashing of a combination of the ESP32 MAC address, the device IP address and a one-time seeded pseudo-random variable. At first connection to a server or master device the hashed UUID may be collected and stored as a key for use in identifying the specific device during future connection sessions.
Sensor and status data is only as useful as much as it can be quickly and easily understood in such a way as it can be useful without contributing to a sense of overload and cognitive dissonance. Data visualisation techniques and technologies can be very helpful in this area
N/A
TBA
Loose wires with temporary unfixed connections have the potential to decrease the reliability of a prototype. With wires instead soldered the device is less likely to develop intermittent faults as wires and their connections move around.
While the project would have benefited from more work put into PCB design for manufacture, the mostly programming focused work which was done has proven to be interesting and a valuable learning experience. Serverless, or mostly serverless, applications have the potential to provide highly affordable and scalable Cloud infrastructure for web and mobile applications. This project has also shown that with the ESP32 microcontroller sensor status data can be integrated with Cloud services in a relatively secure way.
N/A
This project was originally completed by Stephen Julian as part of his New Zealand Diploma of Engineering (Electronics) studies.
This GitHub repository delivers on intentions to publish the project work under the MIT Licence.
While this wiki provides a summary, the complete original project documentation is available in Adobe PDF format below:
Julian, Stephen (30/11/2018). Wireless Temperature Monitoring Device - MG6024 Project Report (~58MB PDF, 59 pages)
ESP8266 Files. Retrieved from https://github.com/bizkiwi/wireless-temp-monitor/tree/main/esp8266-files
Google Apps Script Files. Retrieved from https://github.com/bizkiwi/wireless-temp-monitor/tree/main/google-apps-script-files
ESP32 Files. Retrieved from https://github.com/bizkiwi/wireless-temp-monitor/tree/main/esp32-files
Google Apps Script Files. Retrieved from https://github.com/bizkiwi/wireless-temp-monitor/tree/main/google-apps-script-files
Gerber Files. Retrieved from https://github.com/bizkiwi/wireless-temp-monitor/tree/main/gerber-files
BOM Files. Retrieved from https://github.com/bizkiwi/wireless-temp-monitor/tree/main/bom-files
Schematic Files. Retrieved from https://github.com/bizkiwi/wireless-temp-monitor/tree/main/schematic-files
Pick and Place Files. Retrieved from https://github.com/bizkiwi/wireless-temp-monitor/tree/main/pickandplace-files