A hotel room multi-wireless node reliable and safe communication control method and system based on an OpenHarmony edge RCU
Patent Information
- Application Number
- CN202611291655.8
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2026-08-25
- Publication Date
- 2026-10-16
AI Technical Summary
[0008]针对现有酒店客房控制系统在多无线节点控制过程中存在的控制链路可靠性不足、执行结果不可确认、云端命令重传易导致重复执行、无线节点在线状态判断不准确、安全认证机制不完善以及断云情况下数据不可追踪等问题,本发明提出一种基于OpenHarmony边缘RCU的酒店客房多无线节点可靠安全通信控制方法及系统
[0044]1. This invention uses an edge RCU running the OpenHarmony operating system as the local control center in the guest room, uniformly carrying local user interface, wireless node communication, scene control, encryption authentication, local database, and cloud communication functions. Compared with traditional guest room central control or single cloud control methods, this invention can complete control decisions, status maintenance, and anomaly handling locally in the guest room, reducing dependence on cloud networks.
Smart Images

Figure CN122934255A_ABST
Abstract
Description
Technical Field
[0001] This invention belongs to the technical fields of smart hotels, IoT room control, edge computing, wireless communication, information security and terminal operating system applications. Specifically, it relates to a reliable and secure communication control method and system for multiple wireless nodes in hotel rooms based on OpenHarmony edge RCU.
[0002] Specifically, this invention relates to a technical solution for local control, status acquisition, scene linkage, encryption authentication, log recording, and cloud-based collaborative management of multiple wireless nodes, including temperature and humidity nodes, NFC access control nodes, fan coil unit nodes, touch nodes, motor nodes, relay nodes, infrared nodes, and smoke alarm nodes, in a hotel room setting, utilizing an edge RCU running the OpenHarmony operating system. The solution also involves technologies such as wireless control message generation based on the HRCP protocol, payload encryption, message authentication, control confirmation, execution result feedback, transaction deduplication, local autonomy in cloud outages, and cloud recovery and retransmission. Background Technology
[0003] With the development of the Internet of Things, edge computing, wireless communication, and smart terminal operating systems, hotel room control systems are gradually evolving from traditional wired bus control methods towards intelligent, wireless, and cloud-based collaborative approaches. Existing hotel room control solutions typically use room controllers, smart switches, air conditioning controllers, door locks, curtain controllers, doorplates, and human body sensors to control functions such as lighting, air conditioning, curtains, access control, and power supply, and achieve remote management through mobile applications or cloud platforms.
[0004] In existing technologies, there are various solutions related to hotel room control and smart hotels. For example, a dynamically configurable smart hotel RCU system can achieve cross-configuration and scene linkage of room equipment; a bus-type room control system typically controls equipment such as lighting, air conditioning, and curtains through a main control box, communication bus, and multiple room actuators; an MQTT-based access control solution can achieve access control message push and remote status reporting; and an NFC room card authentication solution focuses on room card identification and cloud authentication. Furthermore, CN109901410A discloses an IoT smart hotel overall solution system, which includes a LAN switch, an IoT self-check-in terminal, an IoT management and control system, an IoT check-in guidance terminal, an IoT hotel management and control terminal, a deep learning system, a router, an IoT room central control terminal, a cloud server, and mobile applications. It connects to devices such as smart power switches, smart switches, air conditioning control switches, room door locks, room doorplates, curtain touch switches, and human body sensor power switches through the IoT room central control terminal to achieve self-check-in, remote room control, room mode control, and overall intelligent management of the hotel.
[0005] However, the existing solutions still have certain shortcomings. First, some solutions focus more on the overall hotel business process, mobile application services, self-check-in, access control, or wired / bus-type guest room central control structures, and do not adequately disclose the low-latency reliable control mechanism between multiple wireless nodes within the hotel guest room. Second, in scenarios with unstable wireless links or high-frequency control of multiple nodes, ordinary control methods often cannot distinguish between "the node has received the control command" and "the device has completed the control action," lacking a two-stage closed loop of control confirmation and execution result feedback, which can easily lead to problems such as command loss, unconfirmed execution results, or inconsistent states. Third, when command retransmission, network jitter, or disconnection and reconnection occur on the cloud platform, if the edge side lacks an idempotent deduplication mechanism based on transaction identifiers, the same control command may be executed repeatedly.
[0006] Furthermore, existing smart hotel solutions typically rely on cloud platforms, device shadow attributes, or the most recent device status report to determine whether a device is online. However, in cases of wireless node anomalies, local network congestion, or lost result packets, issues such as devices appearing "falsely online" or having out-of-sync status can easily arise. For security control messages involving room numbers, device identifiers, timestamps, random numbers, and message authentication codes, existing solutions rarely integrate edge-side unified key management, node-side message authentication, replay protection, tamper protection, forgery protection, anomaly logging, and alarm linkage to form a complete closed-loop security control system for guest rooms.
[0007] OpenHarmony, as an open-source operating system for the Internet of Things (IoT) and smart terminals, possesses capabilities such as application development, network communication, relational data management, and key security management, providing a system foundation for building hotel room edge controllers. However, existing hotel room control solutions rarely integrate OpenHarmony edge RCU, multi-wireless node control, reliable and secure communication protocols, local database log tracing, cloud-edge command conversion, scene orchestration, cloud-outage local autonomy, and recovery and retransmission mechanisms. Therefore, it is necessary to propose a reliable and secure communication control method and system for multiple wireless nodes in hotel rooms based on OpenHarmony edge RCU to improve the reliability, security, real-time performance, and traceability of the wireless control process in hotel rooms. Summary of the Invention
[0008] To address the problems of insufficient control link reliability, unverifiable execution results, retransmission of cloud commands leading to repeated execution, inaccurate judgment of wireless node online status, imperfect security authentication mechanism, and untraceable data in the event of cloud outage in existing hotel room control systems, this invention proposes a reliable and secure communication control method and system for multiple wireless nodes in hotel rooms based on OpenHarmony edge RCU.
[0009] This invention deploys an edge RCU running the OpenHarmony operating system in hotel guest rooms, using the edge RCU as a local control center and cloud-edge collaboration gateway. On one hand, the edge RCU receives control requests from guests or administrators through a local user interface; on the other hand, it communicates with the cloud platform, receiving remote control commands and converting them into HRCP control transactions for wireless nodes. The edge RCU communicates with multiple wireless nodes, including temperature and humidity nodes, NFC access control nodes, fan coil unit nodes, touch nodes, motor nodes, relay nodes, infrared nodes, and smoke alarm nodes, using the HRCP reliable and secure communication control protocol. This enables the collection of guest room equipment status, the issuance of control commands, the transmission of execution results, scene linkage, alarm processing, and log tracking.
[0010] The HRCP control protocol in this invention introduces mechanisms such as control transaction identifiers, control confirmation messages, execution result messages, timeout retransmission, transaction deduplication, status reconciliation, timestamps, random numbers, and message authentication codes on the basis of wireless communication. Control confirmation messages confirm that the wireless node has received the control command, and execution result messages confirm that the wireless node has completed the control action. Control transaction identifiers prevent the same control command from being executed repeatedly due to retransmission. AES-128-CTR is used to encrypt the service payload to prevent the control command content from being eavesdropped on. HMAC-SHA256 is used to perform integrity verification and source authentication on the message header, initialization vector, and ciphertext payload to prevent control messages from being forged, tampered with, or replayed. Room identifiers, node identifiers, timestamps, and random numbers prevent cross-room miscontrols and replay of old messages.
[0011] Meanwhile, this invention utilizes the local database capabilities of the OpenHarmony edge RCU to locally store device information, device status, control logs, alarm logs, scene logs, upload queues, and key element information. When the cloud platform is online, the edge RCU uploads status data, control results, alarm information, and scene execution results to the cloud platform; when the cloud platform is offline, the edge RCU still maintains local control functions in the guest room and writes the data to be uploaded into the local upload queue, which is then re-uploaded after the cloud connection is restored. This improves the reliability, security, real-time performance, and traceability of the hotel guest room wireless control system.
[0012] To achieve the above objectives, the technical solution adopted by the present invention is as follows:
[0013] A reliable and secure communication control method for multiple wireless nodes in hotel rooms based on an OpenHarmony edge RCU is disclosed. The method is applied to an edge RCU within a hotel room, wherein the edge RCU runs the OpenHarmony operating system and communicates with multiple wireless nodes and a cloud platform. The method includes the following steps:
[0014] Step S1: Control request reception.
[0015] The edge RCU receives control requests from the local user interface, cloud platform, NFC access control events, touch events, smoke alarm events, or preset scene policies.
[0016] Step S2: Determine the target node and control commands.
[0017] The edge RCU determines the target wireless node, control command, target status, and trigger source based on the control request; wherein, the wireless node includes one or more of the following: temperature and humidity node, NFC access control node, fan coil node, touch node, motor node, relay node, infrared node, and smoke alarm node.
[0018] Step S3: Control transaction and plaintext payload generation.
[0019] The edge RCU generates a control transaction identifier for the control request and generates a plaintext service payload based on the target radio node, control command, target status, and control parameters.
[0020] Step S4: Payload encryption and message authentication code generation.
[0021] The edge RCU encrypts the plaintext service payload (plainPayload) using AES-128-CTR based on the node's encryption key to obtain the ciphertext payload (cipherPayload) and generates an initialization vector (iv). Simultaneously, the edge RCU performs HMAC-SHA256 operations on the room identifier, node identifier, message type, control transaction identifier, timestamp, random number, encryption algorithm identifier, initialization vector, and ciphertext payload based on the node's authentication key to generate a message authentication code.
[0022] Step S5: Control message delivery.
[0023] The edge RCU generates an HRCP control message containing a room identifier, node identifier, message type, control transaction identifier, timestamp, random number, encryption algorithm identifier, initialization vector, ciphertext payload, and message authentication code. The HRCP control message is sent to the corresponding target wireless node via a wireless link, and a control log is written to the local database to record the control transaction identifier, target node, control command, target status, transmission time, and initial status.
[0024] Step S6: Wireless node security verification and decryption.
[0025] After receiving the HRCP control message, the target wireless node first verifies the room identifier, node identifier, timestamp, random number, and message authentication code. If the verification passes, it performs a control transaction deduplication check. If it is not a duplicate transaction, it returns a control confirmation message and decrypts the encrypted payload using AES-128-CTR to obtain the control command. If the verification fails, it refuses to decrypt and execute the control command and generates an authentication failure message.
[0026] Step S7: Control confirmation and execution result feedback.
[0027] After receiving a valid control message, the target wireless node returns a control confirmation message to the edge RCU to indicate that the control command has been received. After completing the control action, the target wireless node returns an execution result message to the edge RCU to indicate the execution status of the control action and the current status of the node.
[0028] Step S8: Timeout retransmission and transaction deduplication.
[0029] If the edge RCU does not receive a control acknowledgment message within a first preset time, it retransmits the HRCP control message. If the edge RCU does not receive an execution result message within a second preset time, it records the execution result timeout and sends a status query request to the target wireless node. The target wireless node performs deduplication processing on duplicate control messages based on the control transaction identifier. When it detects that a control command corresponding to the same control transaction identifier has already been executed, it does not execute the control command again and returns the cached execution result.
[0030] Step S9: Status update and log recording.
[0031] The edge RCU updates the device status, control log, alarm log, and scene log based on the execution result message, and determines whether the control command was executed successfully based on the consistency between the target status and the status reported by the wireless node; when the two are inconsistent, a status inconsistency record is generated.
[0032] Step S10: Scene control processing.
[0033] When the control request is a scene control request, the edge RCU generates multiple control subtasks according to the preset scene configuration and sends HRCP control messages to the corresponding wireless nodes respectively. The scene execution status is determined according to the execution results of each control subtask. The scene execution status includes success, partial failure, and failure.
[0034] Step S11: Cloud-edge collaboration and cloud interruption retransmission.
[0035] When the edge RCU is online on the cloud platform, it uploads device status, control results, alarm information, and scene execution results to the cloud platform. When the cloud platform is offline, the edge RCU maintains local control functions and writes the data to be uploaded into a local upload queue. After the cloud platform restores the connection, it re-uploads the data according to the upload queue. Furthermore, the present invention also provides a system solution.
[0036] A reliable and secure communication control system for multiple wireless nodes in hotel rooms based on OpenHarmony edge RCU includes:
[0037] The edge RCU is used to run the OpenHarmony operating system, receive control requests generated by the local user interface, cloud platform, access control events, touch events or alarm events, and generate HRCP control messages;
[0038] Multiple wireless nodes are used to receive HRCP control messages sent by the edge RCU, execute corresponding control commands, and return control confirmation messages and execution result messages;
[0039] Wireless access equipment is used to provide wireless communication links between the edge RCU and multiple wireless nodes;
[0040] The cloud platform is used to receive device status, control logs, alarm logs and scene logs uploaded by the edge RCU, and to send remote control commands to the edge RCU;
[0041] The edge RCU includes a local user interface module, an HRCP protocol processing module, an encryption authentication module, a scene control module, a local database module, and a cloud communication module.
[0042] The local user interface module displays the status of guest room equipment and receives local control requests; the HRCP protocol processing module generates, encapsulates, parses, and verifies HRCP messages; the encryption and authentication module performs AES-128-CTR payload encryption and decryption, HMAC-SHA256 message authentication code generation and verification, and key management interface calls; the scene control module executes welcome mode, sleep mode, room departure mode, and security mode; the local database module stores equipment status, control logs, alarm logs, scene logs, pending upload queues, and key element information; and the cloud communication module communicates with the cloud platform for status reporting, command reception, and cloud recovery retransmission.
[0043] Compared with the prior art, the advantages of the present invention are as follows:
[0044] 1. This invention uses an edge RCU running the OpenHarmony operating system as the local control center in the guest room, uniformly carrying local user interface, wireless node communication, scene control, encryption authentication, local database, and cloud communication functions. Compared with traditional guest room central control or single cloud control methods, this invention can complete control decisions, status maintenance, and anomaly handling locally in the guest room, reducing dependence on cloud networks.
[0045] 2. This invention employs the HRCP reliable and secure communication control protocol between the edge RCU and multiple wireless nodes. It confirms "the node has received the command" and "the device has completed execution" through control confirmation messages and execution result messages, respectively. This solves the problem in ordinary wireless control where commands are only issued but the execution results cannot be confirmed, thereby improving the control reliability of execution devices such as fan coil nodes, motor nodes, relay nodes, and infrared nodes.
[0046] 3. This invention introduces AES-128-CTR encryption and HMAC-SHA256 message authentication mechanisms into HRCP messages. AES-128-CTR is used to encrypt the service payload to prevent control command content from being eavesdropped on; HMAC-SHA256 is used to perform integrity verification and source authentication on the message header, initialization vector, and ciphertext payload to prevent cross-room miscontrol, illegal forgery, message tampering, and replay attacks; at the same time, by using control transaction identifiers, it avoids repeated execution by the device due to cloud retransmission or wireless retransmission, thereby improving the security and idempotency of guest room wireless control.
[0047] 4. This invention utilizes the local data management capabilities of the edge RCU to record device status, control logs, alarm logs, scene logs, and a queue of data to be uploaded. When the cloud platform is offline, the edge RCU can still complete local control via the HRCP protocol and cache data to be uploaded; after the connection is restored in the cloud, the data is re-uploaded, thus ensuring that the room control process is traceable, anomalies can be located, and data is not easily lost. Attached Figure Description
[0048] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.
[0049] Figure 1 This is a schematic diagram of the overall system structure;
[0050] Figure 2 This is a schematic diagram of the OpenHarmony edge RCU functional module structure;
[0051] Figure 3This is a schematic diagram of the HRCP control message structure;
[0052] Figure 4 This is a schematic diagram of the HRCP two-stage reliable control process;
[0053] Figure 5 This is a schematic diagram of the cloud-edge collaboration and cloud outage recovery process; Detailed Implementation
[0054] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. For details, please refer to... Figures 1 to 5 Obviously, the described embodiments are only a part of the embodiments of this application, and not all of the embodiments. Other embodiments obtained by those skilled in the art based on the embodiments of this application without creative effort are all within the scope of protection of this application.
[0055] In this application, the edge RCU can be implemented using an embedded control device with network communication, database storage, and local application execution capabilities. Preferably, the edge RCU runs the OpenHarmony operating system. The wireless node can be implemented using a microcontroller node with wireless communication capabilities, used to connect to sensing or execution devices in hotel rooms. Specific hardware models, wireless communication methods, database implementation methods, and cloud platform types can be adjusted according to actual engineering needs, and this application does not impose any limitations on these aspects. The embodiments of this application are further described below with reference to the accompanying drawings.
[0056] Example 1: System structure and overall architecture, such as Figure 1 As shown, this embodiment provides a reliable and secure communication control system for multiple wireless nodes in hotel rooms based on OpenHarmony edge RCU, including a cloud platform, OpenHarmony edge RCU, wireless access devices (APs), multiple wireless nodes, and a local database module.
[0057] The OpenHarmony edge RCU is installed in the hotel guest rooms, serving as the local control center and cloud-edge collaborative gateway. The edge RCU communicates with the cloud platform to receive cloud control commands, upload device status, upload control logs, and alarm information. It also communicates with multiple wireless nodes via wireless links to send HRCP control messages, receive control confirmation messages, receive execution result messages, and receive status reports, event reports, and alarm reports.
[0058] The multiple wireless nodes include one or more of the following: temperature and humidity nodes, NFC access control nodes, fan coil unit nodes, touch control nodes, motor nodes, relay nodes, infrared nodes, and smoke alarm nodes. Different wireless nodes, based on their functional types, are used to collect environmental data, identify access control events, execute fan coil unit control, receive touch input, control motor actions, control relay on / off states, send infrared control commands, or report smoke alarm information.
[0059] The cloud platform is used for centralized display and management of the status of hotel room equipment, and for issuing remote control commands or scene control commands to the edge RCU. The cloud platform does not directly control the wireless nodes, but sends control commands to the edge RCU. The edge RCU parses, verifies, converts, and manages the transactions of the cloud commands before generating HRCP control messages for the target wireless nodes.
[0060] The wireless access device (AP) provides a wireless communication environment for the edge RCU and multiple wireless nodes. In one implementation, UDP is used as the transmission method between the edge RCU and the wireless nodes, and the HRCP reliable and secure communication control protocol runs on top of UDP to achieve low-latency control and reliable execution feedback.
[0061] Example 2: OpenHarmony edge RCU functional module, such as Figure 2 As shown, the OpenHarmony edge RCU includes a local UI module, an HRCP protocol processing module, an encryption authentication module, a scene control module, a local database module, a cloud communication module, and a system management module.
[0062] The local UI module is used to display the status of equipment in the guest room, sensor data, alarm information and control results, and to receive equipment control requests or scene control requests issued by guests or managers on the local interface.
[0063] The HRCP protocol processing module is used to generate, encapsulate, parse, and verify HRCP messages. These HRCP messages include control messages, control acknowledgment messages, execution result messages, status reporting messages, event reporting messages, alarm reporting messages, and error messages. The HRCP protocol processing module is also used to maintain control transaction identifiers, retransmission counts, timeout times, and node execution results.
[0064] The encryption and authentication module is used to perform business payload encryption, ciphertext payload decryption, message authentication code generation, and message authentication code verification. In one implementation, the edge RCU performs AES-128-CTR encryption on the plaintext business payload in the HRCP message according to the node encryption key to generate the ciphertext payload; and performs HMAC-SHA256 operation on the room identifier, node identifier, message type, control transaction identifier, timestamp, random number, encryption algorithm identifier, initialization vector, and ciphertext payload according to the node authentication key to generate the message authentication code. Preferably, the edge RCU stores the node encryption key, node authentication key, or key alias through OpenHarmony's HUKS unified keystore or secure storage capabilities, thereby avoiding directly storing the real key in the ordinary business database.
[0065] The scene control module is used to execute scene controls such as welcome mode, sleep mode, away mode, and security mode. Each scene may include multiple control sub-tasks, such as controlling fan coil unit nodes, motor nodes, relay nodes, infrared nodes, etc., to perform corresponding actions. The edge RCU determines the scene execution status based on the execution results of multiple control sub-tasks, and the scene execution status includes success, partial failure, and failure.
[0066] The local database module stores device information, device status, control logs, alarm logs, scene logs, a queue of data to be uploaded, and key information. Specifically, device information records node identifier, room identifier, node type, communication address, and online status; device status records target status and actual reported status; control logs record the sending, confirmation, execution, failure, and retransmission of control transactions; alarm logs record abnormal events such as smoke alarms, unauthorized access control, authentication failures, node offline events, and control timeouts; scene logs record the scene execution process; the queue of data to be uploaded caches data generated during cloud offline periods; and key information records key aliases, key uses, algorithm types, and key versions.
[0067] The cloud communication module is used to communicate with the cloud platform. In one implementation, the cloud communication module uses MQTT or MQTTS to communicate with the cloud platform, and is used to upload status data, control results, alarm information and scene execution results, and to receive device control commands, scene control commands or parameter configuration commands issued by the cloud.
[0068] The system management module is used to manage the network connection, system configuration, log management, time synchronization, and upgrade maintenance of the edge RCU.
[0069] Example 3: HRCP control message structure, such as Figure 3As shown, the HRCP control message includes a protocol version number, room identifier, node identifier, message type, control transaction identifier, timestamp, random number, encryption algorithm identifier, initialization vector, ciphertext payload length, ciphertext payload, and message authentication code.
[0070] Among them, the protocol version number is used to identify the HRCP protocol version; the room identifier is used to identify the current guest room and to prevent accidental control across rooms; the node identifier is used to identify the target wireless node; the message type is used to distinguish control commands, control confirmations, execution results, status reports, event reports, alarm reports, or error messages; the control transaction identifier is used to identify a control transaction and is used for transaction tracking and idempotent deduplication; the timestamp is used to determine whether the message has expired; the random number is used to prevent message replay; the encryption algorithm identifier is used to identify the encryption method used by the service payload; the initialization vector is used as the initial value of the counter in the AES-128-CTR encryption process; the ciphertext payload length is used to identify the data length of the ciphertext payload; the ciphertext payload is used to carry the encrypted control commands, target status, or status data; and the message authentication code is used to verify the integrity and source legitimacy of the message.
[0071] In one implementation, the encrypted payload and message authentication code are generated as follows:
[0072] cipherPayload = AES-128-CTR-Encrypt(Kenc, iv, plainPayload)
[0073] mac = HMAC-SHA256(Kmac, version || roomId || deviceId || msgType ||txId || timestamp || nonce || encAlg || iv || cipherPayload)
[0074] In this context, Kenc is the node encryption key, Kmac is the node authentication key, iv is the initialization vector or counter initial value, plainPayload is the plaintext service payload, and cipherPayload is the ciphertext service payload. After generating the HRCP control message, the edge RCU writes the ciphertext payload and message authentication code into the message. Upon receiving the HRCP control message, the target wireless node first recalculates the message authentication code and compares it. If the verification passes, it then decrypts the ciphertext payload using AES-128-CTR. If the message authentication code verification fails, decryption and execution of control commands are refused, and an authentication failure message is generated.
[0075] In another implementation, the HRCP message can also have a sequence number field, an error code field, or an extended field added according to business needs to support message sorting, anomaly location, or protocol version extension.
[0076] Example 4: HRCP two-stage reliable control method, such as Figure 4 As shown, this embodiment provides a two-stage reliable control process based on HRCP, including the following steps:
[0077] S1: Receive control requests. The edge RCU receives control requests from the local UI, cloud platform, NFC access control node, touch node, smoke alarm node, or preset scene policy.
[0078] S2: Determine the target node and generate a control transaction. The edge RCU determines the target wireless node, control command, target status and trigger source according to the control request, and generates a control transaction identifier txId.
[0079] S3: The edge RCU generates plaintext service payload plainPayload based on the target radio node information and generates initialization vector iv; then, AES-128-CTR is used to encrypt plainPayload to obtain ciphertext payload cipherPayload.
[0080] S4: Generate message authentication code and encapsulate HRCP control message. The edge RCU uses HMAC-SHA256 to calculate roomId, deviceId, msgType, txId, timestamp, nonce, encAlg, iv, and cipherPayload to generate message authentication code mac, and encapsulates HRCP control message containing roomId, deviceId, msgType, txId, timestamp, nonce, encAlg, iv, cipherPayload, and mac.
[0081] S5: Send control message and record initial log. The edge RCU sends the HRCP control message to the target wireless node and writes the control record in the ControlLog of the local database. The initial status is marked as "pending confirmation".
[0082] S6: The target wireless node receives and verifies the message. After receiving the HRCP control message, the target wireless node verifies the validity of roomId, deviceId, timestamp, nonce, and mac.
[0083] S7: Verification result judgment. When the verification fails, the target wireless node refuses to decrypt and execute control commands, and returns an authentication failure message, or the edge RCU records the authentication failure log, and the process ends; when the verification passes, the transaction deduplication judgment process begins.
[0084] S8: Transaction deduplication judgment. When the verification passes, the target wireless node further performs deduplication judgment based on the control transaction identifier txId.
[0085] S9: Repeated transaction processing. If the control command corresponding to the same txId has been executed, the target wireless node will not execute the control command again, but will return the cached CONTROL_RESULT execution result message, and the process will end.
[0086] S10: Return a control confirmation message. When the verification passes and the control transaction is not a duplicate transaction, the target wireless node returns a control confirmation message CONTROL_ACK to the edge RCU to indicate that the control command has been received.
[0087] S11: Decrypt the cipher payload. The target wireless node uses AES-128-CTR to decrypt the cipher payload cipherPayload and obtain the control command.
[0088] S12: Execute control commands. The target wireless node executes corresponding actions based on the decrypted control commands to complete the control actions of the fan coil unit, motor, relay, infrared device and other execution devices.
[0089] S13: Return execution result message. After the target wireless node completes the control action, it generates and returns an execution result message CONTROL_RESULT. The execution result message includes one or more of the following: control transaction identifier txId, execution result, current status, and error code.
[0090] S14: Edge RCU updates the acknowledgment status. After receiving the CONTROL_ACK returned by the target wireless node, the edge RCU updates the acknowledgment time and acknowledgment status in the ControlLog to indicate that the target wireless node has received the control command. This acknowledgment status update process corresponds to the subsequent decryption, execution and return of CONTROL_RESULT by the target wireless node.
[0091] S15: Edge RCU updates device status and control log. After receiving CONTROL_RESULT, the edge RCU updates DeviceState and ControlLog based on the execution result. S16: State consistency judgment. The edge RCU makes a final judgment on the control result based on whether the target state is consistent with the actual reported state of the node. If consistent, the control is marked as successful; if inconsistent, the inconsistent state or control failure information is recorded.
[0092] S17: The process ends. After the edge RCU completes the control transaction status update, the current HRCP control process ends.
[0093] Anomaly Handling A: ACK Timeout Handling. When the edge RCU does not receive CONTROL_ACK within the first preset time, it determines that an ACK timeout has occurred, and resends the HRCP control message, while updating the retransmission count and retransmission status in ControlLog.
[0094] Exception Handling B: RESULT Timeout Handling. When the edge RCU does not receive CONTROL_RESULT within the second preset time, it determines that the execution result has timed out, records the execution result timeout information, and sends a status query request QUERY_STATUS to the target wireless node, or updates the control log based on the query result.
[0095] Through the above main process and exception handling mechanism, this embodiment can distinguish between "whether the control command has reached the node" and "whether the control action has been completed". Combined with AES-128-CTR payload encryption, HMAC-SHA256 message authentication, transaction deduplication, timeout retransmission and state consistency judgment mechanism, it can improve the reliability, security and traceability of the multi-wireless node control process in hotel rooms.
[0096] Example 5: Cloud-edge collaboration and cloud outage recovery process, such as Figure 5 As shown, this embodiment provides a cloud-edge collaboration and cloud interruption retransmission process.
[0097] When the cloud platform is online, it sends single-device control commands or scene control commands to the edge RCU. Upon receiving the command, the edge RCU parses the command source, target room, target node, and control content, and converts the cloud command into an HRCP control message, which is then sent to the corresponding wireless node. After the wireless node completes the execution, the edge RCU receives the execution result message and uploads the execution result, node status, control log, or scene log to the cloud platform.
[0098] When the cloud platform is offline, the edge RCU can continue to perform local control through the local UI, NFC access control events, touch events, or alarm events without relying on the cloud platform. Device status, control results, alarm information, and scene execution results generated during the cloud offline period are written to a local queue to be uploaded.
[0099] Once the cloud platform regains its connection, the edge RCU will re-upload the data to the cloud platform according to the generation time or priority order in the upload queue. After successful re-upload, the edge RCU will update the status of the upload queue or delete the successfully re-uploaded data.
[0100] Through the above methods, this embodiment can maintain the local control function of hotel rooms during cloud offline periods, and maintain the continuity of device status, control results, alarm information and scene execution results after cloud recovery.
[0101] The above description is merely a preferred embodiment of this application, enabling those skilled in the art to understand or implement this application. Various modifications to these embodiments can be made by those skilled in the art without departing from the principles of the invention, and these modifications should also be considered within the scope of protection of this invention. Therefore, this application is not limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features claimed herein.
Claims
1. A reliable and secure communication control method for multiple wireless nodes in hotel rooms based on OpenHarmony edge RCU, characterized in that, An edge RCU, installed in a hotel room, running the OpenHarmony operating system and communicating with multiple wireless nodes and a cloud platform, is described in the method, which includes: Receive control requests from the local user interface, cloud platform, access control events, touch events, or alarm events; The target wireless node, control command, and target status are determined based on the control request. Generate a control transaction identifier corresponding to the control request, and encrypt the service payload to generate an HRCP control message containing a room identifier, node identifier, message type, control transaction identifier, timestamp, random number, encryption algorithm identifier, initialization vector, ciphertext payload and message authentication code; The HRCP control message is sent to the corresponding target wireless node via a wireless link; Receive the control confirmation message returned by the target wireless node to confirm that the target wireless node has received the HRCP control message; Receive the execution result message returned by the target wireless node after executing the control command; Update the device status, control log, alarm log, and scene log according to the execution result message; When the cloud platform is online, the device status, control results, alarm information, and scene execution results are uploaded to the cloud platform; when the cloud platform is offline, the local control of the guest room is maintained, and the data to be uploaded is written to the local upload queue, and the data is re-uploaded after the cloud platform reconnects.
2. The method according to claim 1, characterized in that, The plurality of wireless nodes include one or more of the following: temperature and humidity node, NFC access control node, fan coil unit node, touch node, motor node, relay node, infrared node, and smoke alarm node.
3. The method according to claim 1, characterized in that, The edge RCU uses the node encryption key to encrypt the service payload with AES-128-CTR to obtain the ciphertext payload, and uses the node authentication key to perform HMAC-SHA256 operation on the room identifier, node identifier, message type, control transaction identifier, timestamp, random number, encryption algorithm identifier, initialization vector and ciphertext payload to obtain the message authentication code.
4. The method according to claim 3, characterized in that, After receiving the HRCP control message, the target wireless node first verifies the room identifier, node identifier, timestamp, random number, and message authentication code. When the verification passes, it decrypts the encrypted payload using AES-128-CTR and executes the decrypted control command. When the verification fails, it refuses to decrypt and execute the control command and generates an authentication failure record.
5. The method according to claim 1, characterized in that, The target wireless node performs deduplication processing on the received control commands based on the control transaction identifier; when it detects that the control command corresponding to the same control transaction identifier has been executed, the target wireless node does not execute the control command again and returns the cached execution result.
6. The method according to claim 1, characterized in that, The control confirmation message indicates that the target wireless node has received the HRCP control message, and the execution result message indicates that the target wireless node has completed the execution of the control command. The edge RCU updates the reception confirmation status and execution completion status in the control log according to the control confirmation message and the execution result message, respectively.
7. The method according to claim 6, characterized in that, If the edge RCU does not receive a control confirmation message within a first preset time, it retransmits the HRCP control message; if the edge RCU does not receive an execution result message within a second preset time, it records the execution result timeout and sends a status query request to the target wireless node.
8. The method according to claim 1, characterized in that, When the control request is a scene control request, the edge RCU generates multiple control subtasks according to the preset scene configuration and sends the multiple control subtasks to the corresponding wireless nodes respectively. The scene execution status is determined according to the execution result of each control subtask. The scene execution status includes success, partial failure and failure.
9. The method according to claim 1, characterized in that, The edge RCU stores device information, device status, control logs, alarm logs, scene logs, pending upload queues, and key element information in a local database. The pending upload queue is used to cache status data, control results, alarm information, scene execution results, and authentication failure records generated during cloud platform offline periods. The key element information is used to record key aliases, key objects, key uses, algorithm types, key versions, and activation status.
10. A reliable and secure communication control system for multiple wireless nodes in hotel rooms based on OpenHarmony edge RCU, characterized in that, include: An edge RCU is used to run the OpenHarmony operating system, receive control requests generated by the local user interface, cloud platform, access control events, touch events, or alarm events, and perform the method as described in any one of claims 1 to 9; Multiple wireless nodes are used to receive HRCP control messages sent by the edge RCU, execute corresponding control commands, and return control confirmation messages and execution result messages; A wireless access device for providing wireless communication links between the edge RCU and multiple wireless nodes; The cloud platform is used to receive device status, control logs, alarm logs and scene logs uploaded by the edge RCU, and to send remote control commands to the edge RCU; The edge RCU includes a local user interface module, an HRCP protocol processing module, an encryption authentication module, a scene control module, a local database module, and a cloud communication module.
Citation Information
Patent Citations
Internet of Things smart hotel overall solution system
CN109901410A