A method and system for safe communication of water and electricity prepayment based on MQTT protocol

Abstract

The application discloses a water and electricity prepayment safe communication method and system based on an MQTT protocol, which comprises a cloud management platform, an MQTT server, a local MQTT client, a prepayment data interface and an energy consumption metering control terminal. The cloud management platform is used for generating and issuing a handover frozen identifier. The local MQTT client is used for suspending remote control of original and new accounts, disconnecting an energy consumption path, and forming handover reading and handover evidence according to disconnection feedback and continuous meter reading. The cloud end and the local end jointly generate a new communication code according to the handover evidence, update an MQTT topic, an application layer verification key and a new account metering starting point. The local MQTT client is also used for executing messages matched with the current communication code and isolating other messages. The application limits metering handover and communication permission switching within the same actual energy consumption boundary, avoids messages before handover from acting on the new account, and improves communication safety of account handover.

Description

Technical Field

[0001] This invention relates to the field of prepaid hydropower communication technology, specifically to a secure prepaid hydropower communication method and system based on the MQTT protocol. Background Technology

[0002] Prepaid water and electricity systems typically use the MQTT protocol to enable remote communication between cloud accounts and on-site water and electricity meters. When a shop is leased or the energy user changes, the original water and electricity meters and the local MQTT client generally continue to be used; only the water and electricity meters are re-bound from the original account to the new account.

[0003] After an account is changed, offline, retained, or re-entry messages from the original account may still be sent to the same water and electricity meter. While the device identifier and signature of such messages may be legitimate, they no longer belong to the current energy consumption relationship. Simply relying on identity authentication, timestamps, or duplicate message detection is insufficient to prevent them from affecting the new account. Furthermore, completing the account change in the cloud does not mean that the water valve or power switch on-site has actually been disconnected; even if the actuator reports a disconnection, the water and electricity meter may continue to measure due to residual water flow, contact adhesion, or bypass energy consumption.

[0004] Therefore, existing technologies make it difficult to keep the timing of cloud account switching, actual on-site power consumption termination, and MQTT message permission switching consistent, which can easily lead to cross-account execution of messages from the original account or inaccurate division of usage between accounts. Summary of the Invention

[0005] The purpose of this invention is to provide a secure communication method and system for prepaid water and electricity based on the MQTT protocol, so as to solve the problems mentioned in the background art.

[0006] To address the aforementioned technical problems, this invention provides the following technical solution: a secure communication method and system for prepaid water and electricity based on the MQTT protocol, comprising: S1. The cloud management platform responds to the account handover request of the water and electricity meter by generating a handover freeze flag, and sends it to the local MQTT client via the MQTT server, so that the local MQTT client suspends remote control messages for the original account and the new account. S2. The local MQTT client controls the energy metering control terminal corresponding to the water and electricity meters to disconnect the energy consumption path, obtain the actual feedback status of the energy consumption path and the continuous cumulative meter reading, and determine the handover reading corresponding to the actual energy consumption termination based on the changes in the actual feedback status and the cumulative meter reading. S3. The local MQTT client generates handover evidence containing the water and electricity meter identifier, handover reading, actual status of the energy consumption path, original communication code, and sequence number of the last executed instruction of the original account, and sends the handover evidence to the cloud management platform via the MQTT server. S4, the cloud management platform and the local MQTT client jointly generate a new communication code based on the handover evidence, update the MQTT topic and application layer verification key corresponding to the new account, and use the handover reading as the metering starting point for the new account; S5. The local MQTT client exits the handover lock state, executes the message that matches the new communication code, and transfers the message carrying the original communication code or the message that does not match the current communication code to the non-execution isolation area.

[0007] According to the above technical solution, the energy metering and control terminal includes a water meter, an electrically controlled water valve and a valve position feedback unit, or includes an electricity meter, an on / off relay and a contact feedback unit. In step S1, the handover freeze identifier includes the water and electricity meter identifier, the original communication code, the account binding change sequence number, and the sequence number of the last executed instruction of the original account; Upon receiving the handover freeze flag, the local MQTT client enters the handover lock state. In the handover lock state, only the following operations are allowed: disconnecting the power supply path, collecting meter readings, collecting terminal status data, and uploading handover evidence.

[0008] According to the above technical solution, in step S2, after the energy consumption metering control terminal reports that the energy consumption path has been disconnected, the local MQTT client acquires the cumulative meter reading according to a preset acquisition cycle. And calculate the usage increment between adjacent cumulative meter readings: When the actual feedback state of the energy-consuming path is disconnected, and continuous The usage increment for each collection cycle satisfies: At that time, The handover reading was determined to be the aforementioned value. in, It is a positive integer not less than 2. The stable threshold is determined based on the resolution of the water and electricity meters and the allowable residual consumption after the energy supply path is disconnected.

[0009] According to the above technical solution, when the local MQTT client does not receive feedback on the disconnection of the power supply path within the preset action time limit, it maintains the handover lock state and generates actuator action abnormal information. When disconnection feedback has been obtained, but the usage increment does not meet the stability condition within the preset stable time limit, the meter reading acquisition process is extended, and the water valve is not completely closed, bypass water flow or meter abnormality information is output according to the continuous metering result of the water meter after the water valve is closed, or the relay contact sticking, bypass power use or meter abnormality information is output according to the continuous metering result of the electricity meter after the on / off relay is disconnected. Step S4 is prohibited from being executed before the abnormality is resolved.

