An internet of things device control method based on master-slave architecture

Abstract

The application relates to a kind of internet of things equipment control methods based on master-slave architecture, comprising the following steps: step 1, obtain the ready state slave machine that can initiate registration;Step 2, obtain the MAC-ID permanent binding relationship and slave identity ID;Step 3, obtain stable conflict-free communication timing and online state awareness ability;Step 4, obtain remote centralized control and real-time state feedback;Step 5, obtain the local autonomous control ability under the condition of network breakage / failure;Step 6, obtain the whole system data consistency and communication recovery.The beneficial effects of the application are:1. Significant comprehensive cost advantage;2. Communication is reliable, and conflict is reduced;3. Decentralized and high expansion system architecture.

Description

Technical Field

[0001] This invention relates to the field of IoT device control and short-range wireless communication technology, specifically to an IoT device control method based on a master-slave architecture. It is designed for resource-constrained microcontroller systems, router-free scenarios, and extremely simple deployment scenarios. It is suitable for centralized control, status monitoring, and local manual control of multiple smart devices in the event of network outages, and can be applied to smart homes, small offices, laboratory equipment management, and other fields. Background Technology

[0002] In practical applications of smart homes and IoT devices, it is often necessary to connect multiple smart switches, sensors, and other devices to achieve centralized control and status monitoring. A common solution is to connect all devices to a home router and then control them via a mobile app or cloud platform. However, this solution has several problems: first, it relies on the external network, making remote control impossible when the network is down; second, after a power outage or restart, devices often require reconfiguration, which is cumbersome; and third, it cannot be used directly in scenarios without a router, such as laboratories or temporary exhibition booths.

[0003] Another common approach is to use ZigBee or Bluetooth Mesh networking, enabling self-organized communication between devices. However, this solution becomes complex when there are a large number of devices, requiring a dedicated gateway device, which raises the configuration and maintenance threshold. For small-scale, low-cost local control scenarios, such as using a single microcontroller to directly control dozens of smart switches, existing solutions are either too cumbersome or lack good support for basic functions such as device reconnection after disconnection and status monitoring.

[0004] In actual engineering implementation, the following specific problems currently exist:

[0005] First, device registration and binding are usually temporary. If the host device loses power or the slave device restarts, the binding relationship is lost, requiring the network configuration process to be re-executed, increasing usage costs.

[0006] Second, when multiple slave devices report data simultaneously, conflicts are likely to occur, leading to lost instructions or delayed responses. Introducing complex conflict avoidance algorithms will increase the amount of code and power consumption.

[0007] Third, when the host or communication link fails, the slave device cannot receive instructions. If the user wants to operate the device manually, the existing solution often does not support it or requires additional hardware modifications.

[0008] To address the aforementioned issues, especially in scenarios where there is no reliance on external networks, a local microcontroller is used as the host, and cost and ease of deployment are required, a simple and practical management method is needed that can enable rapid device registration, power outage reconnection, basic status monitoring, and manual control via local buttons even when the host is offline. Summary of the Invention

[0009] To address the technical problems of wireless control systems for smart devices, such as complex deployment, easy conflicts in multi-node communication, cumbersome device registration, non-persistent identity binding, and weak local autonomous control capabilities, this invention aims to provide a master-slave architecture-based IoT device control method that achieves persistent device binding, reconnection after disconnection, avoidance of basic conflicts, and local manual control functions without increasing hardware costs or development complexity.

[0010] The technical solution of this invention to solve the above-mentioned technical problems is as follows: A method for controlling IoT devices based on a master-slave architecture, which is applied to an IoT system including one master and at least one slave device, includes the following steps:

[0011] Step 1: Through slave hardware initialization and Web network configuration, complete the master parameter configuration and obtain a slave device in a ready state that can initiate registration;

[0012] Step 2: Based on the ready state of the slave device obtained in Step 1, the master device sends a registration request carrying the MAC address. The master device verifies the MAC address and stores it, thus obtaining the permanent MAC-ID binding relationship and the slave device identity ID.

[0013] Step 3: Based on the MAC-ID binding relationship and slave identity ID obtained in Step 2, stable and conflict-free communication timing and online status awareness are obtained by the slave sending heartbeat packets periodically and the master scheduling time slots.

[0014] Step 4: Based on the stable and conflict-free communication timing and online status obtained in Step 3, remote centralized control and real-time status feedback are obtained by issuing commands from the host and executing them on the slave.

