CN112243034A

CN112243034A - Multi-machine communication system

Info

Publication number: CN112243034A
Application number: CN202011105522.XA
Authority: CN
Inventors: 蔺想红; 皮晓妹; 杜攀高
Original assignee: Northwest Normal University
Current assignee: Northwest Normal University
Priority date: 2020-10-15
Filing date: 2020-10-15
Publication date: 2021-01-19

Abstract

The invention discloses a multi-machine communication system, which comprises: the system comprises a cloud server and an ESP32 module, wherein the cloud server is connected with an ESP32 module through a wireless network, a data receiving unit, a data storage unit, a data recording unit and a data return unit are arranged in the cloud server, data collection and processing are achieved through the cloud server, the ESP32 module is connected with a plurality of terminal devices through serial ports or I2C, data of the terminal devices are collected, and control instructions are sent to the terminal devices. The invention solves the problem that the existing intelligent terminal cannot be controlled in a centralized way.

Description

Multi-machine communication system

Technical Field

The invention relates to the technical field of communication, in particular to a multi-machine communication system.

Background

Wi-Fi devices are the basic configuration for current home networking. Wi-Fi-based network-enabled smart devices already have many solutions, but the main drawback at present is that many smart devices are on the domestic market, and a complete and mature technical specification has not yet been formed for a while. Meanwhile, each manufacturer does not have a uniform standard interface protocol to follow, and different brands of equipment use different control modes. Each intelligent device in the family can not be connected to a unified control port, centralized management and control are carried out, and intelligent management is achieved.

Disclosure of Invention

Therefore, the invention provides a multi-machine communication system to solve the problem that the existing intelligent terminal cannot be controlled in a centralized manner.

In order to achieve the above purpose, the invention provides the following technical scheme:

the invention discloses a multi-machine communication system, which comprises: the system comprises a cloud server and an ESP32 module, wherein the cloud server is connected with an ESP32 module through a wireless network, a data receiving unit, a data storage unit, a data recording unit and a data return unit are arranged in the cloud server, data collection and processing are achieved through the cloud server, the ESP32 module is connected with a plurality of terminal devices through serial ports or I2C, data of the terminal devices are collected, and control instructions are sent to the terminal devices.

Further, the data receiving unit of the cloud server is used for creating a UDP connection and establishing an interface for receiving and sending UDP data, so that the system can be used at a later stage; the data storage unit stores a processing result on the established storage area after receiving the data, and respectively stores different information according to different types of the received data; the data recording unit records data for subsequent maintenance and management.

Furthermore, the data recorded by the data recording unit mainly includes two types, one type is data which may be used later and stored by using a MySQL database, and the other type is a log file, and a generated simple log file can facilitate an administrator to view the running state of the server.

Further, the cloud server initializes UDP communication first, establishes an empty user list, and the user list is used to store basic information of each control terminal at a later stage, block and wait for UDP data, establishes a thread and processes each time UDP communication, and establishes a thread to process the data specially every time data is received.

Furthermore, each array is used for storing data in the user list, the user list is stored in a list library database or a file form of the control terminal, and the writing difficulty of the program is simplified by using a simple array.

Further, after the cloud server creates the user list, the cloud server waits for UDP data, monitors a UDP port and waits for data, performs preliminary calibration and verification on the data after receiving the data, and preliminarily verifies whether the first byte is 0XFE or not. If so, a new thread is created in the next step to process the received data, otherwise, the method returns to the previous step to continue waiting for UDP data.

Further, the creation of the thread and the data lock establish a thread if the system detects the receipt of a data, and process the received data in the thread. The main function of the data lock is to provide list service for users and prevent errors of user lists caused by simultaneous reading and writing among threads.

Further, the cloud server judges whether a sender of the currently received data exists in the user list, and if yes, the next step is carried out to judge a receiver; if not, the user is added into the user list, a data lock needs to be acquired before the control terminal is added into the control terminal list, and the data lock needs to be released after the task of adding the control terminal is completed.

Further, the cloud server judges whether the receiver is a server or a control terminal, and if the receiver is sent to other control terminals, the server plays a role in data transfer and recording; before data transfer, whether a receiver is correct or not is judged, namely whether a terminal exists in a traversal control terminal list or not is judged, if yes, data is transferred, and a thread is finished after the data is transferred; if there is no recording error, the thread is ended, and the receiving mode server processes according to different data.