[0010] According to the above technical solution, in step S4, the cloud management platform and the local MQTT client respectively generate cloud-based random numbers. and local random numbers The new communication codes are calculated according to the following formulas: in, This is a pre-configured system-level authentication key for the cloud management platform and the local MQTT client. This was the original communication code. For water and electricity meter markings, For the handover of readings, This represents the actual disconnected state of the energy supply path. This is the sequence number of the last executed instruction in the original account. Indicates data concatenation; The cloud management platform and the local MQTT client confirm the validity of the handover evidence when their respective calculated new communication codes match.

[0011] According to the above technical solution, step S4 further includes: The cloud management platform generates a request topic and a response topic for a new account based on the new communication code. The request topic includes, in sequence, a topic prefix, a water / electricity meter identifier, the new communication code, and a request identifier. The response topic includes, in sequence, a topic prefix, a water / electricity meter identifier, the new communication code, and a response identifier. The cloud management platform and the local MQTT client generate a new application-layer authentication key according to the following formula: in, Represents the key derivation function; After the local MQTT client returns confirmation information for the new communication code, the cloud management platform controls the MQTT server to update the topic access control relationship according to the new communication code, so that the new account only has the publish or subscribe permissions for the topic corresponding to the new communication code, and sends an activation response to the local MQTT client. The local MQTT client only enables the new communication codename after receiving an activation response, and maintains a handover lock state until either confirmation process is completed.

[0012] According to the above technical solution, in the handover lock state, the message carrying the original communication code is stored in the historical audit queue, and the message submitted by the new account during the handover period is stored in the activation queue. After the new communication code is activated, the cloud management platform uses the new communication code and the new application layer verification key to repackage the messages in the queue to be activated, without directly releasing the original messages; The local MQTT client executes the corresponding message only if the communication code in the MQTT topic, the communication code in the message payload, and the message verification code generated based on the new application layer verification key all match. The first message to restore water or electricity supply after the new communication code is activated adopts a control method that sets a target state, and returns the execution result after the energy metering control terminal reports that the target state has been reached.

[0013] A prepaid secure communication system for hydropower based on the MQTT protocol includes a cloud management platform, an MQTT server, a local MQTT client, a prepaid data interface, and an energy metering and control terminal. The cloud management platform is used to initiate account handover, verify handover evidence, coordinate with the local MQTT client to generate new communication codes, and control the activation of communication permissions for new accounts. The MQTT server is used to transmit account handover data and prepaid water and electricity service messages between the cloud management platform and the local MQTT client, and manages access permissions for corresponding MQTT topics according to the new communication code. The local MQTT client is used to respond to account handover and enter the handover lock state, control the energy metering control terminal to form on-site handover readings, generate handover evidence, confirm the new communication code, and execute or isolate the control message according to the communication generation to which the message belongs; The prepaid data interface is used to store the account binding relationship of water and electricity meters, cumulative meter readings, communication codes, and executed instruction records; The energy consumption metering and control terminal is used to measure actual consumption, control the on / off state of energy consumption channels, and provide feedback on the actual status of energy consumption channels.

[0014] According to the above technical solution, the energy metering and control terminal includes a water meter, an electrically controlled water valve and a valve position feedback unit, or includes an electricity meter, an on / off relay and a contact feedback unit. The metering data output terminal of the water meter or electricity meter and the status output terminal of the valve position feedback unit or contact feedback unit are respectively connected to the data input terminal of the local MQTT client, and the control output terminal of the local MQTT client is connected to the electric water valve or on / off relay. The prepaid data interface stores the account binding change sequence number, the current communication code, the handover reading, and the sequence number of the last executed instruction of the original account, and provides account handover data to the cloud management platform and the local MQTT client. The local MQTT client, in the handover locked state, only enables the functions of disconnecting the power supply path, collecting meter readings, collecting terminal status, and uploading handover evidence.

[0015] According to the above technical solution, the cloud management platform includes a handover management module and a topic permission management module, and the local MQTT client includes a physical handover determination module, a communication code confirmation module, and a message execution isolation module; The handover management module is used to generate a handover freeze flag, verify the handover evidence sent by the local MQTT client, and use the handover reading as the starting point for the new account's metering. The physical handover determination module is used to receive the actual feedback status of the energy consumption path and the continuous cumulative meter reading, and output the handover reading or the abnormal lock result. The communication code confirmation module is used to take handover evidence, cloud random number and local random number as input, generate a new communication code and a new application layer verification key with the cloud management platform respectively, and output confirmation information when the calculation results are consistent. The topic permission management module is used to generate request topics and response topics according to the new communication code, update the topic access control relationship of the MQTT server, and send an activation response after the update is completed; The message execution isolation module is used to determine the execution qualification of a message based on the communication code in the MQTT topic, the communication code in the message payload, and the message verification code. It transfers the message corresponding to the original communication code to the historical audit queue and converts the first message to restore water or electricity after the new communication code is enabled into a control command for the set target state.

[0016] Compared with the prior art, the beneficial effects achieved by the present invention are as follows: The present invention suspends the remote control of the original account and the new account by using the handover freeze flag, and determines the handover reading corresponding to the termination of actual energy consumption by combining the actuator disconnection feedback and continuous meter reading, and makes the handover reading participate in the generation of the new communication code, MQTT topic and application layer verification key, so that the metering boundary corresponds to the communication permission switching boundary; even if the original account message is legitimate and is re-delivered, it will be isolated due to the communication code mismatch. At the same time, it can detect abnormalities such as incomplete water valve closure, relay contact sticking or bypass energy consumption, and avoid the original account message acting on the new account and the confusion of the consumption of the previous and previous accounts. Attached Figure Description