[0015] Step 5: Based on the online status awareness capability obtained in Step 3, the slave device automatically switches modes after determining that the master device is offline, thereby obtaining the local autonomous control capability under network outage / fault conditions.

[0016] Step 6: Based on the permanent MAC-ID binding relationship obtained in Step 2 and the local status changes recorded in Step 5, the slave device re-registers and reports data, thus achieving system-wide data consistency and communication recovery.

[0017] In some possible implementation methods, step 1 specifically involves: after the slave device is powered on, initializing the filter step-down circuit, relay module, sensing module, wireless communication module, button module, and main control module; when the host MAC address and communication channel are not configured, automatically starting the Web configuration mode; the user connects to the slave hotspot via mobile phone / computer, completes parameter configuration on the web page, and the slave device restarts to enter normal working mode.

[0018] Step 1: Build a web server based on the WiFi function of the main control module to achieve no programming, no wiring, and no computer configuration, thus lowering the deployment threshold; standardized hardware initialization ensures stable power supply and module compatibility, improving the reliability of device startup.

[0019] In some possible implementations, step 2 specifically involves: the slave device sending a registration request containing its own MAC address to the master device; the master device querying the binding table in non-volatile memory; if the MAC address already exists, the original ID is reused; if it does not exist, a new ID is assigned and the MAC-ID is stored in the binding table; the master device replies with a confirmation ID to the slave device, and the slave device stores its own ID to complete the registration.

[0020] Step 2 utilizes non-volatile memory to ensure that binding information is not lost when power is off, and the MAC address uniquely identifies the device to avoid duplicate network configuration; it achieves "registration upon power-on and self-recovery upon restart", adapting to batch deployment and long-term stable use.

[0021] In some possible implementations, step 3 specifically involves: the slave device sending heartbeat packets to the master device at preset fixed intervals; the master device receiving the heartbeats and updating the online status, and replying with confirmation; the master device polling the status in the order of the registered slave device list, allocating a fixed reporting time slot to each slave device, and the slave device calculating the reporting delay according to the time slot and staggering the sending time.

[0022] Step 3 employs polling scheduling, time slot allocation, and random delay retry to prevent concurrent data conflicts among multiple slave devices from the root cause; the heartbeat mechanism monitors the online status in real time and does not delete the binding when offline, ensuring stable and low-latency communication.

[0023] In some possible implementation methods, step 4 specifically involves: the user issuing control commands through the host serial port / cloud platform; the host sending the commands to the target slave device via unicast; the slave device controlling the relay to operate after verifying that the data is correct, and sending the execution result back to the host; the host updating the device status, completing the closed-loop control.

[0024] Step 4: Customize the application layer bus protocol and checksum verification to reduce the error rate of erroneous commands and data; unicast directional control is precise and efficient, supports up to 254 slave devices, and is suitable for centralized management in various scenarios such as smart homes and small offices.

[0025] In some possible implementations, step 5 specifically involves: determining that the master is offline after the slave's continuous heartbeat times out; automatically switching to local mode, with physical buttons directly controlling the relay's on / off state; the slave equipped with sensors can execute automatic logic; and recording status changes during local operations.

[0026] Step 5 employs a heartbeat timeout-triggered degradation mechanism, enabling offline availability without relying on the external network or adding hardware; independent local button control ensures that the device can still be used normally in the event of a host failure, thus improving system robustness.

[0027] In some possible implementations, step 6 specifically involves: after the host recovers, the slave device resends the registration request; the host identifies the original MAC address and directly restores binding and communication; the slave device reports the local status changes during the offline period to the host; the host updates the binding table and device status, and the system switches back to centralized control mode.

[0028] Step 6 employs persistent binding information and automatic status synchronization to seamlessly restore communication without manual intervention; it ensures data consistency between the master and slave devices, avoids control conflicts, and achieves a complete closed loop of "offline controllability and online synchronization".

[0029] The beneficial effects of this invention are:

[0030] 1. Significant overall cost advantage: In this invention, under stable slave connection scenarios, the power consumption of this system is far lower than that of traditional Zigbee technology. Simultaneously, the master and slave hardware adopt standardized modules, and Web configuration + permanent MAC binding greatly simplifies on-site configuration and subsequent maintenance. Deterministic time slot scheduling also reduces communication overhead and debugging time caused by conflict retransmissions, resulting in a significant reduction in overall cost.