Furthermore, the UDP communication follows rules, data communicated each time is composed of a plurality of bytes, the first byte is used for preliminary verification, when the server receives the data, the data is not needed by the program through the byte, the data is needed to enter the next step, and if not, the data is directly discarded; the second byte is used for judging a receiver, and the data is divided into data which is sent to a server and forwarded to other control terminals; the third byte is 0, 1, 2 and 3, which respectively represent the change of the description information of the control terminal, the information sent to the server, the acquisition of a control terminal list and the active disconnection of the control terminal.

The invention has the following advantages:

the application discloses multimachine communication system is connected with a plurality of terminal equipment through ESP32 module, and the ESP32 module carries out data transmission through wireless network and cloud server, uses ESP 32's wireless function to connect to the UDP server of building oneself, can handle a plurality of UDP connections simultaneously through the processing mode of multithreading on the server, has realized the communication between client and the server and the communication between client and the client. Thereby realizing the most basic functions of the system. And secondly, a certain data format is specified for the communication process, all the devices can communicate with the server through the network according to the data format, and the server can process new data only by expanding different types of devices and data. The centralized control of a plurality of terminal devices is realized.

Drawings

In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the embodiments or the prior art will be briefly described below. It should be apparent that the drawings in the following description are merely exemplary, and that other embodiments can be derived from the drawings provided by those of ordinary skill in the art without inventive effort.

The structures, ratios, sizes, and the like shown in the present specification are only used for matching with the contents disclosed in the specification, so as to be understood and read by those skilled in the art, and are not used to limit the conditions that the present invention can be implemented, so that the present invention has no technical significance, and any structural modifications, changes in the ratio relationship, or adjustments of the sizes, without affecting the effects and the achievable by the present invention, should still fall within the range that the technical contents disclosed in the present invention can cover.

Fig. 1 is a flowchart illustrating a working process of a cloud server of a multi-machine communication system according to an embodiment of the present invention;

fig. 2 is a method for determining a receiver by a cloud server of a multi-machine communication system according to an embodiment of the present invention;

fig. 3 is a UDP communication data format rule diagram of a cloud server of a multi-machine communication system according to an embodiment of the present invention;

FIG. 4 is a flowchart illustrating control of ESP32 modules in a multi-machine communication system according to an embodiment of the present invention

Detailed Description

The present invention is described in terms of particular embodiments, other advantages and features of the invention will become apparent to those skilled in the art from the following disclosure, and it is to be understood that the described embodiments are merely exemplary of the invention and that it is not intended to limit the invention to the particular embodiments disclosed. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present invention.

Examples

The embodiment discloses a multi-machine communication system, which comprises: the system comprises a cloud server and an ESP32 module, wherein the cloud server is connected with an ESP32 module through a wireless network, a data receiving unit, a data storage unit, a data recording unit and a data return unit are arranged in the cloud server, data collection and processing are achieved through the cloud server, the ESP32 module is connected with a plurality of terminal devices through serial ports or I2C, data of the terminal devices are collected, and control instructions are sent to the terminal devices.

The ESP32 module can be used as a module only responsible for communication, and the ESP32 provides communication with the control module through I2C, SPI, serial port and the like, and the communication module is used as a wireless communication component of the control module. However, the ESP32 can be a controller, which has a maximum main frequency of 240M and an on-chip Flash of 4M, which can basically handle most of the non-computing tasks, and the ESP32 module also implements a low power consumption mode, which is very advantageous for some monitoring sensors, such as sensors that only need to wake up to collect data under certain conditions, and in this embodiment, the ESP32 is directly used as a main control of a control terminal, which is responsible for all data receiving processing and corresponding control actions.

The data receiving unit of the cloud server is used for creating a UDP connection and establishing an interface for receiving and sending UDP data so that the system can be used at a later stage; the data storage unit stores a processing result on the established storage area after receiving the data, and respectively stores different information according to different types of the received data; the data recording unit records data for subsequent maintenance and management. The data recorded by the data recording unit mainly comprises two types, one type is data which may be used later and stored by using a MySQL database, the other type is a log file, and the generated simple log file can facilitate an administrator to check the running state of the server.

The cloud server attempts to handle concurrent services in the system using a simpler multi-threaded approach, creating and processing a thread each time a UDP communication is made. In the embodiment, the server receives the frequency of data, the design is added to make the system easier in the later period, and the multithreading can save more server resources only when the expense for creating the threads is far less than the expense for on-site tasks.

Referring to fig. 1, the cloud server initializes UDP communication, establishes an empty user list, and the user list is used to store basic information of each control terminal at a later stage, block and wait for UDP data, establishes a thread and processes each time UDP communication, and establishes a thread to process the data specifically every time data is received.