[0017] The accompanying drawings are provided to further illustrate the invention and form part of the specification. They are used in conjunction with embodiments of the invention to explain the invention and do not constitute a limitation thereof. In the drawings: Figure 1 This is a flowchart illustrating the prepaid secure communication method for water and electricity based on the MQTT protocol of the present invention. Figure 2 This is a schematic diagram of the prepaid secure communication system for water and electricity based on the MQTT protocol of the present invention. Detailed Implementation

[0018] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0019] Example 1 Please see Figure 1 This embodiment provides a secure communication method for prepaid water and electricity based on the MQTT protocol. It is applicable to commercial complexes, industrial parks or centralized property management areas, where the original water meters, electricity meters and local MQTT clients are reused, while the prepaid water and electricity accounts are replaced due to shop lease changes, property transfers or changes in the energy user.

[0020] In this embodiment of the invention, the cloud management platform communicates with a local MQTT client located on the on-site intranet via an MQTT server. The local MQTT client is connected to both the prepaid data interface and the energy metering control terminal. The prepaid data interface stores the binding relationship between water and electricity meters and accounts, cumulative meter readings, balance data, current communication codes, and executed command records. The energy metering control terminal is either a water energy terminal or an electricity energy terminal; the water energy terminal includes a water meter, an electrically controlled water valve, and a valve position feedback unit, while the electricity energy terminal includes an electricity meter, an on / off relay, and a contact feedback unit.

[0021] For ease of understanding, the account handover in this embodiment is not simply a matter of transferring the water and electricity meters from the original account to the new account in the cloud. Instead, it involves three interconnected processes: First, the remote execution privileges of both the original and new accounts are suspended; second, the water valve or power switch is disconnected, and the actual energy consumption is confirmed to have stabilized and ceased through actuator feedback and accumulated meter readings; finally, a new communication code is generated using the resulting handover readings and the on-site status, ensuring that messages before and after the handover belong to different communication generations. In other words, this embodiment first freezes message execution, then determines the on-site handover point, and finally enables the communication permissions of the new account.

[0022] The secure communication method includes the following steps.

[0023] Step S1: In response to the account handover request from the water and electricity meter, the cloud management platform generates a handover freeze flag and sends it to the local MQTT client via the MQTT server, causing the local MQTT client to suspend remote control messages for both the original and new accounts.

[0024] Specifically, the account handover request is generated by the property management or prepaid service provider and corresponds to the identifier of the water and electricity meter to be handed over, the original account identifier, the new account identifier, and the account binding change sequence number. The account binding change sequence number increases with the number of account handovers for the same water and electricity meter, and is used to distinguish different handover processes initiated successively for the same water and electricity meter.

[0025] After receiving an account handover request, the cloud management platform does not immediately grant remote control permissions to the new account. Instead, it reads the original communication code and the sequence number of the last executed instruction of the original account stored in the prepaid data interface to generate a handover freeze identifier. In this embodiment of the invention, the handover freeze identifier includes the water / electricity meter identifier, the original communication code, the account binding change sequence number, and the sequence number of the last executed instruction of the original account. The sequence number of the last executed instruction is taken from the non-volatile execution record written by the local MQTT client after completing the on-site control action, rather than simply using the message sequence number already delivered by the MQTT server.

[0026] Upon receiving the handover freeze flag, the local MQTT client matches the meter identifier, original communication code, and account binding change sequence number with the locally stored data. If the match is successful, the local MQTT client enters a handover lock state. In this state, only operations such as disconnecting the energy consumption path, collecting meter readings, collecting terminal status data, and uploading handover evidence are permitted. Remote messages from either the original or new account are not allowed to modify prepaid balances, activate energy consumption paths, or change terminal status during the handover process.

[0027] The aforementioned handover lockout does not merely disable the original account; rather, it simultaneously suspends remote control of both the original and new accounts while the on-site handover readings are still pending. If only the original account is disabled and the new account is immediately opened, the new account's prepaid funds might continue to be consumed before the original power consumption path is truly disconnected. Conversely, if the original account is disabled only after the on-site handover is complete, the executable time for messages on the original account will be extended. Therefore, under the handover lockout state, neither account can remotely open the power consumption path, but the local MQTT client can still perform disconnection, sampling, and evidence upload. This prevents the original account from continuing to control the site and also prevents the new account from prematurely consuming the power consumption that the original account has not yet finished consuming.

[0028] For example, the local MQTT client stores unexecuted messages carrying the original communication code into the historical audit queue, and stores messages submitted by the new account during the handover period into the pending activation queue. Messages in the historical audit queue retain the message source, reception time, original communication code, and message digest, but do not enter the execution queue; messages in the pending activation queue are only saved as pending requests for the new account, and the original messages cannot be released directly later, but should be re-encapsulated after the new communication code is enabled.

[0029] If the local MQTT client is offline when the account handover request is initiated, the MQTT server saves a handover freeze flag. After the local MQTT client reconnects, it processes the handover freeze flag in system management messages first, and then processes ordinary control messages. If the locally saved account binding change sequence number is higher than the received account binding change sequence number, the handover freeze flag is treated as an expired handover message and transferred to the non-execution isolation zone to prevent earlier handover processes from overwriting the current handover state.

[0030] Step S2: The local MQTT client controls the energy metering control terminal corresponding to the water and electricity meters to disconnect the energy consumption path, obtain the actual feedback status of the energy consumption path and the continuous cumulative meter reading, and determine the handover reading corresponding to the termination of actual energy consumption based on the changes in the actual feedback status and the cumulative meter reading.

