Hardware

The hardware group has designed a remote temperature and humidity monitoring equipment that can be utilized in any working environment for real-time detecting of ambient temperature and humidity.

Master stm32

The design of this system is based on the stm32 103 series of development board. For the configuration and programming of STM32 microcontroller, we acquired hardware and software tools to set up the development environment. Basically, we first ensured that the STM32CubeMX and corresponding compilers, such as IAR Embedded Workbench or Keil MDK, were installed. Subsequently, the temperature and humidity sensor was connected to the GPIO pin of the STM32 microcontroller.
In order to read the sensor data, we configured the relevant GPIO pins by using the STM32CubeMX to simplify this process. Further, by selecting the target microcontroller model, inputting the correct mode and enabling the associated peripheral clock, we finally generated the code and exported it as a HAL library project. With the generated project, we were able to program to initiate the relevant peripherals, such as GPIO and USART for the main function. Meanwhile, the baud rate and data format of the USART were set up and adapted for communication with the temperature and humidity sensor.

DHT11 Digital Temperature and Humidity sensor

DHT11 digital temperature and humidity sensor is a temperature and humidity composite sensor with calibrated digital signal output, which is controlled by an 8-bit single chip computer to control a resistive humidity sensing element and an NTC temperature measuring element. DHT11 also uses the single bus protocol, but the protocol is slightly different from the single bus protocol of DS18B20. Compared with DS18B20, which can only measure temperature, DHT11 can detect both temperature and humidity, but DHT11's accuracy and measurement range are lower than DS18B20, and its temperature measurement range is 0~50 ℃, with an error of ±2 ℃. The Humidity is measured in the range of 20%-90% RH. Relative Humidity refers to the percentage of water vapor pressure in the air to saturated water vapor pressure, with an error of ±5% RH. The DHT11 circuit is relatively simple, only connecting the Dout pin to an I/O of the MCU, but the pin needs to pull up a 5K resistor, and the supply voltage of the DHT11 is 3~5.5 V.

Figure 1 Picture of DHT11

Protocol and data format

DHT11 uses the single bus protocol to communicate with the single chip microcomputer. After the single chip microcomputer sends a reset signal, DHT11 switches from the low-power mode to the high-speed mode. After waiting for the end of the host reset, DHT11 sends a response signal and pulls up the bus to prepare for data transmission. The complete data is 40 bits at a time, and is transmitted in the order of high bits first and low bits last.
The data format is: 8 bit humidity integer data + 8 bit humidity decimal data + 8 bit temperature integer data + 8 bit temperature decimal data + 8 bit checksum, a total of 5 bytes (40 bits) of data. Since the DHT11 resolution can only be accurate to the ones place, the fractional part of the data is all 0. The checksum is the sum of the first four bytes of data. The purpose of the checksum is to ensure the accuracy of data transmission.
The DHT11 triggers temperature and humidity collection only after receiving the start signal. If the host does not send a reset signal, the DHT11 willnot take the initiative to collect temperature and humidity. When the data collection is complete and there is no start signal, the DHT11 automatically switches to the low speed mode.
Note: Because DHT11 timing requirements are very strict, in order to prevent interruptions from interfering with the bus timing when operating the timing, the total interrupt is turned off first, and then turned on only after the operation is complete.

Operation sequence

1. Sending a reset signal by the host
The initialization process of DHT11 is composed of reset signals and response signals. First, the host pulls down the bus for at least 18 ms, and then pulls up the bus. The delay is 20~40 μs, and the middle value is 30 us, at which time the reset signal is sent.

Figure 2 Sequence chart of signals

2. Sending a response signal by DHT11
After detecting the reset signal, DHT11 will trigger a sampling, and pull down the bus 80us to send out the response signal, telling the host that the data is ready; The DHT11 then pulls up the bus 80us and afterwards the data is transferred. If the response signal is high, DHT11 initialization will fail.
After the reset signal is sent, if the bus is detected to be low, count it every 1 us until the bus is high, and calculate the low level time; When the bus is pulled high, the recount detects a high level of 80us. If a high level of 80us is detected after the response signal, it is ready to start receiving data. In fact, the response time of DHT11 is not the standard 80us, and there is often an error. When the response time is between 20 and 100 us, the response can be identified as successful.

3. Data transmission
The DHT11 starts transmitting data after the bus is raised by 80us. Each bit of data starts with a 50us low time slot, telling the host to start transmitting one bit of data. DHT11 defines whether the data bit is 0 or 1 by the length of the high level. When the bus is pulled up after the 50us low level time slot, the high level lasts 26~28us, indicating the data "0"; If the value lasts for 70us, the value is 1.
When the last bit of data is transmitted, the DHT11 pulls down the bus 50us, indicating that the data transmission is complete, and then the bus is pulled up by the pull-up resistance to enter the idle state.

Figure 3 Clock signal

WIFI module

The ESP32's WiFi module, called the ESP32-Wroom-32, is a low-power Wi-Fi and Bluetooth module. It supports IEEE 802.11b /g/n/e/i, IEEE 802.15.4, BLE 4.2, dual-mode Bluetooth, and low power mode. The module is powered by a 32-bit Xtensa® Dual-Core LX6 processor with Dual cores, each capable of 160MHz and up to 240MHz.
In addition, it has 520KB of SRAM, supporting a variety of peripherals such as ADC, DAC, I2C, I2S, SPI, UART, CAN, IR, PWM, GPIO, etc., and is compatible with a variety of programming languages such as C, C++, Python, Java, Lua, etc. The module has 4MB of Flash storage and can support a variety of applications.
In terms of WiFi function, the ESP32 WiFi module can be used as wireless access point (AP), or ….. (STA) (site) or AP+STA modes. As an AP, it can be connected by four STAs.
The hardware team will use this module to transmit the temperature and humidity information to our attached server, and then we can display our temperature and humidity information in real time on the website through the front-end design.