Socket programming of UDP communication, UDP is a basic communication mode of the system, and all data receiving and sending in the system are realized based on UDP communication. If the system is under the cloud server, the problem of opening the port needs to be considered, firstly, a firewall of the server needs to be configured, and the port to be communicated at the later stage of the system is opened; secondly, a series of components of the security policy of the server are configured, and all communication ports are opened.

The user list is created and maintained, each time an array is used for storing data, the user list should be stored in a database or file form as a better solution, and the verification of the model needs to use a simple array to simplify the writing difficulty of the program. The basic format definition of the list data of the control terminal we use in the system:

and after the cloud server creates a user list, waiting for UDP data, monitoring a UDP port and waiting for the data, and performing primary calibration verification on the data after receiving the data, wherein the primary verification is to judge whether the first byte is 0 XFE. If so, a new thread is created in the next step to process the received data, otherwise, the method returns to the previous step to continue waiting for UDP data. Thread creation and data locking, creating a thread if the system detects receipt of a data, and processing the received data in the thread. The main function of the data lock is to provide list service for users and prevent errors of user lists caused by simultaneous reading and writing among threads.

Judging whether a sender of the currently received data exists in the user list or not, and if so, entering the next step to judge a receiver; if not, the user is added into the user list, a data lock needs to be acquired before the control terminal is added into the control terminal list, and the data lock needs to be released after the task of adding the control terminal is completed. Referring to fig. 2, it is determined whether the receiving side is a server or a control terminal, and if the receiving side is a server or a control terminal, the server plays a role of data transfer and recording; before data transfer, whether a receiver is correct or not is judged, namely whether a terminal exists in a traversal control terminal list or not is judged, if yes, data is transferred, and a thread is finished after the data is transferred; if there is no logging error, the thread is ended. The receiving mode server processes according to different data.

As shown in fig. 3, substantially all data transmitted between networks follows the rules shown in fig. 3. Each time data is communicated, it is made up of several bytes (a minimum of 3 bytes).

The first byte is used for preliminary verification, namely, when the server receives the data, the data is not needed by the program through the byte, the data is needed to enter the next step, and the data is not directly discarded.

The second byte is used for judging the receiving party, and the data is divided into data which is sent to the server and forwarded to other control terminals. If the second byte is 0, the data is handed to the server for processing; if not 0, it means that the data is to be sent to other control terminals for processing, and the server only plays a role of forwarding the data in this step.

In the above two cases, for different third bytes and data after the third bytes, when the receiving party is the server, the third bytes are 0, 1, 2 and 3, which respectively represent changing the description information of the receiving party, sending the information to the server, acquiring the list of the control terminal, and actively disconnecting the control terminal.

Changing own data description information, and storing the description information from the fourth byte, wherein the structure of the description information is defined as follows:

the format of the data is reserved when the information is sent to the server, and the data format is not defined explicitly. On the server, the code can directly output the data in the form of character strings.

And acquiring a control terminal list, wherein the third byte is 2 to represent the acquisition control terminal list, and the communication process only has three bytes. After the system receives this signal, the server will start sending back a list of control terminals in a defined data format to the control terminal that initiated the request signal.

The control terminal will actively disconnect, and the third byte is 3, which means that the control terminal will actively disconnect at this time, and this communication process also has only three bytes. After receiving the signal, the server first acquires the data lock, deletes the control terminal from the control terminal list after acquisition, releases the data lock, and then ends the thread performed at this moment.

The ESP32 module, as a control core of the terminal, theoretically needs to be responsible for receiving data from two aspects, namely, collecting data of the sensor on one hand and receiving data from UDP on the other hand; and processing the data sent by the UDP and the data to be sent by the UDP, and finally controlling the OLED to output prompt information to facilitate the test. In functional implementation, the first part is about control of the network, ESP32 is to access the designated Wi-Fi network as a Station, and then configure UDP communication of ESP 32; the second part is the initialization of the display device, and the external display device is driven to display related information or provide an intuitive output path for debugging.

Referring to fig. 4, the writing of the multitask single chip microcomputer program can be conveniently realized by using an ESP32 integrated system-on-chip FreeRTOS. The OLED is initialized at first, the OLED display screen of 0.9 inch is adopted as an output display module in the design of the embodiment, the SPI and IIC communication is supported by the OLED display screen module of 0.9 inch generally, and the ESP32 can be used as a single chip microcomputer with less IO to save IO resources to a great extent by using the two communication modes.

And starting a Station mode, namely initializing a Station working mode of the ESP32, so that the ESP32 is accessed into the network as a routed terminal. Initialization of the Station mode of operation in ESP32 requires initialization of the NVS storage system because hardware information about the network needs to be read from the NVS partition.