[0031] Specifically, for water-powered terminals, the local MQTT client sends a control command to the electrically controlled water valve to set it to the closed state, and obtains the actual position of the valve through the valve position feedback unit; for electrical-powered terminals, the local MQTT client sends a control command to the on / off relay to set it to the open state, and obtains the actual contact state of the relay through the contact feedback unit. The control command is a command to set the target state, rather than a toggle command that changes the state every time it is executed, thus avoiding the re-sending of MQTT messages or control retries that would reopen a disconnected power supply path.

[0032] It should be noted that this embodiment employs a two-layer confirmation process for the termination of actual energy consumption. The first layer of confirmation comes from the valve position feedback unit or contact feedback unit, used to determine whether the electrically controlled water valve or on / off relay has performed a disconnection action; the second layer of confirmation comes from the continuous cumulative meter reading of the water meter or electricity meter, used to determine whether actual energy consumption still exists after the disconnection action. The former reflects whether the control component has operated, while the latter reflects whether the water flow or load power consumption has truly stopped; the two cannot be substituted for each other.

[0033] After receiving a disconnection notification, the local MQTT client continuously acquires cumulative table readings according to a preset collection period. And calculate the usage increment between adjacent cumulative meter readings: in, For the first The cumulative water or electricity volume obtained at each collection point. This refers to the cumulative water or electricity volume obtained at the previous data collection time. This indicates the actual usage still occurring within the corresponding data collection period. The cumulative meter reading is taken directly from the metering data of the water or electricity meter, and is not replaced by changes in account balance or MQTT message responses.

[0034] When the actual feedback state of the energy-consuming path is disconnected, and continuous The usage increment for each collection cycle satisfies: At that time, the current cumulative meter reading will be displayed. Determined as handover reading .

[0035] in, It is a positive integer not less than 2, used to avoid misjudging a single unchanged meter reading as the actual energy consumption having stopped; This is a stable threshold determined based on the resolution of the water and electricity meters and the allowable residual consumption after the energy supply path is disconnected. For example, It can be 3 or 5, but the specific value should be determined based on the meter's data collection cycle, communication delay, and on-site energy consumption inertia, and is not limited to a fixed value.

[0036] As can be seen from the above judgment relationship, a single unchanged meter reading is insufficient to prove that actual energy consumption has stopped. Only when the consumption increments for multiple consecutive sampling cycles are all within a stable threshold can a handover reading be generated. If the consumption increment in any sampling cycle exceeds the stable threshold, the counting of consecutive stable cycles restarts to avoid misjudging intermittent water or electricity use, or missed sampling, as the termination of actual energy consumption.

[0037] For water-using terminals, even after the water valve is closed, the residual water in the downstream pipeline may continue to drive the water meter. Therefore, the stability threshold can be determined based on the minimum metering resolution of the water meter and the allowable residual flow in the pipeline. For electrical-using terminals, although the relay has been disconnected, if there is contact sticking or bypass load, the meter will still generate a continuous increase. Therefore, the stability threshold can be determined based on the meter resolution, measurement noise, and allowable standby power consumption of the terminal.

[0038] Therefore, the actuator disconnect feedback is used to confirm that "the water valve or power switch has been activated," and the stable reading of the continuous meter further confirms that "the water flow or current has actually stopped." This embodiment combines the two results to determine the handover reading, which can avoid mistakenly using the moment when the user change is initiated in the cloud, the moment the control command is issued, or the moment when the actuator just returns a disconnect response as the boundary between the actual usage of the previous and next accounts.

[0039] Furthermore, if the local MQTT client does not receive feedback on the disconnection of the power supply path within the preset action time limit, it maintains the handover lock state and generates actuator action exception information, but does not generate handover readings. If disconnection feedback has been received, but the usage increment does not meet the stability condition within the preset stability time limit, the local MQTT client extends the meter reading acquisition process.

[0040] For water-using terminals, if the valve position feedback is closed but the water meter continues to measure, output information indicating incomplete valve closure, bypass water flow, or meter malfunction. For electricity-using terminals, if the contact feedback is open but the electricity meter continues to measure, output information indicating relay contact sticking, bypass power use, or meter malfunction. The new communication code generation process is prohibited until the anomaly is resolved and the stability conditions are met again.

[0041] If a network interruption occurs again during the handover process, the local MQTT client will remain in the handover locked state and write the disconnection feedback, cumulative table readings, and continuous stable period count to its local non-volatile storage. After the network is restored, the reading stability assessment will continue, and the client must not automatically exit the handover locked state due to reconnecting to the MQTT server.

[0042] Step S3: The local MQTT client generates handover evidence containing the water and electricity meter identifier, handover reading, actual status of the energy consumption path, original communication code, and the last executed instruction of the original account, and sends the handover evidence to the cloud management platform via the MQTT server.

[0043] In this embodiment of the invention, the evidence of handover includes at least water and electricity meter identification. , handover reading Actual state of energy consumption pathways Original communication code The sequence number of the last executed instruction in the original account. And the account binding change serial number.

[0044] in, Equipment files retrieved from energy consumption metering and control terminals; The cumulative table reading determined in step S2; It is taken from the valve position feedback unit or the contact feedback unit and encoded as the actual disconnection state of the energy consumption path; The original communication code currently used by the local MQTT client; Retrieved from local non-volatile execution records, used to limit the position already executed in the original communication generation.

[0045] The local MQTT client encapsulates the handover evidence according to a preset field order and uploads it to the cloud management platform through the system management topics allowed during the handover period. After receiving the handover evidence, the cloud management platform verifies the water and electricity meter identifier, original communication code, account binding change sequence number, and the sequence number of the last executed instruction against the corresponding records in the prepaid data interface.