Communication transmission

Message Queuing Telemetry Transport (MQTT) is a lightweight message transfer protocol developed by IBM. Compared with other communication protocols, MQTT is more suitable for the Internet of Things scenario.
In MQTT, there are three main roles:

Figure 4 Server transport architecture

The messages transmitted by MQTT are divided into two parts: Topic (distinguishing between different messages) and payload (message content).
MQTT protocol, an application layer protocol, adopts the Publish/Subscribe mode. It is based on TCP protocol which is the transport layer protocol delivering the messages between devices. The design of this hardware group uses the server of EMQX, which is an open source MQTT message server based on Erlang/OTP platform and is widely used in the construction of Internet of Things platforms in various industries around the world. The goal of the designis to achieve highly reliable MQTT connections that carry massive iot terminals and support low-latency message routing between massive iot devices.

Figure 5 Background of server management

Based on the construction of EXMQ server, MQTT protocol can be directly connected across LAN to realize the application of Internet of Things technology. We directly use the official free server, and the relevant compliance configuration is as follows:
broker: broker-cn.emqx.io
TCP port: 1883
WebSocket port: 8083
SSL/TLS port: 8883
WebSocket Security port: 8084
CA certificate file: broker.emqx.io-ca.crt

MQTT publishing and subscription patterns
MQTT is based on the publish/subscribe model for communication and data exchange, which is fundamentally different from the request/reply model of HTTP.
The subscriber subscribes to the topic to the message server,??? and when the subscription is successful, the message server forwards the message under the topic to all subscribers.
Topics use "/" as the separator to distinguish between different levels, topics that contain wildcards "+" or "#" are also called topic filters, and topics that do not contain wildcards are called topic names.

The MQTT server consists of the following core components:
Communication interface: Used to establish a connection between client devices, receiving and sending messages among clients. Communication interfaces isimplemented using the traditional TCP/IP stack or other protocols such as WebSockets.
Subscription management system: Responsible for maintaining user subscription relationships. When a client subscribes to a topic, the subscription management system associates that topic with the client's connection so that when there is a new message, it can be sent to the client subscribed to that topic.
Message queue: Used to store messages about to be sent. When a server receives a message from a client, it can store the message in a message queue and then send it one by one to clients that have subscribed to the related topic.
Persistent storage: Used to store client subscription relationships, message queues, and other important status information. Persistent storage can be implemented using databases, file systems, etc., to ensure that the server can be restored to its previous state upon restart.

Figure 6 MQTT protocol

The operation mechanism of MQTT server contains the following steps:
Establishing a connection: When a client device establishes a connection with an MQTT server, a CONNECT message is sent to the server. After receiving the CONNECT message, the server authenticates and processes the client information, and then returns the CONNACK message to the client.
Publish and subscribe: Clients can publish messages to the server and subscribe to topics of interest. When a client publishes a message, the server stores the message in a message queue and sends the message to clients that have subscribed to the topic.
Transmission and acknowledgement: The server sends messages to subscribers one by one and waits for confirmation from subscribers. After receiving the message, the subscriber replies a confirmation message to the server to indicate that the message was successfully received.
DISCONNECT: When the client device disconnects from the server, the disconnect message is sent to the server. After receiving the DISCONNECT message, the server processes the disconnect and cleans up the status information.
MQTT servers can be in the following states:
Connection status: The server establishes and maintains a connection with the client. In the connected state, the server can receive messages from the client and forward the messages to the subscriber.
Offline: The server is disconnected from the client, but maintains the client subscription relationship and message queue. When the client connects to the server again, the server can resume the previous subscription relationship and message queue.
Publishing status: After receiving the messages published by the client, the server stores the messages in the message queue and sends them to the clients that subscribe to the related topics in turn. In the publish state, the server handles the distribution and acknowledgement of messages.
The MQTT server can be extended in the following ways:
Security enhancement: Data encryption is implemented through the use of TLS/SSL protocols to protect data security during communication. At the same time, authentication and access control mechanisms can be added to ensure that only legitimate devices and applications can connect and send messages.
High availability and load balancing: Enable server redundancy and load balancing by deploying multiple MQTT servers. Use load balancers to allocate client connections to ensure server availability and performance.

Overall architecture

This project is based on the embedded device monitoring ambient temperature and humidity and maintaining communication via WIFI. There are three parallel tasks based on the FREERTOS operating system as the theme architecture. These three tasks are scheduled by the operating system to achieve parallel multi-task function. In this way, the reception of information will not be affected by internal software.
In addition, in terms of data reception, using validation protocols common in the market, we can automatically identify header subject files that belong to us while retaining data frames. Moreover, the selected MQTTX server transmitter has good multi-device adaptability and can send and receive data on web in windows or mac systems.

Physical result

Sending end:

Figure 7 Temperature and humidity iot system based on STM32

Figure 8 OLED display and OLED display

Receiving end:

Figure 9 Web page receiving messages (EMXQ-based iot platform)