In the connection use of the UDP, after the Station mode is enabled, the creation of the UDP connection is started, so that the device may be connected to the server, the creation of the UDP connection may use socket network programming similar to Linux, or may use UDP network functions encapsulated by esp-idf, and these two methods have no difference essentially, and both can implement the network connection required in the design, and the second method is used in this embodiment. When using the latter, a receive callback function needs to be registered in the process of creating a UDP connection, and this function is called after the UDP receives data. The specific registration is as follows:

// register receive callback function

udp_recv(my_udp_pcb,my_udp_recv,NULL)；

my _ UDP _ recv is a registered callback name, and my _ UDP _ pcb is a data structure for UDP control.

The receive callback function is called after each UDP receives data, and processes the received data in the receive callback function in such a way that corresponding information is displayed by the OLED in the embodiment. And sequentially sending test data, namely test information for changing description information, sending information to a server, acquiring a client list and actively disconnecting the connection.

Although the invention has been described in detail above with reference to a general description and specific examples, it will be apparent to one skilled in the art that modifications or improvements may be made thereto based on the invention. Accordingly, such modifications and improvements are intended to be within the scope of the invention as claimed.

Claims

1. A multi-machine communication system, the system comprising: the system comprises a cloud server and an ESP32 module, wherein the cloud server is connected with an ESP32 module through a wireless network, a data receiving unit, a data storage unit, a data recording unit and a data return unit are arranged in the cloud server, data collection and processing are achieved through the cloud server, the ESP32 module is connected with a plurality of terminal devices through serial ports or I2C, data of the terminal devices are collected, and control instructions are sent to the terminal devices.

2. The system of claim 1, wherein the data receiving unit of the cloud server is configured to create a UDP connection, and to establish an interface for UDP data reception and transmission for later use by the system; the data storage unit stores a processing result on the established storage area after receiving the data, and respectively stores different information according to different types of the received data; the data recording unit records data for subsequent maintenance and management.

3. A multi-machine communication system as claimed in claim 2, wherein the data recorded by the data recording unit includes two types, one type is data that may be used later stored by using MySQL database, and the other type is log file, and a simple log file is generated to facilitate the administrator to view the operation status of the server.

4. A multi-machine communication system as claimed in claim 1, wherein said cloud server first initiates UDP communication, creates an empty user list, said user list later storing basic information for each control terminal, blocks waiting for UDP data, creates a thread for each UDP communication and processes the UDP data, and creates a thread for processing the UDP data every time it receives the UDP data.

5. A multi-machine communication system as claimed in claim 4, wherein the user list uses one array at a time to store data, the user list is stored in the form of a library database or file of the list of control terminals, and simple arrays are used to simplify the difficulty of writing programs.

6. The system of claim 4, wherein the cloud server creates the user list, waits for UDP data, listens to UDP ports and waits for data, performs a preliminary calibration and verification on the data after receiving the data, the preliminary verification is that the first byte is determined to be 0XFE, if so, a new thread is created in the next step to process the received data, otherwise, the previous step is returned to continue to wait for UDP data.

7. A multi-machine communication system as claimed in claim 4, wherein the creation of threads and data locks, if the system detects that a data is received, creates a thread in which the received data is processed, the primary function of the data locks being to provide list services to the user and to prevent errors in the user list between threads due to simultaneous read and write problems.

8. The system of claim 4, wherein the cloud server determines whether a sender of currently received data is present in the user list, and if so, proceeds to the next step to determine the receiver; if not, the user is added into the user list, a data lock needs to be acquired before the control terminal is added into the control terminal list, and the data lock needs to be released after the task of adding the control terminal is completed.

9. The system of claim 4, wherein the cloud server determines whether the receiving party is a server or a control terminal, and if the receiving party is sent to another control terminal, the server performs data forwarding and recording; before data transfer, whether a receiver is correct or not is judged, namely whether a terminal exists in a traversal control terminal list or not is judged, if yes, data is transferred, and a thread is finished after the data is transferred; if there is no recording error, the thread is ended, and the receiving mode server processes according to different data.

10. A multi-machine communication system as claimed in claim 4, wherein the UDP communication follows rules, each communication data is composed of several bytes, the first byte is used for preliminary verification, when the server receives the data, the byte is passed to determine whether the data is needed by the program, the data is needed to go to the next step, otherwise, the data is directly discarded; the second byte is used for judging a receiver, and the data is divided into data which is sent to a server and forwarded to other control terminals; the third byte is 0, 1, 2 and 3, which respectively represent the change of the description information of the control terminal, the information sent to the server, the acquisition of a control terminal list and the active disconnection of the control terminal.