[0046] If the original communication code in the handover evidence is not equal to the current communication code stored in the cloud, or if the account binding change sequence number does not correspond to the current pending account handover request, the cloud management platform will not enter the new communication code generation process, but will maintain the handover frozen state and request the local MQTT client to resynchronize the handover record.

[0047] As can be seen from the above process, the handover evidence is not an account version number automatically generated by the cloud, but rather constitutes a combination of the actual handover readings on-site, the disconnection status of the energy consumption path, and the last execution position of the original account. The cloud only allows the transition to the next communication generation after confirming which water and electricity meter, at what cumulative reading, and under what on-site condition the original energy consumption relationship ended. This avoids the situation where the cloud has completed the account change, but the local water valves, power switches, or cumulative metering status remain at the original account stage.

[0048] Step S4: The cloud management platform and the local MQTT client jointly generate a new communication code based on the handover evidence, update the MQTT topic and application layer verification key corresponding to the new account, and use the handover reading as the metering starting point for the new account.

[0049] Specifically, the cloud management platform generates cloud-based random numbers. The local MQTT client generates a local random number. Cloud-based random numbers and local random numbers are exchanged through a handover management communication process. The cloud management platform and the local MQTT client independently calculate the new communication code based on the same handover evidence. in, A pre-configured system-level authentication key for the cloud management platform and the local MQTT client; This was the original communication code; For water and electricity meter markings; For handing over readings; This represents the actual disconnected state of the energy consumption path; This is the sequence number of the last executed instruction in the original account; and These are cloud-based random numbers and local random numbers, respectively. This indicates that data is concatenated according to a preset field order.

[0050] When concatenating data, each field uses a fixed-length encoding method or an encoding method with a length identifier to avoid different combinations of fields producing the same concatenation result.

[0051] As can be seen from the above formula, the new communication code is not a simple random number unrelated to the on-site conditions. Original communication code Used to connect two generations of communication; water and electricity meter markings Used to specify a particular device; for handing over readings and actual disconnection status Used to define the physical boundary of the site; the sequence number of the last executed instruction. Used to limit the position already reached in the original communication generation; cloud random number. and local random numbers This ensures that the new communication code must be generated jointly by the cloud and the local end.

[0052] Therefore, as long as the water and electricity meters, handover readings, on-site conditions, last execution location, or any random number are different, the calculated new communication code will be different. From a technical perspective, this is equivalent to allowing the actual energy handover point formed on-site to participate in the generation of the next communication generation. The communication identity of the new account no longer comes solely from the cloud account rebinding result, but from the joint confirmation of cloud records and on-site physical conditions.

[0053] After completing the calculation, the local MQTT client returns a new communication code confirmation message to the cloud management platform. This confirmation message can be a verification digest of the new communication code or a message verification code generated using a system-level verification key to verify the new communication code and the account binding change sequence number. The cloud management platform compares the local calculation result with its own calculation result, and only confirms the validity of the handover evidence if the two match.

[0054] The cloud management platform generates request and response topics for new accounts based on the new communication code. For example, the request topic includes, in sequence, a topic prefix, a water / electricity meter identifier, the new communication code, and a request identifier; the response topic includes, in sequence, a topic prefix, a water / electricity meter identifier, the new communication code, and a response identifier. The topic prefix distinguishes the service type, the water / electricity meter identifier locates the energy metering control terminal, the new communication code defines the communication generation to which the message belongs, and the request and response identifiers distinguish the message direction.

[0055] The cloud management platform and the local MQTT client also generate a new application-layer authentication key according to the following formula: in, This represents the key derivation function. This is the application layer verification key for the communication generation corresponding to the new account, used to generate and verify message verification codes.

[0056] After receiving confirmation of the new communication code from the local client, the cloud management platform controls the MQTT server to update the topic access control relationships based on the new communication code. This ensures that the new account only has publish or subscribe permissions for the topic corresponding to the new communication code, while the original account no longer has access to the new topic. After completing the topic access control relationship update, the MQTT server returns the update result, and the cloud management platform then sends an activation response to the local MQTT client.

[0057] The local MQTT client will only send the activation response after receiving it. and Set the current communication code and the current application layer verification key, and exit the handover lock state. If the new communication code confirmation information is lost on the local end, the calculation results on the cloud and the local end are inconsistent, the MQTT server has not completed the access control update, or the local MQTT client has not received an activation response, then the handover lock state will remain.

[0058] The activation sequence described above is as follows: the local end first verifies that the on-site handover has been completed; then the cloud and local ends calculate the new communication codename respectively; the MQTT server then grants access permissions to the topic corresponding to the new communication codename; finally, the local MQTT client activates the new communication codename. If any step is not completed, the new account cannot directly control the on-site equipment.

[0059] For example, if the MQTT server has updated the topic access control relationship, but the local MQTT client has not yet received the activation response, the new account's message cannot enter the execution process even if it has arrived at the local end. Conversely, if the local end has calculated the new communication code, but the MQTT server has not yet opened the new topic, the local end also maintains the handover lock, thereby avoiding communication permissions being effective only on the cloud or only on the local end.

[0060] Meanwhile, the cloud management platform uses data transfer... As the starting point for metering the new account, the handover readings and the new communication code are written together into the prepaid data interface. The metering endpoint of the original account and the metering starting point of the new account are formed by the same physical reading, so that the communication permission switching boundary corresponds to the actual energy consumption termination boundary on site.