[0031] 2. Reliable Communication and Reduced Collisions: The system utilizes the stable device identity provided by permanent MAC binding to pre-allocate or dynamically negotiate dedicated communication time slots for each slave device. Compared to schemes relying on dynamic discovery or random contention, this scheme fundamentally avoids wireless collisions when multiple slave devices are operating concurrently, achieving deterministic, collision-free time slot scheduling. For communication, a custom application-layer bus protocol is used, coupled with checksum verification, to avoid erroneous data.

[0032] 3. Decentralized and highly scalable system architecture: Supports centralized management of the host and collaborative local autonomous control of the slave devices. Even if the host is offline, the slave devices can still operate independently according to their local logic, avoiding system paralysis due to single point of failure. The host supports up to 254 slave devices. Adding a new slave device only requires completing web configuration; the system automatically assigns it a permanently bound MAC address and a corresponding scheduling time slot. Attached Figure Description

[0033] Figure 1 This is a hardware structure diagram of the slave device;

[0034] Figure 2 Flowchart for device registration and binding;

[0035] Figure 3 This is a diagram of the overall system architecture.

[0036] Figure 4 This is a hardware structure diagram of the slave device in an embodiment;

[0037] Figure 5The following is a flowchart illustrating the overall operation of the system as an example. Detailed Implementation

[0038] The principles and features of the present invention are described below with reference to the accompanying drawings. The examples given are only for explaining the present invention and are not intended to limit the scope of the present invention.

[0039] This invention provides a method for controlling IoT devices based on a master-slave architecture. The method employs a single-hop star master-slave architecture, comprising one master node and several slave nodes. The master node can be uploaded to any device or microcontroller with wireless communication capabilities, serving as the system control core. The slave nodes are intelligent devices integrating filtering and step-down circuits, relay modules, sensing modules, wireless communication modules, button modules, and a master control module, such as… Figure 1 As shown, it illustrates the connection relationships between modules such as filtering and step-down, ESP32 main control, key input, and relay execution. This invention achieves wireless communication between the master and slave devices through a custom application layer bus protocol, without relying on a router. The entire workflow and core mechanism are divided into three parts.

[0040] (a) Device registration and permanent binding mechanism

[0041] This invention designs a fast registration and recovery mechanism based on non-volatile storage and permanent MAC-ID binding. The host maintains a binding table to record the correspondence between the MAC addresses of registered slave devices and their assigned logical IDs. This binding table is stored in non-volatile memory and is not lost after power failure.

[0042] After the slave device powers on, it automatically sends a registration request to the host, which includes its own MAC address. Upon receiving the request, the host performs the following checks: if the MAC address already exists in the binding table, it directly replies with the existing ID corresponding to that MAC address, without assigning a new ID; if the MAC address does not exist, it assigns a new unique ID, stores the MAC-ID pair in the binding table, and then replies with the newly assigned ID. After receiving the registration confirmation, the slave device saves its ID, which is used for all subsequent communications. In this way, even if the host or slave device loses power and restarts, as long as the binding relationship has been established, the slave device can restore its original identity upon reconnecting without reconfiguration. This achieves a seamless reconnection capability of "no loss of identity during power outages and automatic recovery after disconnection." The overall process of this mechanism is as follows: Figure 2 As shown, it illustrates the complete process of slave registration, master table lookup, and ID allocation.

[0043] (II) Communication Scheduling and Conflict Avoidance Methods

[0044] In terms of communication keep-alive, slave nodes send heartbeat packets to the master at preset intervals within their own time slots. To avoid conflicts caused by multiple slaves sending data simultaneously, the master uses a round-robin scheduling method to control the communication rhythm. Specifically:

[0045] The host maintains a list of registered slave devices and sends status query commands to each slave device in the order of the list. Upon receiving a query, the slave device replies with its current status. For scenarios where slave devices proactively report data, such as when a button is pressed, the slave device employs a random delay and retry strategy: it first waits for a random period of time, then listens to see if the channel is idle. If idle, it sends data; if sending fails, it retryes after another random delay, until successful or the retry limit is reached.

[0046] Furthermore, the master can assign a fixed reporting time slot number to each slave device. The slave device calculates its own active reporting delay based on this number, thereby staggering the reporting times of each slave device. When a new slave device joins or a slave device goes offline, the master can dynamically adjust the time slot allocation.

