Read this in other languages: English | 简体中文
- IoT
- 1. MQTT - A Communication Protocol
- 2. Zero-Configuration Networking
- 3. Thing Model
- 4. IoT Gateway
- 5. Data Processing
- 6. Setting Up the Hardware Development Environment
- 7. Remote Control: Building a Networked Smart Light
- 8. How Smart Lights Perceive Light
- 8.1. Communication Technology
- 8.2. Selecting Development Board
- 8.3. Preparing MicroPython Environment
- 8.4. Building the Hardware Circuit of Light Sensor
- 8.5. Writing Bluetooth Programs
- 8.6. Verifying the Light Sensor
- 8.7. Gateway System Architecture
- 8.8. Northbound MQTT Connection to Cloud Platform
- 8.9. Creating Light Sensor Devices on Cloud Platform
- 8.10. Product Networking Development
- 8.11. Deploying Software on Raspberry Pi
- 8.12. Setting Up Scene Linkage
- 9. Smart Speaker: Voice Control
From the perspective of the overall architecture, the Internet of Things (IoT) can be divided into three layers:
The first is the device layer, which refers to various hardware devices. Device components include sensors (such as devices that measure parameters like temperature, humidity, and light intensity) and actuators (such as relays that control circuit on/off, motors that realize object movement, etc.). IoT devices involve not only the development of traditional embedded systems but also the consideration of communication technologies such as Wi-Fi, Bluetooth, and cellular networks.
The second is the network layer, which mainly focuses on the communication protocols between devices and IoT platforms. IoT network communication is still based on the Internet, so the underlying layer is still the TCP/IP protocol. In applications, what you need to understand and master more are specific network protocols, such as HTTP, MQTT, and AMQP.
The third is the application layer, which is where specific business logic is implemented. In addition to facing issues such as server frameworks, database systems, and message queues like ordinary Internet backends, IoT systems first need to handle massive amounts of data. This can be divided into three aspects:
- Data storage, such as the selection of NoSQL databases and time-series databases.
- Data processing, such as the different characteristics of big data processing frameworks like Spark and Flink, and the applicable scenarios of batch processing and stream processing.
- Data analysis, such as various machine learning algorithms and even the application of AI.
MQTT (Message Queuing Telemetry Transport) is a messaging protocol based on the publish/subscribe programming model of binary messages. First proposed by IBM, it has now become an OASIS standard. Due to its simple specification, it is very suitable for IoT scenarios that require low power consumption and limited network bandwidth, such as:
Remote sensing data Automotive Smart home Smart city Medical care
Since the IoT environment is very special, MQTT follows the following design principles:
- Streamlined, without adding dispensable functions.
- Publish/Subscribe (Pub/Sub) mode to facilitate message transmission between sensors.
- Allow users to dynamically create topics with zero operation and maintenance costs.
- Minimize the transmission volume to improve transmission efficiency.
- Take into account factors such as low bandwidth, high latency, and unstable networks.
- Support continuous session control.
- Understand that the client's computing capacity may be very low.
- Provide quality of service management.
- Assume that data is unknown, do not force the type and format of transmitted data, and maintain flexibility.
With the MQTT protocol, devices can easily connect to IoT cloud services, manage devices, process data, and finally apply to various business scenarios, as shown in the figure below:
In the MQTT protocol based on the publish/subscribe model, there are three roles: Publisher, Broker, and Subscriber. The publisher publishes messages to the broker, and the broker forwards these messages to the subscribers. Usually, the client acts as the publisher and subscriber, and the server acts as the broker. However, in practice, the server may also actively publish messages or subscribe to topics, acting as a client temporarily.
For easy understanding, MQTT transmitted messages can be simplified into two parts: Topic and Payload:
Topic: the message topic. After a subscriber subscribes to a topic from the broker, once the broker receives a message with the corresponding topic, it will forward the message to the subscriber. Payload: the message payload, the part that the subscriber really cares about in the message, usually related to the business.
A program or device that uses the MQTT protocol. It can:
- Open a network connection to the server.
- Publish application messages to other relevant clients.
- Subscribe to request to receive relevant application messages.
- Unsubscribe to remove the request to receive application messages.
- Close the network connection to the server.
A program or device that acts as an intermediary between the client sending messages and the subscribed client. It can:
- Accept network connections from clients.
- Accept application messages published by clients.
- Process client subscription and unsubscription requests.
- Forward application messages to eligible subscribed clients.
- Close network connections from clients.
Install hbmqtt, an open-source MQTT Broker software based on the Python language.
hbmqtt is implemented based on Python3, so the pip3 tool is used here.
pip3 install hbmqtt
After installation, we can use the two command-line tools hbmqtt_sub and hbmqtt_pub provided in hbmqtt. From the names, you should be able to see that hbmqtt_sub can act as a subscriber; hbmqtt_pub can be used as a message publisher.
As for the broker between the subscriber and the publisher (i.e., the MQTT Broker), we use the free and open online Broker service provided by Eclipse. Open the link, and you can see information about the ports, which support both encrypted and unencrypted methods, and also have implementations based on Websocket, which is very beneficial for applications based on front-end web pages.
mqtt.eclipse.org
This is a public test MQTT broker service. It currently listens on the following ports:
1883 : MQTT over unencrypted TCP
8883 : MQTT over encrypted TCP
80 : MQTT over unencrypted WebSockets (note: URL must be /mqtt )
443 : MQTT over encrypted WebSockets (note: URL must be /mqtt )
First, use the unencrypted method on port 1883, then determine a topic for message transmission. The topic defines the category of the message and is used for message filtering. The topic can be set to "/learn/iot".
Enter the following command in the terminal interface of the computer to subscribe to messages of this topic:
hbmqtt_sub --url mqtt://mqtt.eclipse.org:1883 -t /learn/iot
To learn about the execution details of some commands, you can add the "-d" parameter to the above command.
Start another terminal interface and publish a message with the topic "/learn/iot" through hbmqtt_pub:
hbmqtt_pub --url mqtt://mqtt.eclipse.org:1883 -t /learn/iot -m Hello,World!
With Eclipse's open Broker as the "broker", the message is transmitted to the subscriber we run through hbmqtt_sub. The figure below shows the running results on my terminal interface, and a complete message transmission process is completed in this way.
[2020-11-25 11:02:06,375] :: INFO - Finished processing state new exit callbacks.
[2020-11-25 11:02:06,375] :: INFO - Finished processing state connected enter callbacks.
Hello,World!
MQTT is a lightweight network protocol, which is also an important reason for its popularity in IoT systems. After all, a large number of IoT devices have limited computing resources and low network bandwidth.
This "lightweight" is reflected in two aspects. On the one hand, MQTT messages adopt a binary encoding format instead of the text representation like the HTTP protocol.
It can make full use of byte bits, and the protocol header can be very compact, thereby minimizing the amount of data that needs to be transmitted over the network.
For the MQTT protocol, one byte can represent a lot of content. The picture below shows the format of the MQTT fixed header, which has only 2 bytes:
The first byte is divided into the high 4 bits (4～7) and the low 4 bits (0～3); the low 4 bits are the packet identifier bits, where each bit can represent different meanings; the high 4 bits are the identifier bits for different packet types.
The second byte represents the total number of bytes of the packet header and the message body, where the highest bit indicates whether a third byte exists to represent the total number of bytes together with the second byte.
If there is a third byte, its highest bit indicates whether there is a fourth byte to represent the total number of bytes together with the second and third bytes. And so on, there may also be a fourth byte and a fifth byte. However, the part representing the number of bytes of the variable header and the message body can only have up to five bytes, so the maximum packet length that can be represented is 256MB.
For example, a CONNECT type packet requesting to establish a connection requires 14 bytes for the header; a PUBLISH type packet for publishing messages has a header of only 2～4 bytes.
On the other hand, the lightweight is reflected in the very simple design of the specific interaction process of messages, so the types of interactive messages of MQTT are also very few. The functions and message flow directions of different MQTT packet types are summarized below.
MQTT version 3.1.1 defines a total of 14 types of packets, corresponding to values from 1 to 14 in the high 4 bits of the first byte respectively.
The MQTT protocol also pays great attention to the optimized design of low power consumption, which is mainly reflected in the optimization of energy consumption and the number of communications.
For example, the MQTT protocol has a Keepalive mechanism. Its role is to allow both parties to find out in time when the connection between the Client and the Broker is interrupted, and re-establish the MQTT connection to ensure the reliable transmission of topic messages.
The working principle of this mechanism is: both the Client and the Broker judge whether there are messages transmitted between them within a period of time based on the time length determined by Keepalive. This Keepalive time length is set when the Client establishes a connection. If no new data packets are received by both parties beyond this time length, the connection is judged to be disconnected.
Although Keepalive requires data packets to be transmitted within a period of time, in reality, the Client and the Broker cannot transmit topic messages all the time. What should we do?
The solution of the MQTT protocol is to define two message types: PINGREQ and PINGRESP. Neither of them has a variable header and a message body, that is, they are only 2 bytes in size. The Client and the Broker can meet the requirements of the Keepalive mechanism by sending PINGREQ and PINGRESP messages respectively.
If we have to send messages regularly in such a "silly" way, it would be a waste of power and network resources. Therefore, if there is data transmission between the Client and the Broker within the Keepalive time length, the Keepalive mechanism will also count it, so there is no need to send PINGREQ and PINGRESP messages to judge.
In addition to the Keepalive mechanism, the repeated topic feature in MQTT 5.0 can also help us save network resources.
When a Client repeatedly sends a message on a topic, it can set the topic name length to 0 from the second time, so that the Broker will automatically process the message according to the previous topic. This situation is very common for sensor devices, so this feature is of great practical significance in work.
In addition to limited computing resources and low network bandwidth, IoT devices also often encounter unstable network environments, especially in scenarios such as mobile communication and satellite communication. For example, for shared bikes, if the message that the user has locked the bike cannot be reliably uploaded to the server, the billing will be wrong, resulting in user complaints.
The MQTT protocol is designed with 3 different QoS (Quality of Service) levels. You can choose flexibly according to the scenario to ensure reliable communication in different environments.
These 3 levels are:
- QoS 0: indicating that the message is received at most once, i.e., the message may be lost but will not be duplicated.
- QoS 1: indicating that the message is received at least once, i.e., the message is guaranteed to be delivered but may be duplicated.
- QoS 2: indicating that the message is received exactly once, i.e., the message is delivered once and only once.
The processes of QoS 0 and QoS 1 are relatively simple; while QoS 2 has a relatively complex process to ensure reliable transmission of once and only once. Under normal circumstances, QoS 2 has 4 interactions: PUBLISH, PUBREC, PUBREL, and PUBCOMP.
In "abnormal cases", the sender needs to resend the message. For example, if no PUBREC message is received within a period of time, the PUBLISH message needs to be sent again. However, it should be noted that the "Duplicate" flag in the message should be set to 1 at this time so that the receiver can process it correctly. Similarly, if no PUBCOMP message is received, the sender needs to send the PUBREL message again.
It is necessary to verify whether the Client has the permission to access the MQTT Broker. To control Client access, MQTT provides a username/password mechanism. During the connection establishment process, it can filter valid connection requests by judging the correctness of the username and password.
However, relying solely on this mechanism cannot guarantee data security during network communication. Because in the plaintext transmission mode, not only device data but even usernames and passwords may be intercepted and leaked by others from the network, so others can pretend to be legitimate devices to send data. Therefore, we also need the support of communication encryption technology.
The MQTT protocol supports SSL/TLS encrypted communication. After adopting SSL/TLS encryption, MQTT will be converted to MQTTS. This is a bit similar to the relationship between HTTP and HTTPS.
Changing "mqtt://" to "mqtts://" and the port to 8883 allows you to connect to the open Broker provided by Eclipse using SSL/TLS encrypted communication. However, I recently found that its SSL certificate has expired, so the connection will fail.
After successful network configuration, networking is also required, that is, allowing the device to obtain its own IP address, and at the same time knowing the IP address of the router in the local area network and the IP address of the DNS (Domain Name System). The device's own IP address is its unique identifier in the TCP/IP network; the router can correctly forward the device's data packets; and the DNS server can help resolve the destination IP address that needs to be set in the data packets.
Zero-configuration networking automates these tasks, achieving the goal that users do not need to operate manually, and even enabling this device to work with other devices in the network.
This automatic allocation function is implemented based on the DHCP (Dynamic Host Configuration Protocol) protocol.
DHCP uses a server-client architecture model.
- When a device (your mobile phone) accesses the network, it acts as a DHCP client and requests a network address.
- Then the DHCP server (the Wi-Fi router at home) will select an IP address from the address pool and assign it to the device.
- When the device no longer uses this IP (you take your mobile phone out / turn on flight mode to sleep), the DHCP server will reclaim it and then assign it to other devices in need (your newly bought tablet) for use.
The communication between the DHCP server and the device is completed through the UDP transport protocol. Because UDP has an advantage: it does not need to establish a connection in advance. The port number of the DHCP server is 67, and the port number of the device is 68. Their general interaction process is as follows:
- Discover: The device sends a DHCP Discover message by broadcasting, indicating that it needs to obtain an IP address.
- Offer: After receiving this message, the DHCP server will send a DHCP Offer message as a response. The message contains the IP address assigned by the DHCP server to the device, and also includes its own IP address.
- Request: After receiving the DHCP Offer message, the device will broadcast a DHCP Request message to formally request this IP address from the DHCP server.
- ACK: After receiving the DHCP Request message, the DHCP server will judge whether the server IP is consistent with its own address. If consistent, it will immediately reply a DHCP ACK message to the device and specify the lease term of the IP address.
- Decline: After receiving the DHCP ACK message, the device will also verify whether the IP address is available. If there is an address conflict, it means it is unavailable, and it will send a DHCP Decline message; if there is no address conflict, it is available, and the device will use this IP address according to the lease term.
- Release: When the device no longer uses this IP address, the device can release it by sending a DHCP Release message. In this way, the DHCP server can reassign this IP address.
Principle of Mobile Phone Screen Projection Technology
UPnP is short for Universal Plug and Play, and its goal is to achieve plug-and-play of network devices.
UPnP consists of six parts: device addressing, device discovery, device description, device control, event notification, and HTML-based description interface. Among them, device addressing is also implemented based on DHCP. If there is no DHCP server in the network, UPnP will specify an IP address based on its own AutoIP method.
Overall, UPnP is a framework system composed of multi-layer protocols. Each layer is based on the adjacent lower layer and is also the basis of the adjacent upper layer until it reaches the application layer. You can refer to the picture below.
The third layer (counting from the bottom up) is based on HTTP, HTTPU, and HTTPMU protocols, belonging to the transport protocol layer. The transmitted content is "encapsulated" and stored in a specific XML file. The SSDP (Simple Service Discovery Protocol) protocol used for device and service discovery transmits data based on XML.
The SSDP protocol provides both service discovery and device discovery functions. We can query devices based on the M-SEARCH method in SSDP, and then obtain the description information of the device's service capabilities based on the device's response. At the same time, the device can notify the network of its service capabilities through the NOTIFY method.
With the UPnP protocol, your device can be automatically discovered and used. This automated process is usually summarized by a proper noun, that is, zero-configuration networking. To sort out, zero-configuration networking includes three technical cores:
- Automatically assign IP addresses to network devices, generally involving the DHCP protocol and AutoIP method;
- Automatically discover and resolve devices, mainly based on the SSDP protocol;
- Automatically propagate and discover the services provided by various network devices, mainly based on the SSDP protocol.
Then, what open-source code implementations can you use to implement the UPnP protocol? A popular open-source library is libupnp, which is used by Xiaomi TV boxes. Another option is the GUPnP project, which includes several different sub-projects, such as the GSSDP project that implements the SSDP protocol.
In addition to the UPnP protocol, zero-configuration networking can also use other protocol standards, such as mDNS and DNS-SD protocols.
AirDrop of Apple devices discovers other Apple devices on the network through the Bonjour service. This Bonjour service is a specific implementation of the mDNS protocol and the DNS-SD protocol.
The mDNS (Multicast DNS) protocol allows devices to set a local domain name in the local DNS namespace. Later, when asked, it broadcasts the IP address via UDP so that other devices can find it. mDNS can be simply understood as the local network version of DNS.
The DNS-SD (DNS Service Discovery) protocol is generally used together with mDNS. It uses three DNS protocol record types to define the protocol content: PTR record, SRV record, and TXT record. It provides service discovery functions, similar to the SSDP protocol mentioned above.
This layer of specification in the Internet of Things is Thing Specification Language, or TSL for short. The entity model in the Internet of Things described using TSL is the "Thing Model", also called "Product Model" or "Data Template".
The thing model also stipulates the functions of the device. Newly added devices, if they are of the same type, will follow the same function definitions, have the same characteristics, and implement the same services in design and research and development. For example, all lights should have two states: "on" and "off".
Based on common abstract features, the thing model allows applications to no longer target individual product devices, but adopt the same processing logic for the same type of devices. This is actually the basis of application development. When the value of a smoke sensor triggers an alarm, even for smoke sensor products of different brands, the application can perform the same processing and judgment on the value; otherwise, numerical analysis has to be carried out separately.
In addition, in the thing model, the functions of the device are clearly defined, which can facilitate the realization of scene linkage. For example, a light sensor can send commands to control the brightness of a smart light, or commands to turn it on and off, based on the light intensity.
It is generally defined through three functional elements: Property, Event, and Action.
Property: Describes a certain state of the product device during operation.
The characteristic of a property is that it is readable and writable. That is to say, the application can read the property and also set the property of the device. We can also see similar examples, such as the temperature and humidity properties of environmental monitoring equipment.
Event: Information, alarms, faults, etc., generated by the product device during operation.
If a smart light has a low voltage during operation, or a hardware failure occurs, the networked device can send this information out to notify you to deal with it in a timely manner.
An event can contain multiple output parameters. Unlike properties, events are reported by the device and cannot be set by the application. Similar examples include messages when a task is completed, alarms for pollutants detected by environmental sensors, etc.
Action: The capability or method that the device can be called, also known as Service.
Actions are sent by the application to the device, and the device can return results to the application. From the perspective of the execution process, actions can be further divided into synchronous and asynchronous. This depends on whether the action is a time-consuming operation and the dependence of other application logic on the action execution result.
Compared with properties, actions are control commands sent by the application to the device; actions can implement more complex business logic through a single instruction, such as lowering the temperature by 5 degrees, rotating the camera by 30°, etc.
As a modeling language, the data of the thing model also has different data types. They mainly include six types:
- Boolean: Binary variables that are either true or false. For example, the switch function has only two states: on and off.
- Integer: Integer variables that can be used for linear adjustment. For example, the brightness of a light is an integer range.
- String: Functional points expressed in string form. For example, the position of the light.
- Float: Functional points with floating-point precision. For example, the voltage range is 0.0 - 24.0.
- Enum: Custom finite set values. For example, the color of the light includes white, red, yellow, etc.
- Timestamp: UTC timestamp of String type.
For integer and floating-point values, their units can be percentage, voltage, meter, etc. The thing model is generally used to describe model elements in JSON format. JSON is a data format often used in Web development. Compared with XML, it is more concise, clear, and lightweight.
According to the three elements of property, event, and action, let's see how to define the thing model of a smart light in JSON format.
The switch property of a smart light is a Boolean type and is a necessary property. It can be expressed in JSON as follows:
{
"id": "power_switch", //Unique identifier of the property
"name": "Light Switch", //Name
"desc": "Control the on/off of the light", //Detailed description of the property
"required": true, //Indicates whether this property must be included, yes
"mode": "rw", //Property mode, r for read, w for write
"define": {
//Definition of property values
"type": "bool", //Value type, Boolean
"mapping": {
//Meaning of specific values
"0": "Off", //0 means the light is off
"1": "On" //1 means the light is on
}
}
}The voltage of the smart light is a value that needs to be monitored. When the voltage is low, this event can be reported. This event has one parameter, the voltage value, with a data type of float. The JSON format description is as follows:
{
"id": "low_voltage", //Unique identifier of the event
"name": "LowVoltage", //Event name
"desc": "Alert for device voltage is low", //Description of the event
"type": "alert", //Event type, alarm
"required": false, //Indicates whether this property must be included, no
"params": [
//Event parameters
{
"id": "voltage", //Unique identifier of the event parameter
"name": "Voltage", //Name of the event parameter
"desc": "Current voltage", //Description of the parameter
"define": {
//Definition of parameter values
"type": "float", //Value type, floating-point number
"unit": "V", //Unit of the value, volt
"step": "1", //Step size of value change, 1
"min": "0.0", //Minimum value of the value
"max": "24.0", //Maximum value of the value
"start": "1" //Starting value of the event
}
}
]
}The definition of actions is similar to the definition process of properties and events. Combining all properties, events, and actions, we get the complete JSON format of the smart light thing model:
{
"version": "1.0", //Model version
"properties": [
//Property list
{
"id": "power_switch", //Light switch property
"name": "Light Switch",
"desc": "Control the on/off of the light",
"required": true,
"mode": "rw",
"define": {
"type": "bool",
"mapping": {
"0": "Off",
"1": "On"
}
}
},
{
"id": "brightness", //Brightness property
"name": "Brightness",
"desc": "Light brightness",
"mode": "rw",
"define": {
"type": "int",
"unit": "%",
"step": "1",
"min": "0",
"max": "100",
"start": "1"
}
},
{
"id": "color", //Light color property
"name": "Color",
"desc": "Light color",
"mode": "rw",
"define": {
"type": "enum",
"mapping": {
"0": "Red",
"1": "Green",
"2": "Blue"
}
}
},
{
"id": "color_temp", //Color temperature property
"name": "Color Temperature",
"desc": "Light temperature (warm/cool)",
"mode": "rw",
"define": {
"type": "int",
"min": "0",
"max": "100",
"start": "0",
"step": "10",
"unit": "%"
}
}
],
"events": [
//Event list
{
"id": "status_report", //Running status report
"name": "DeviceStatus",
"desc": "Report the device status",
"type": "info",
"required": false,
"params": [
//Event parameter list
{
"id": "status",
"name": "running_state",
"desc": "Report current device running state",
"define": {
"type": "bool",
"mapping": {
"0": "normal",
"1": "fault"
}
}
},
{
"id": "message",
"name": "Message",
"desc": "Some extra message",
"define": {
"type": "string",
"min": "0",
"max": "64"
}
}
]
},
{
"id": "low_voltage", //Low voltage alarm event
"name": "LowVoltage",
"desc": "Alert for device voltage is low",
"type": "alert",
"required": false,
"params": [
{
"id": "voltage",
"name": "Voltage",
"desc": "Current voltage",
"define": {
"type": "float",
"unit": "V",
"step": "1",
"min": "0.0",
"max": "24.0",
"start": "1"
}
}
]
},
{
"id": "hardware_fault", //Hardware fault event
"name": "Hardware_fault",
"desc": "Report hardware fault",
"type": "fault",
"required": false,
"params": [
{
"id": "name",
"name": "Name",
"desc": "Name like: memory,tf card, censors ...",
"define": {
"type": "string",
"min": "0",
"max": "64"
}
},
{
"id": "error_code",
"name": "Error_Code",
"desc": "Error code for fault",
"define": {
"type": "int",
"unit": "",
"step": "1",
"min": "0",
"max": "2000",
"start": "1"
}
}
]
}
],
"actions": [], //Action list
"profile": {
//Product parameters
"ProductId": "8D1GQLE4VA", //Product ID
"CategoryId": "141" //Product category ID
}
}When creating a model, there are two modes: copy and inherit. The difference between these two creation modes is mainly reflected in the model relationship.
The "copy" mode is similar to value copy in programming languages. The newly created model has exactly the same three elements as the copied model, and the two models are independent of each other, with no mutual influence on model changes.
The "inheritance" mode is the inheritance concept in object-oriented programming. The newly created model is defined as a "sub-model", and the inherited model is defined as a "parent model".
The specific characteristics of inheritance are:
- The sub-model inherits all elements of the parent model, and the inherited elements cannot be modified.
- The sub-model can be inherited again, supporting multi-layer inheritance relationships.
- The sub-model can create independent elements, but the newly added elements in the sub-model cannot have the same names as the elements in all upper-level parent models.
- When the elements in the parent model change, the elements inherited from the parent model in the sub-model change synchronously to keep consistent with the parent model.
The device shadow is used to cache device status. Applications can directly obtain the last updated property value of the device through the device shadow without accessing the device every time. When the device is online, it can directly obtain application instructions; after the device is offline, it can actively pull application instructions when it goes online again.
Imagine a scenario. If the device network is stable, many applications request to obtain the device status, and the device needs to respond multiple times according to the requests, even if the response results are the same. However, the device itself may have limited processing capacity and cannot actually handle multiple requests. With the device shadow mechanism, the device only needs to actively synchronize the status to the device shadow once, and multiple applications can request the device shadow to obtain the device status, achieving decoupling between applications and the device.
For example, the switch status property of a smart light can be controlled remotely by a mobile App, and you can also change it locally through a physical switch. If the network is unstable, the status stored on the platform may be inconsistent with the real status of the light, leading to errors in subsequent operation logic.
The device shadow can achieve consistency of properties between the server side and the device side through two-way synchronization, thereby solving this problem.
The thing model is a digital model of a physical entity, but it is mainly aimed at application development and device interoperability in the Internet of Things.
If this model is further developed to integrate various data of the physical entity, it will be a faithful mapping of the physical entity. At the same time, during the entire life cycle of the physical entity, it will evolve together with the entity, accumulate various information and knowledge, and promote the optimization of the physical entity. Such a model is the digital twin of the physical entity.
When BLE, ZigBee, and LoRa devices communicate with the gateway, the gateway needs to parse the data based on open or internal private protocols; then the gateway organizes the data using the connection protocol with the cloud platform to complete data transmission.
This process naturally requires the gateway device to support different communication technologies.
The northbound interface needs to access the Internet, so common choices include RJ45 Ethernet port, optical fiber interface, Wi-Fi, and cellular network modules such as 4G and NB-IoT.
The southbound interface is used to connect IoT devices. In addition to interfaces for wireless technologies such as BLE, ZigBee, LoRa, and Wi-Fi, common ones also include RJ45 Ethernet port, RS232, RS485 and other wired interfaces used on Industrial Personal Computers (IPCs).