[0061] Step S5: The local MQTT client exits the handover lock state, executes the message that matches the new communication code, and transfers the message carrying the original communication code or the message that does not match the current communication code to the non-execution isolation area.

[0062] Specifically, after the new communication code is activated, the cloud management platform will utilize the new communication code. and new application layer verification key The system repackages messages submitted by new accounts in the activation queue during the handover period. During repackaging, a new MQTT topic, message payload, and message verification code are generated; the original messages saved during the handover period are not directly released.

[0063] After receiving a message, the local MQTT client sequentially verifies the communication identifier in the MQTT topic, the communication identifier in the message payload, and the message verification code generated based on the new application layer verification key. Only when all three match the current communication identifier and the current application layer verification key will the corresponding message be sent to the prepaid service processing or energy control flow.

[0064] For example, the original account A corresponds to the original communication code. New account B corresponds to a new communication code. If a valve shut-off, power outage, or balance processing message generated before the original account A's lease termination is redelivered by the MQTT server after the account is transferred, even if the sender's identity, device number, timestamp, and original message signature are all verified correctly, the message will still be considered invalid because its MQTT subject and message payload still carry the same information. With the local MQTT client currently enabled Because of the inconsistency, this message can only enter the historical audit queue or the non-execution isolation zone. It cannot modify the balance of the new account B, nor can it control the water valve or power switch corresponding to the new account B.

[0065] If the communication code in the MQTT topic matches the current communication code, but the communication code or message verification code in the message payload does not match, it will be judged as an incomplete encapsulation or verification error message, outputting a security communication error message and prohibiting the corresponding message from entering the execution process.

[0066] For requests to restore water or electricity submitted by new account B during the handover lockout period, the system does not directly release the original messages saved before the handover, but instead utilizes... and The MQTT topic, message payload, and message verification code are regenerated. This is because when the original message was created, the on-site handover readings and new communication codes were not yet determined; only after re-encapsulation can the message clearly belong to the new communication generation after the handover is completed.

[0067] Furthermore, the first message to restore water or power supply after the new communication code is activated adopts a control method that sets a target state. For example, the control content of the message to restore water supply is to set the electrically controlled water valve to the open state, and the control content of the message to restore power supply is to set the on / off relay to the closed state, rather than using a control method that switches the current state.

[0068] After the local MQTT client issues the target status command, it reads the valve position feedback or contact feedback. Only when the energy metering control terminal reports that the target status has been reached will a successful execution result be returned to the cloud management platform. If the target status is not reached within the preset action time limit, the current safe state of the energy consumption path is maintained, actuator action exception information is output, and marking the control task as complete solely based on the delivery of the MQTT message is prohibited.

[0069] Through the above process, even if offline messages, retained messages, cloud retry messages, or local cached messages of the original account are delivered again after the account handover, they cannot pass the matching verification of the current communication generation, and therefore cannot cross the energy consumption boundary formed by the physical handover readings to act on the new account.

[0070] Example 2 Please see Figure 2 This embodiment provides a prepaid secure communication system for water and electricity based on the MQTT protocol, including a cloud management platform, an MQTT server, a local MQTT client, a prepaid data interface, and an energy metering and control terminal.

[0071] The prepaid data interface is used to store the account binding relationship of water and electricity meters, cumulative meter readings, prepaid balance, current communication code and executed instruction records, and to provide account handover data to the cloud management platform and on-site account status and communication code verification data to the local MQTT client.

[0072] The cloud management platform communicates with the MQTT server. In response to an account handover request, the cloud management platform generates a handover freeze flag, which is then sent to the local MQTT client via the MQTT server. Upon receiving the handover evidence, the cloud management platform and the local MQTT client generate a new communication code based on the evidence, update the metering starting point for the new account, and control the MQTT server to update the topic access control relationship.

[0073] The MQTT server is located on the cloud network side and is used to transmit handover freeze indicators, handover evidence, new communication code confirmation information, activation responses, and prepaid water and electricity service messages between the cloud management platform and the local MQTT client. Whether the MQTT server has completed message delivery is not the sole basis for determining whether the account handover is complete. Account handover completion also depends on the actual local disconnection feedback, the stability of the cumulative meter readings, and the two-way confirmation results of the new communication code.

[0074] The local MQTT client is located on the on-site intranet and communicates with the prepaid data interface and the energy metering control terminal. The local MQTT client enters a handover lock state based on the handover freeze flag, controls the energy metering control terminal to disconnect the energy consumption path, determines the handover reading corresponding to the actual energy consumption termination based on the disconnection feedback and continuous cumulative meter readings, generates handover evidence, and calculates a new communication code with the cloud management platform. After the new communication code is activated, the local MQTT client only executes messages with the current communication code and transfers messages with other communication codes to the non-execution isolation area.

[0075] The energy metering control terminal includes a water meter, an electrically controlled water valve, and a valve position feedback unit, or an electricity meter, an on / off relay, and a contact feedback unit. The water meter or electricity meter outputs the cumulative meter reading to the local MQTT client, the valve position feedback unit or contact feedback unit outputs the actual status of the energy consumption path, and the local MQTT client outputs the target status control command to the electrically controlled water valve or on / off relay.

[0076] In this embodiment of the invention, after the power consumption path feedback is disconnected, the local MQTT client calculates the power consumption increment between adjacent cumulative meter readings according to a preset collection period, and continuously... When the usage increment in each collection cycle does not exceed the stable threshold, the current cumulative meter reading is determined as the handover reading. When no disconnection feedback is obtained or the usage increment does not meet the stability condition within the preset stable time limit, the local MQTT client maintains the handover lock state, outputs actuator action abnormality, bypass power consumption abnormality, or meter abnormality information, and prohibits the generation of new communication codes.