[0047] (III) Dual-mode intelligent control mechanism

[0048] Each slave node integrates a keypad input circuit and an optional sensor module in its hardware. In normal operating mode, the slave node responds to commands issued by the master node to perform relay switching operations. For example... Figure 3 The integrated management platform for user-operated devices uploads control information to the cloud server, which then sends it to the wireless host via wireless communication methods such as MQTT or WIFI to control the slave devices.

[0049] When the slave device detects consecutive timeouts in the master device's heartbeat, it considers the master device offline or experiencing communication abnormalities. At this time, the slave device automatically switches to local control mode: when the user presses a physical button on the slave device, the slave device directly switches the on / off state of the corresponding relay and records the state change; after communication with the master device is restored, the slave device synchronizes the local state change to the master device. If the slave device also integrates a human infrared sensor, automatic control can also be achieved in local mode: for example, automatically turning off all relays after detecting no one for 10 seconds. Figure 3 The system displays a star topology connecting the host to multiple slave devices when the host is offline or experiencing communication issues.

[0050] In summary, this invention constructs a complete low-power IoT communication and control technology solution through three progressively layered mechanisms: device registration and permanent binding mechanism, communication scheduling and conflict avoidance method, and dual-mode intelligent control mechanism, realizing end-to-end collaboration from identity management to communication scheduling and control execution.

[0051] The following specific examples illustrate the detailed process of this invention and the beneficial effects it can achieve.

[0052] (I) Hardware Implementation Examples

[0053] 1. Host Node Hardware: Employs wireless communication equipment or a microcontroller, equipped with a wireless communication module, non-volatile memory, and a serial port interface. The non-volatile memory stores slave MAC-ID binding information, system configuration parameters, etc.; the serial port interface receives user commands, enabling manual management of the host.

[0054] 2. Slave Node Hardware: The slave node is the smart switch, and its core hardware consists of five modules, with the overall structure as follows: Figure 4 The system comprises: 1) a filtering and step-down module, using an LM1117-3.3V voltage regulator chip, along with capacitors and inductors to form a filtering circuit, providing stable power supply to the slave device and filtering power interference with an input of AC220V and an output of DC3.3V; 2) an ESP32 master control module, using an ESP32-S3 chip, responsible for wireless communication, instruction processing, and logic execution, and equipped with a WiFi module to support Web networking; 3) a signal acquisition module, including a button acquisition circuit, a bl0937b power consumption calculation module, and an HC-SR501 human infrared sensor; 4) an execution module, using a relay module to control lights and sockets, controlled by the ESP32 master control module via GPIO ports; and 5) a status indicator module, using LEDs to indicate the slave device status.

[0055] (II) System Operation Flow

[0056] 1. The host node powers on, initializes WiFi and non-volatile memory, loads existing MAC-ID binding information, starts serial port listening, and waits for slave devices to register;

[0057] 2. The slave node powers on, initializes the hardware module, and checks whether the host parameters have been configured. If not, it starts the Web configuration mode. After the user configures the host MAC address and communication channel, the slave restarts and enters normal mode.

[0058] 3. After the slave node enters normal mode, it automatically sends a registration request to the host, which includes its own MAC address and device name.

[0059] 4. The host node receives the registration request, checks whether the MAC address is already bound; if it is already bound, it assigns an existing ID and sends a registration confirmation; if it is not bound, it assigns a new ID, creates and stores the binding relationship, and sends a registration confirmation.

[0060] 5. The slave node receives the registration confirmation, stores its own ID, timeslot number and other parameters, completes the registration, and begins sending heartbeat packets to the host at 15-second intervals;

[0061] 6. The master node receives the slave heartbeat packet, updates the slave's online status, and sends a heartbeat confirmation; at the same time, it allocates time slots according to the number of slaves to avoid communication conflicts among multiple slaves.

[0062] 7. Users send control commands through the host serial port, and the host node sends commands to the corresponding slave device via unicast;

[0063] 8. After receiving the instruction and verifying that the checksum is correct, the slave node performs the relay opening operation and simultaneously sends the execution result back to the master node;