[0077] The cloud management platform and the local MQTT client generate a new communication code based on the original communication code, water and electricity meter identifiers, handover readings, actual status of the energy consumption path, the sequence number of the last executed instruction of the original account, cloud-based random numbers, and local random numbers. They also generate a new application-layer verification key based on the system-level verification key, the new communication code, cloud-based random numbers, and local random numbers. The cloud management platform then generates request and response topics for the new account based on the new communication code and controls the MQTT server to update topic access control relationships.

[0078] After the new communication code is enabled, the local MQTT client will store the message carrying the original communication code in the historical audit queue, and will only execute the corresponding message if the communication code in the MQTT topic, the communication code in the message payload, and the message verification code generated based on the new application layer verification key all match.

[0079] Therefore, the cloud management platform is responsible for initiating account handover and switching communication permissions, the local MQTT client is responsible for controlling the on-site energy consumption path and determining whether actual energy consumption has stopped, the MQTT server is responsible for message transmission and topic access control, the prepaid data interface is responsible for saving account binding relationships, handover readings and communication codes, and the energy metering control terminal is responsible for providing cumulative meter readings and actual disconnection feedback.

[0080] This system does not use any single factor—such as a changed cloud account, delivered MQTT message, or returned disconnection feedback—as the sole basis for account switching completion. Instead, it first uses disconnection feedback and continuous meter readings to generate on-site handover readings, and then generates a new communication code based on these readings. The same handover reading serves as both the metering endpoint for the original account and the metering starting point for the new account, and also participates in determining the eligibility for execution of MQTT messages before and after the change, ensuring that metering handover and communication handover correspond to the same actual energy consumption boundary.

[0081] It should be noted that this invention can be applied separately to water prepaid systems or electricity prepaid systems, or to water and electricity prepaid systems that manage both water meters and electricity meters simultaneously on the same property management platform. When the same account is associated with both water meters and electricity meters, corresponding handover readings and handover evidence can be generated for the water energy consumption path and the electricity energy consumption path respectively; when the physical stability judgment of either energy consumption path has not been completed, the handover lock state of the corresponding terminal is maintained to avoid replacing the incomplete on-site handover process with the handover already completed by another terminal.

[0082] The MQTT transmission quality level, specific meter model, actuator type, acquisition cycle, and stability threshold not specifically limited in the above embodiments can be set according to the on-site network conditions, meter resolution, and characteristics of energy-consuming equipment. However, the technical relationship of determining the handover reading based on the actual energy consumption termination boundary and switching the communication generation based on the handover evidence must not be changed.

Claims

1. A secure communication method for prepaid water and electricity based on the MQTT protocol, characterized in that, include: S1. The cloud management platform responds to the account handover request of the water and electricity meter by generating a handover freeze flag, and sends it to the local MQTT client via the MQTT server, so that the local MQTT client suspends remote control messages for the original account and the new account. S2. The local MQTT client controls the energy metering control terminal corresponding to the water and electricity meters to disconnect the energy consumption path, obtain the actual feedback status of the energy consumption path and the continuous cumulative meter reading, and determine the handover reading corresponding to the actual energy consumption termination based on the changes in the actual feedback status and the cumulative meter reading. S3. The local MQTT client generates handover evidence containing the water and electricity meter identifier, handover reading, actual status of the energy consumption path, original communication code, and sequence number of the last executed instruction of the original account, and sends the handover evidence to the cloud management platform via the MQTT server. S4, the cloud management platform and the local MQTT client jointly generate a new communication code based on the handover evidence, update the MQTT topic and application layer verification key corresponding to the new account, and use the handover reading as the metering starting point for the new account; S5. The local MQTT client exits the handover lock state, executes the message that matches the new communication code, and transfers the message carrying the original communication code or inconsistent with the current communication code to the non-execution isolation area.

2. The prepaid secure communication method for water and electricity according to claim 1, characterized in that, The energy metering and control terminal includes a water meter, an electrically controlled water valve and a valve position feedback unit, or includes an electricity meter, an on / off relay and a contact feedback unit. In step S1, the handover freeze identifier includes the water and electricity meter identifier, the original communication code, the account binding change sequence number, and the sequence number of the last executed instruction of the original account; Upon receiving the handover freeze flag, the local MQTT client enters the handover lock state. In the handover lock state, only the following operations are allowed: disconnecting the power supply path, collecting meter readings, collecting terminal status data, and uploading handover evidence.

3. The prepaid secure communication method for water and electricity according to claim 2, characterized in that, In step S2, after the energy consumption metering control terminal reports that the energy consumption path has been disconnected, the local MQTT client acquires the cumulative meter reading according to the preset acquisition cycle. And calculate the usage increment between adjacent cumulative meter readings: When the actual feedback state of the energy-consuming path is disconnected, and continuous The usage increment for each collection cycle satisfies: At that time, The handover reading was determined to be the aforementioned value. in, It is a positive integer not less than 2. The stable threshold is determined based on the resolution of the water and electricity meters and the allowable residual consumption after the energy supply path is disconnected.

4. The prepaid secure communication method for water and electricity according to claim 3, characterized in that, When the local MQTT client does not receive feedback on the disconnection of the power supply path within the preset action time limit, it maintains the handover lock state and generates actuator action exception information; When disconnection feedback has been obtained, but the usage increment does not meet the stability condition within the preset stable time limit, the meter reading acquisition process is extended, and the water valve is not completely closed, bypass water flow or meter abnormality information is output according to the continuous metering result of the water meter after the water valve is closed, or the relay contact sticking, bypass power use or meter abnormality information is output according to the continuous metering result of the electricity meter after the on / off relay is disconnected. Step S4 is prohibited from being executed before the abnormality is resolved.

5. The prepaid secure communication method for water and electricity according to claim 1, characterized in that, In step S4, the cloud management platform and the local MQTT client respectively generate cloud-based random numbers. and local random numbers The new communication code is calculated according to the following formula: in, This is a pre-configured system-level authentication key for the cloud management platform and the local MQTT client. This was the original communication code. For water and electricity meter markings, For the handover of readings, This represents the actual disconnected state of the energy supply path. This is the sequence number of the last executed instruction in the original account. Indicates data concatenation; The cloud management platform and the local MQTT client confirm the validity of the handover evidence when their respective calculated new communication codes match.

6. The prepaid secure communication method for water and electricity according to claim 5, characterized in that, Step S4 also includes: The cloud management platform generates a request topic and a response topic for a new account based on the new communication code. The request topic includes, in sequence, a topic prefix, a water / electricity meter identifier, the new communication code, and a request identifier. The response topic includes, in sequence, a topic prefix, a water / electricity meter identifier, the new communication code, and a response identifier. The cloud management platform and the local MQTT client generate a new application-layer authentication key according to the following formula: in, Represents the key derivation function; After the local MQTT client returns confirmation information for the new communication code, the cloud management platform controls the MQTT server to update the topic access control relationship according to the new communication code, so that the new account only has the publish or subscribe permissions for the topic corresponding to the new communication code, and sends an activation response to the local MQTT client. The local MQTT client only enables the new communication codename after receiving an activation response, and maintains a handover lock state until either confirmation process is completed.

7. The prepaid secure communication method for water and electricity according to claim 6, characterized in that, During the handover lockout state, messages carrying the original communication code are stored in the historical audit queue, and messages submitted by the new account during the handover period are stored in the activation queue. After the new communication code is activated, the cloud management platform uses the new communication code and the new application layer verification key to repackage the messages in the queue to be activated, without directly releasing the original messages; The local MQTT client executes the corresponding message only if the communication code in the MQTT topic, the communication code in the message payload, and the message verification code generated based on the new application layer verification key all match. The first message to restore water or electricity supply after the new communication code is activated adopts a control method that sets a target state, and returns the execution result after the energy metering control terminal reports that the target state has been reached.

8. A prepaid secure communication system for water and electricity based on the MQTT protocol, characterized in that, This includes a cloud management platform, an MQTT server, a local MQTT client, a prepaid data interface, and an energy metering and control terminal; The cloud management platform is used to initiate account handover, verify handover evidence, coordinate with the local MQTT client to generate new communication codes, and control the activation of communication permissions for new accounts. The MQTT server is used to transmit account handover data and prepaid water and electricity service messages between the cloud management platform and the local MQTT client, and manage access permissions for corresponding MQTT topics according to the new communication code. The local MQTT client is used to respond to account handover and enter the handover lock state, control the energy metering control terminal to form on-site handover readings, generate handover evidence, confirm the new communication code, and execute or isolate the control message according to the communication generation to which the message belongs; The prepaid data interface is used to store the account binding relationship of water and electricity meters, cumulative meter readings, communication codes, and executed instruction records; The energy consumption metering and control terminal is used to measure actual consumption, control the on / off state of energy consumption channels, and provide feedback on the actual status of energy consumption channels.

9. The prepaid secure communication system for water and electricity according to claim 8, characterized in that, The energy metering and control terminal includes a water meter, an electrically controlled water valve and a valve position feedback unit, or includes an electricity meter, an on / off relay and a contact feedback unit. The metering data output terminal of the water meter or electricity meter and the status output terminal of the valve position feedback unit or contact feedback unit are respectively connected to the data input terminal of the local MQTT client, and the control output terminal of the local MQTT client is connected to the electric water valve or on / off relay. The prepaid data interface stores the account binding change sequence number, the current communication code, the handover reading, and the sequence number of the last executed instruction of the original account, and provides account handover data to the cloud management platform and the local MQTT client. The local MQTT client, in the handover locked state, only enables the functions of disconnecting the power supply path, collecting meter readings, collecting terminal status, and uploading handover evidence.

10. The prepaid secure communication system for hydropower according to claim 8, characterized in that, The cloud management platform includes a handover management module and a topic permission management module, and the local MQTT client includes a physical handover determination module, a communication code confirmation module, and a message execution isolation module. The handover management module is used to generate a handover freeze flag, verify the handover evidence sent by the local MQTT client, and use the handover reading as the starting point for the new account's metering. The physical handover determination module is used to receive the actual feedback status of the energy consumption path and the continuous cumulative meter reading, and output the handover reading or the abnormal lock result. The communication code confirmation module is used to take handover evidence, cloud random number and local random number as input, generate a new communication code and a new application layer verification key with the cloud management platform respectively, and output confirmation information when the calculation results are consistent. The topic permission management module is used to generate request topics and response topics according to the new communication code, update the topic access control relationship of the MQTT server, and send an activation response after the update is completed; The message execution isolation module is used to determine the execution qualification of a message based on the communication code in the MQTT topic, the communication code in the message payload, and the message verification code. It transfers the message corresponding to the original communication code to the historical audit queue and converts the first message to restore water or electricity after the new communication code is enabled into a control command for the set target state.

Images