[0064] The system operation process is as follows: Figure 5 As shown, this demonstrates the complete process from power-on registration to normal operation and offline reconnection. If the user presses a local button on the slave device, the slave node detects the button signal, switches the corresponding relay state, and simultaneously feeds back the state change to the master node. If the slave's infrared detection module detects no one for 10 seconds, it automatically shuts down all relays to achieve energy-saving control and feeds back the state to the master node. If the master node does not receive a heartbeat packet from a slave device for more than 45 seconds, it marks the slave device as offline. After retries 3 times and still no heartbeat is received, the binding relationship is maintained. After the slave device reconnects, it automatically sends a registration request, which the master node recognizes and restores communication. The measured overall power saving rate reaches 20% to 30%, with the master device consuming approximately 6.73W of power when running three hardware components and a total standby power consumption of approximately 3.78W. The slave device's static standby power consumption is as low as 0.09W, which is lower than the power consumption of commonly used IoT solutions.

[0065] The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A method for controlling IoT devices based on a master-slave architecture, characterized in that, This method is applied to an Internet of Things (IoT) system comprising one master and at least one slave, and includes the following steps: Step 1: Through slave hardware initialization and Web network configuration, complete the master parameter configuration and obtain a slave device in a ready state that can initiate registration; Step 2: Based on the ready state of the slave device obtained in Step 1, the master device sends a registration request carrying the MAC address. The master device verifies the MAC address and stores it, thus obtaining the permanent MAC-ID binding relationship and the slave device identity ID. Step 3: Based on the MAC-ID binding relationship and slave identity ID obtained in Step 2, stable and conflict-free communication timing and online status awareness are obtained by the slave sending heartbeat packets periodically and the master scheduling time slots. Step 4: Based on the stable and conflict-free communication timing and online status obtained in Step 3, remote centralized control and real-time status feedback are obtained by issuing commands from the host and executing them on the slave. Step 5: Based on the online status awareness capability obtained in Step 3, the slave device automatically switches modes after determining that the master device is offline, thereby obtaining the local autonomous control capability under network outage / fault conditions. Step 6: Based on the permanent MAC-ID binding relationship obtained in Step 2 and the local status changes recorded in Step 5, the slave device re-registers and reports data, thus achieving system-wide data consistency and communication recovery.

2. The IoT device control method based on a master-slave architecture according to claim 1, characterized in that, Step 1 specifically involves: after the slave device is powered on, initializing the filter step-down circuit, relay module, sensing module, wireless communication module, button module, and main control module; when the host MAC address and communication channel are not configured, automatically starting the Web configuration mode; the user connects to the slave hotspot via mobile phone / computer, completes parameter configuration on the web page, and the slave device restarts to enter normal working mode.

3. The IoT device control method based on a master-slave architecture according to claim 1, characterized in that, Step 2 is as follows: The slave device sends a registration request containing its own MAC address to the master device; the master device queries the binding table in the non-volatile memory. If the MAC address already exists, the original ID is reused; if it does not exist, a new ID is assigned and the MAC-ID is stored in the binding table; the master device replies with a confirmation ID to the slave device, and the slave device stores its own ID to complete the registration.

4. The IoT device control method based on a master-slave architecture according to claim 1, characterized in that, Step 3 is as follows: The slave device sends heartbeat packets to the master device at preset fixed intervals; the master device receives the heartbeats and updates the online status, and replies with confirmation; the master device queries the status in the order of the registered slave device list, allocates a fixed reporting time slot to each slave device, and the slave device calculates the reporting delay according to the time slot and staggers the sending time.

5. The IoT device control method based on a master-slave architecture according to claim 1, characterized in that, Step 4 is as follows: The user sends control commands through the host serial port / cloud platform; the host sends the commands to the target slave device via unicast; after verifying that the data is correct, the slave device controls the relay to act and sends the execution result back to the host; the host updates the device status and completes the closed-loop control.

6. The IoT device control method based on a master-slave architecture according to claim 1, characterized in that, Step 5 specifically involves: determining that the master is offline after the slave device's continuous heartbeat timeout; automatically switching to local mode, with physical buttons directly controlling the relay's on / off state; slave devices equipped with sensors can execute automatic logic; and recording status changes during local operations.

7. The IoT device control method based on a master-slave architecture according to any one of claims 1 to 6, characterized in that, Step 6 is as follows: After the host recovers, the slave device resends the registration request; the host identifies the original MAC address and directly restores the binding and communication; the slave device reports the local status changes during the offline period to the host; the host updates the binding table and device status, and the system switches back to centralized control mode.

Images