Intelligent internet-of-things management and control system for centralized houses

Abstract

The invention relates to the field of house rental management, and discloses a centralized house-oriented intelligent Internet of Things management and control system, which comprises the steps of: after receiving user rental demand parameters in real time, matching a target house in a preset house database and generating rental information; inputting the information into a preset intelligent contract system, converting the information into a house leasing contract, and fusing user identity information to generate a target leasing contract; acquiring water and electricity data and equipment operation state data acquired by the house internet-of-things equipment in real time, and fusing the data into the target lease contract to complete lease; and processing the equipment repair request in the lease period, monitoring the data of the internet of things in real time, carrying out early warning, and reminding lease renewal or lease cancelling before the lease period expires. According to the method, multi-dimensional demands are integrated by constructing a demand data chain, and house resources are selected by calculating the matching degree in combination with house parameter thresholds; lease information is automatically transferred into a standard contract by means of an intelligent contract, and identity and contract information are encrypted in a partition mode to guarantee safety; precise repair matching is achieved in the lease period, and water, electricity and equipment are monitored through the internet of things and early warning is conducted.

Description

Technical Field

[0001] This invention relates to the field of housing rental management, and in particular to a smart IoT management and control system for centralized housing. Background Technology

[0002] With the acceleration of urbanization, the centralized housing rental market continues to expand, with an explosive growth in both the number of available properties and tenant demand. Traditional rental management models are no longer adequate to meet the industry's development needs. In the property matching process, tenants' rental needs are becoming increasingly diversified, encompassing multiple dimensions such as lease term, apartment type, water and electricity configuration, facilities, and floor orientation. However, existing management systems often rely on fragmented parameter comparisons, lacking a structured demand integration mechanism. Most systems can only perform simple filtering based on a single or a few dimensions, failing to systematically integrate tenants' multi-dimensional needs. This leads to a chaotic matching logic between demand and available properties, often resulting in partial parameter matching but mismatched core requirements. Furthermore, the lack of consistency and standardization among various parameters in the housing database further reduces matching accuracy. This not only forces tenants to spend a significant amount of time filtering properties but also increases the cost of manual intervention for management, resulting in low efficiency in rental matching.

[0003] The generation and management of housing rental contracts suffer from numerous pain points. Traditional models rely on manual contract drafting, which is not only cumbersome and time-consuming but also prone to omissions and errors in wording, creating potential for future rental disputes. More critically, the lack of standardized procedures for linking contracts to user identity information, coupled with a disconnect between identity verification and contract signing, poses security risks such as contract tampering and identity theft. Furthermore, crucial information such as water and electricity usage data and equipment operating status generated during the rental process is not effectively linked to the rental contract and is often stored in a fragmented manner. This makes it difficult for management to quickly verify data and for tenants to clearly understand usage details, impacting payment and settlement efficiency and hindering the determination of responsibilities during the rental period. Information asymmetry and security risks are significant factors restricting the improvement of the rental experience.

[0004] In the operation and maintenance management of leased equipment, the inefficiency and lack of standardization in the equipment repair and maintenance process are particularly prominent. Traditional repair reporting relies on tenant phone calls or offline applications, resulting in untimely transmission of repair requests and a lack of a unified equipment identification system, making it difficult for repair personnel to quickly locate faulty equipment. Matching repair requests with maintenance resources relies entirely on manual scheduling, leading to long response times and resource mismatches such as tenants urgently needing repairs while maintenance personnel are idle or no one is available to handle repair requests. Furthermore, the lack of effective control over maintenance permissions, coupled with the absence of identity verification and permission revocation mechanisms for maintenance personnel entering the site, poses security risks such as equipment misoperation and unauthorized access. In addition, the existing system lacks real-time monitoring capabilities for water and electricity data and equipment operating status during the lease period, failing to promptly detect abnormal usage or equipment malfunctions. Moreover, renewal and termination reminders rely on manual records, which are prone to omissions, resulting in lax lease management and ineffective protection of tenant experience and property security. Summary of the Invention

[0005] To address the shortcomings of existing technologies, this invention discloses a smart IoT management and control system for centralized housing that can increase the efficiency of matching user needs with housing and improve maintenance efficiency.

[0006] This invention discloses a smart IoT management and control system for centralized housing, comprising: upon receiving rental demand parameters input by a user in real time, matching the corresponding target housing in a preset housing database according to the rental demand parameters and generating housing rental information; inputting the housing rental information into a preset smart contract system to convert it into a housing rental contract, and integrating the user's identity information with the housing rental contract to generate a target rental contract; acquiring water and electricity data and equipment operation status data of the target housing collected by the housing IoT devices in real time and integrating them into the target rental contract to complete the housing rental; during the rental period, processing equipment repair and maintenance requests, monitoring IoT data in real time and issuing anomaly warnings, and reminding the tenant to renew or terminate the lease before the expiration date.

[0007] Furthermore, the steps for matching target properties based on rental demand parameters include: parsing rental demand parameters and constructing a demand data chain; detecting several coherent property parameter thresholds in a preset property database, calculating the matching degree between the demand data chain and each property parameter threshold, and matching target properties based on the matching degree.

[0008] Furthermore, matching the target house based on the matching degree includes: determining in real time whether the matching degree is greater than a preset matching degree threshold; if the matching degree is determined to be greater than the preset matching degree threshold in real time, then detecting the target house parameter threshold corresponding to the preset matching degree threshold, and generating the corresponding target data chain based on the target house parameter threshold; and matching the target house in the preset house database based on the size of the target data chain.

[0009] Furthermore, the steps for generating the target rental contract include: creating a blank contract template, mapping the user's identity information and the housing rental contract into the template, generating corresponding identity and contract fields, and setting a dividing line.

[0010] Furthermore, the steps for processing equipment repair requests include:

[0011] When a repair request for a target device is received from a tenant, the device's electronic identifier associated with the repair request is obtained.

[0012] Based on the device's electronic identifier, match maintenance instructions sent by the maintenance terminal that are associated with the same device's electronic identifier in the task pool to be processed;

[0013] When the repair request and maintenance command are successfully matched, the corresponding maintenance terminal is authorized to perform maintenance operations on the target device.

[0014] Furthermore, once the maintenance terminal is authorized, if it receives a first authentication signal from the smart device node containing the maintenance personnel's identity information and the device's electronic identifier, it verifies the identity information and the electronic identifier.

[0015] After successful verification, an unlock command is sent to the smart device node to allow the maintenance terminal to operate the target device.

[0016] Furthermore, upon receiving a maintenance completion signal from the intelligent device node, a lock command is sent to the node to revoke its operating privileges.

[0017] Send a confirmation request containing the repair results to the tenant's end;

[0018] Once confirmation is received from the tenant, the maintenance process is recorded and archived.

[0019] Furthermore, if the repair request fails to match the corresponding maintenance request within a preset time, a task alarm is generated and sent to the higher-level management terminal based on the historical maintenance records and current fault level of the target device.

[0020] Furthermore, if the repair instruction fails to match the corresponding repair request within a preset time, the repair terminal is granted general repair permissions for devices of the same type as the electronic identification device. The scope, validity period, and operation type of the general repair permissions are predefined by the housing management terminal.

[0021] Furthermore, it includes a user interaction module, a housing database module, a demand matching module, a smart contract module, an IoT data collection module, and a lease term management module:

[0022] The user interaction module is used to receive tenants' rental needs, repair requests and payment instructions, repair instructions from the repair terminal, and push housing results, contracts, warnings, reminders and usage reports.

[0023] The housing database module stores basic housing information, housing parameter thresholds, electronic identification, and historical maintenance records. The housing parameter thresholds are consistent.

[0024] The demand matching module parses rental demands, constructs a demand data chain, calculates its matching degree with housing parameter thresholds, filters target houses, and generates rental information.

[0025] The smart contract module converts rental information into contracts, integrates user identity information, and generates the target rental contract by encrypting the identity and contract content in different areas.

[0026] The IoT data acquisition module collects data on the building's water and electricity supply and equipment operating status, and integrates the data into the target rental contract;

[0027] The lease term management module handles equipment repair requests, monitors IoT data and issues alerts, reminds users to renew or terminate the lease before its expiration, and generates monthly usage reports.

[0028] The beneficial effects of this invention are:

[0029] This invention provides a smart IoT management and control system for centralized housing, improving the efficiency and accuracy of the entire housing rental process and building an efficient and collaborative rental ecosystem for tenants and managers. In the housing matching stage, the system constructs a structured demand data chain by parsing rental demand parameters and compares it against consistent housing parameter thresholds in the database. This achieves seamless matching of demand and housing availability, avoiding the logical confusion and inefficiency of traditional fragmented parameter matching. This allows tenants to quickly find target housing that meets their multi-dimensional needs, while reducing the time cost of manual screening for managers. In the contract generation stage, the smart contract system automatically converts rental information into standardized contracts. After integrating user identity information, it performs partitioned encryption processing, eliminating errors and tampering risks associated with manual drafting and ensuring the security of identity information and contract content. This achieves standardized, automated, and secure contract generation. The real-time integration of IoT data and rental contracts deeply binds key information such as water and electricity usage and equipment status to the contract, providing data support for subsequent rental management and promoting efficient operation of the entire rental process from connection and signing to data integration.

[0030] The intelligent IoT management and control system improves the quality of operation and maintenance services and the efficiency of resource utilization through an intelligent lease term management mechanism, achieving refined and sustainable lease management. Regarding equipment repair and maintenance, a rapid matching channel for repair requests and instructions is established based on electronic equipment identification. Upon successful matching, repair operations are authorized through dual authentication. After repair, permissions are promptly locked and the tenant confirms and archives the work, forming a clear, traceable, and secure closed loop. This shortens repair response time and eliminates the risk of unauthorized operations. For matching timeout scenarios, the system triggers alarms or grants general repair permissions through fault level assessment. This ensures timely responses to tenant requests and transforms the standby time of repair personnel into preventative maintenance work, improving human resource utilization. Simultaneously, the system monitors IoT data in real time, providing timely warnings for abnormal water and electricity usage, equipment malfunctions, and other situations. It automatically reminds tenants to renew or terminate leases upon expiration and generates monthly usage reports. This allows management to accurately grasp the status of the property and equipment, proactively avoid risks, reduce operation and maintenance costs, and provides tenants with a transparent and convenient leasing experience, achieving a win-win situation for both management and tenants. Attached Figure Description

[0031] Figure 1 This is a flowchart of a smart IoT management and control system for centralized housing, as described in this application.

[0032] Figure 2 This is another flowchart of a smart IoT management and control system for centralized housing, as described in this application.

[0033] Figure 3 This is another flowchart of a smart IoT management and control system for centralized housing, as described in this application.

[0034] Figure 4 This is another flowchart of a smart IoT management and control system for centralized housing, as described in this application.

[0035] Figure 5 This is a system diagram of a smart IoT management and control system for centralized housing, as described in the embodiments of this application.

[0036] Figure 6 This is a system diagram of a smart IoT management and control system for centralized housing, as described in the embodiments of this application.

[0037] Figure 7 This is another system diagram of a smart IoT management and control system for centralized housing, as described in this application.

[0038] Figure 8 This is another system diagram of a smart IoT management and control system for centralized housing, as described in this application.

[0039] Figure 9 This is another system diagram of a smart IoT management and control system for centralized housing, as described in this application. Detailed Implementation

[0040] To enable those skilled in the art to better understand the present invention, the technical solutions in the specific embodiments of the present invention will be clearly and completely described below.

[0041] This invention discloses a smart IoT management and control system for centralized housing. The system includes: when the smart IoT management and control system receives rental demand parameters input by a user in real time, matching the corresponding target housing in a preset housing database based on the rental demand parameters and generating housing rental information; inputting the housing rental information into a preset smart contract system to convert it into a housing rental contract, and integrating user identity information with the housing rental contract to generate a target rental contract; the smart IoT management and control system acquires water and electricity data and equipment operating status data collected by the housing IoT devices in real time and integrates them into the target rental contract, sending the target rental contract to the user's corresponding user terminal in real time, and receiving confirmation information from the user corresponding to the target rental contract through the user terminal in real time to complete the housing rental; during the rental period, processing equipment repair and maintenance requests, monitoring IoT data in real time and issuing anomaly warnings, and reminding the user to renew or terminate the lease before its expiration.

[0042] User identity information is obtained by guiding users through a real-name authentication process on the terminal via a user interaction module. This includes, but is not limited to: users directly uploading photos or scans of official documents such as ID cards and passports, which the system then performs optical character recognition and preliminary verification; calling nationally authorized third-party real-name authentication service interfaces, such as mobile phone number authentication interfaces from telecom operators or bank identity authentication interfaces, where, after authorization, the system can verify the consistency between the user's name and ID number; and employing liveness detection technology to require users to perform facial recognition, comparing the results with an official identity information database. All acquired identity information is encrypted before being transmitted to the smart contract module for subsequent operations.

[0043] Step 1: The smart IoT management system receives user requests, such as requirements for renting a 1-bedroom apartment for 3 months, with independent water and electricity meters, a private bathroom, at least two desks, at least two refrigerators with a capacity of more than 20 liters, etc. The system then builds a housing database in advance, which stores information on all available rental properties. This database is used to find matching properties and generate rental information for the property that meets the requirements, such as address, rent, apartment type, water and electricity standards, lease term, and penalty for breach of contract.

[0044] The second step is to put the rental information into the smart contract system. The smart contract system is actually an automatically executed and tamper-proof digital contract tool. The smart contract system automatically converts the information into a standardized housing rental contract, avoiding errors or tampering caused by manual contract drafting.

[0045] The third step: The smart IoT management system will obtain the user's identity information in real time, such as ID card information and real-name authentication information; then it will integrate the user's identity information with the previously generated housing rental contract, such as associating the identity information with the housing rental contract, that is, writing it into the housing rental contract, to ensure that the contract corresponds to a specific user, and finally generate an exclusive target rental contract. At this time, the contract has been bound to the user's identity and is a personalized contract for that user.

[0046] Step 4: The smart IoT management system will send the target rental contract to the user's terminal in real time, such as the user's mobile phone, computer, email, etc. After the user views the contract on the terminal, if they agree, they will enter confirmation information, such as clicking the confirmation button or entering a confirmation password. Once the smart contract system receives the confirmation information in real time, the rental process for the house is completed. The smart IoT management system, as shown... Figures 5-9 As shown in the image.

[0047] As one implementation method, the steps of matching target houses based on rental demand parameters include parsing rental demand parameters and constructing a demand data chain; detecting several house parameter thresholds with coherence in the preset house database; calculating the matching degree between the demand data chain and each house parameter threshold; matching target houses based on the matching degree; and the preset matching degree thresholds are uniformly configured and managed by the house management terminal in the system backend according to the house type, rental strategy and market conditions to control the baseline quality of house recommendations.

[0048] Once the user's rental demand parameters are obtained in real time, these parameters are first analyzed and processed to detect several pieces of information contained in the demand, such as the rental period (e.g., 3 months or 1 year), the apartment type (e.g., one bedroom and one living room, two bedrooms and one bathroom), water and electricity requirements (e.g., whether there are independent water and electricity meters, whether there is natural gas), whether it faces south, whether it has a balcony, the floor level, and whether it is close to the entrance of the community. Then, this key information is integrated to build a demand data chain, which is an ordered data stream containing all demand dimensions. Finally, based on the demand data chain, matching houses are searched in a pre-set housing database.

[0049] Specifically, to ensure system compatibility, the demand data chain is instantiated as a structured data object within the system. This object is organized in key-value pairs, mapping each rental demand parameter to a specific field and its value. For example, after parsing the user's natural language input, the system generates a standard demand data chain structure as shown below (in JSON format): {"lease term (months)": 3, "apartment type": "one-bedroom", "independent water and electricity": true, "orientation": "south", "floor preference": "low floor", "facilities required": ["independent bathroom", "balcony"]}.

[0050] This structured data chain serves as a unified, computable data unit for subsequent quantitative matching with building parameters.

[0051] To transform user natural language requirements into a structured data chain of needs, the smart IoT management system employs natural language processing (NLP) technology, combining keyword extraction and semantic analysis modules for parsing. First, the system extracts high-frequency keywords from user input text using the TF-IDF algorithm, and then uses a pre-trained language model for semantic understanding, identifying the specific meaning and contextual relationships of the keywords. For example, "private bathroom" is parsed as "independent toilet" and mapped to the facility requirements field, while "near subway station" is located using entity recognition technology to pinpoint the geographical location parameter. Subsequently, the smart IoT management system utilizes a rule engine and contextual analysis to integrate scattered semantic fragments into multi-dimensional structured parameters, such as rental preferences, facility configuration, and private toilet, ultimately forming standardized entries that conform to the requirements data chain format.

[0052] Based on the demand data chain, the system continuously monitors several housing parameter thresholds stored in the pre-set housing database. These thresholds represent the standard ranges for each housing unit across various dimensions. For example, a housing unit might have a rental term threshold of 1-2 years, a unit type threshold of two bedrooms and one living room, and a water and electricity configuration threshold of independent water and electricity plus natural gas. The consistency between these thresholds means that the thresholds for the same housing unit are mutually matched, preventing contradictory situations such as a 1-year rental term threshold but a 3-bedroom unit without water and electricity configuration. Next, the system calculates the matching degree between the demand data chain and the housing parameter thresholds for each housing unit in the database. For instance, if a user's demand is a 1-year rental, one-bedroom unit, and independent water and electricity, and a housing unit's threshold is 1-2 years, the matching degree is high; conversely, if a housing unit's threshold is 2-3 years, two bedrooms and one living room, and independent water and electricity, the matching degree is low. Finally, based on the calculated matching degree, the system finds the corresponding target housing unit in the database.

[0053] The specific method for calculating the matching degree between the demand data chain (denoted as vector D) and a certain housing parameter threshold vector (denoted as vector H) in the housing database is as follows: a weighted similarity synthesis algorithm is used. First, a weight coefficient w_i is preset for each demand dimension (such as lease term, apartment type, facilities, etc.), with a total weight of 1. Then, for each dimension, a suitable similarity function sim_i(D_i, H_i) is selected according to its data type (such as numeric, boolean, enumerated) to calculate the matching score (normalized to between 0 and 1) between the demand value and the housing value in that dimension. Administrators can adjust these weights according to actual operation strategies to customize the matching degree calculation rules. The final formula for calculating the overall matching degree MatchScore is:

[0054] ;

[0055] The system traverses the housing database, calculates the matching score for each property, and sorts them from high to low scores, using this as a quantitative basis for recommending target properties.

[0056] The Demand Data Chain addresses the issues of accuracy, efficiency, and compatibility with smart IoT management systems in multi-parameter matching scenarios. It transforms disparate demand parameters into structured, computable, and identifiable units.

[0057] Demand data chains resolve the chaos of fragmented matching of multiple parameters, achieving structured integration. Rental demand is a combination of multiple dimensions, not a single parameter. For example:

[0058] User requirements might include a 3-month lease term, a 1-bedroom apartment, a separate electricity meter, a balcony, and a low floor.

[0059] Another user might have a 3-month lease, a 2-bedroom apartment, a shared electricity meter, a balcony, and a lower floor.

[0060] If matching is done directly using scattered parameters, the smart IoT management system needs to compare the lease term, apartment type, and utility configuration separately, and then manually combine the results. This process may result in parameter cross-interference; for example, apartment A might have a matching lease term but a mismatched apartment type, while apartment B might have a matching apartment type but a mismatched lease term. The smart IoT management system would then need to repeatedly filter these parameters. The demand data chain, however, essentially connects these scattered parameters into an indivisible whole according to a fixed logic, such as forming a chain like X-3M-1R-IndepElec based on the order of lease term, apartment type, and utility configuration. The smart IoT management system can directly use this whole as the matching unit, avoiding the logical confusion of comparing multiple parameters individually. It's like giving a set of requirements a unified label. X represents the example user.

[0061] In real-world scenarios, different users may have some overlapping parameters. For example, two users may both want a one-bedroom apartment, but their overall needs may differ. The needs of the same user may also change at different times, such as initially wanting to rent for 3 months but later changing it to 6 months.

[0062] To improve matching efficiency, the system adapts to the consistency of housing parameter thresholds. The pre-set housing database contains several housing parameter thresholds, each with consistency between them. Consistency refers to the housing parameters in the database forming a complete system arranged in a logical gradient. For example, the lease term threshold might be 1M / 3M / 6M / 12M, forming a consistent time gradient; the apartment type threshold might be 1R / 2R / 3R, forming a consistent spatial gradient.

[0063] The role of the demand data chain is to form a whole-to-whole matching relationship with this coherent threshold system. For example, the demand data chain is X-3M-1R-IndepElec, where user X+3 months+1 room+independent electricity meter; the housing parameter thresholds in the database are coherent chains formed by lease term gradients+ apartment type gradients+water and electricity configuration types, such as X-1M-1R-SharedElec-X-3M-1R-IndepElec-X-3M-2R-IndepElec-... In this case, the smart IoT management system can directly perform a linear comparison between the demand data chain and the coherent threshold chain in the database to quickly find the closest threshold combination; while if scattered parameters are used for matching, it is necessary to search separately in the lease term gradient, apartment type gradient, and water and electricity configuration, and then combine the results, which is far less efficient than a direct chain-to-chain comparison.

[0064] The matching degree between the demand data chain and each housing parameter threshold is calculated one by one. Matching degree calculation requires a quantifiable unit of comparison: if scattered parameters are used, the matching degree needs to be calculated separately for lease term matching degree, apartment type matching degree, and water and electricity configuration matching degree, and then a weighted formula needs to be designed to integrate them, such as lease term accounting for 40% and apartment type accounting for 30%, etc., which is complex and prone to deviation due to unreasonable weight settings. Using the demand data chain, the chain can be regarded as a multi-dimensional vector. Through vector similarity algorithms, such as cosine similarity, the overall matching degree between the demand chain and the housing threshold chain can be directly calculated. This simplifies the calculation logic and reflects the overall correlation of parameter combinations. For example, the combination logic of 3 months + 1 bedroom is more practically meaningful than looking at 3 months and 1 bedroom separately.

[0065] Demand data chains, as a structured data format, can be directly recognized by smart contract-based smart IoT management systems without re-parsing fragmented parameters. They can be linked to data collected from IoT devices in the home, such as water and electricity usage and device status; for example, the demand data chain identifier can be used to bind the corresponding IoT demand data chain for a given house. This facilitates subsequent contract encryption and categorized storage, such as archiving contracts and IoT data according to the demand data chain identifier. Without demand data chains, fragmented parameters, during their flow through multiple stages in a smart IoT management system, are prone to problems such as inconsistent formats and lost relationships; for example, smart contracts may be unable to recognize the combination logic of lease terms and apartment types.

[0066] As one implementation method, matching a target house based on the matching degree includes real-time determination of whether the matching degree is greater than a preset matching degree threshold; if the real-time determination shows that the matching degree is greater than the preset matching degree threshold, the corresponding target house parameter threshold is detected, and a corresponding target data chain is generated based on the target house parameter threshold; the target house is matched in a preset house database based on the size of the target data chain. The step of generating a target rental contract includes creating a blank contract template, mapping the user's identity information and the house rental contract to the template, generating corresponding identity fields and contract fields, and setting a boundary line.

[0067] To ensure information security, the smart contract module employs an asymmetric encryption algorithm to independently encrypt different parts of the target rental contract. Specifically, the system generates independent key pairs for identity information and contract content. The user's identity information is encrypted and stored using the first public key pair, while the corresponding private key is kept by the system's security module. The rental contract terms are encrypted using a second independent public key pair. The encrypted contract content can be submitted to a blockchain network or a protected distributed storage system for notarization, ensuring its immutability. The boundary is represented in the electronic contract data structure as a logical partition identifier, used to instruct the encryption module to process the two parts of the data using different keys.

[0068] The size of the target data chain is a numerical metric, rather than its physical dimensions, used to quantify the overall quality of the match between target properties and tenant needs. Its calculation is based on the structured parameters contained in the target data chain, derived through a pre-defined evaluation model. This model primarily considers two dimensions: parameter completeness (the proportion of target property parameters that cover the number of tenant need parameters) and data accuracy (the degree of closeness between the target property parameter values ​​and the tenant need values). The system uses a weighted algorithm to combine the scores of these two dimensions into a total score, which represents the size of the target data chain. For example, if completeness score accounts for weight A and accuracy score accounts for weight B, then the size = A * completeness score + B * accuracy score. By comparing this size value, the system can prioritize multiple properties that meet the criteria.

[0069] To ensure information security, the system employs industry-standard asymmetric encryption algorithms to independently encrypt the identity and contract sections of the target rental contract. Specifically, the system uses the RSA algorithm to generate a public-private key pair. The user's identity information (identity section) is encrypted and stored using a specific public key, PubKey_ID, held by the system, while the corresponding private key, PriKey_ID, is stored by the system's security module and used for authorized decryption. The rental contract content (contract section) is processed using another independent public-private key pair (PubKey_Contract, PriKey_Contract). This dual independent encryption mechanism ensures that even if one encryption step is compromised, the other part of the information remains secure.

[0070] Matching degree threshold judgment: The smart IoT management system will first determine in real time whether the previously calculated matching degree is greater than the preset matching degree threshold. The preset matching degree threshold is a pre-set minimum standard for judging whether a house meets the user's needs. For example, the matching degree must be ≥80% to be considered as meeting the needs. The preset matching degree threshold can be configured by the house management terminal according to the house type: high-end apartments / ordinary shared rentals / detached houses.

[0071] Target parameter threshold and target data chain generation: If it is determined in real time that the matching degree is greater than the preset matching degree threshold, that is, the house meets the requirements, the target house parameter threshold corresponding to this preset matching degree threshold will be detected. That is, the parameter threshold of the house that meets the matching degree standard. For example, if the user's requirement matching degree is 85%, the corresponding parameter threshold is the parameter threshold of the house with a matching degree of 85%. Then, the target data chain is generated based on this target house parameter threshold, which is equivalent to integrating the parameters of the qualified houses into an ordered data stream.

[0072] Target property determination: Based on the size of the target data chain, which includes the completeness and accuracy of the parameters contained in the target data chain, such as the lease term, apartment type, water and electricity, orientation, floor and other dimensions, the target property is accurately matched in the preset property database. The target property can be a single property that best meets the user's needs, or multiple qualified properties, for the user to choose from.

[0073] First, calculate the parameter dimension completeness score, which is the percentage of parameters covering the tenant's needs. For example, if a tenant submits 5 needs and the property parameters cover 4 of them, the score is 80. Then calculate the data accuracy score, which is the error rate between the property parameters and the needs parameters. For example, if the tenant needs a 3-month lease term and the property's lease term is 3-4 months with a 0% error rate, the score is 100. The required area is 60m². 2 The house has an area of ​​55m² 2 An error rate of 8.3% yields a score of 91.7. The weighted total score is then calculated with 60% for dimensional integrity and 40% for data precision. This total score represents the size of the target data chain.

[0074] The target data chain is a key carrier for structuring the parameters of qualified houses after the demand data chain matches the houses that meet the conditions. Its function is to transform the parameters of houses that meet the matching degree requirements into comparable and sortable identifiers, and ultimately lock the target house from multiple qualified houses.

[0075] The essence of the target data chain is a structured chain of qualified housing parameters. When the demand data chain, i.e. the structured expression of user demand, is compared with the housing parameter threshold in the database, i.e. the preset standard of housing information, the matching degree exceeds the preset threshold, such as 80% of the housing parameter threshold. It will be extracted by the smart IoT management and control system and linked together into a complete target data chain according to a fixed logic, such as the order of lease term-unit type-water and electricity configuration.

[0076] Demand Data Chain: This refers to the structured data object formed after the system analyzes and standardizes the diverse rental needs input by users. It is used to represent a complete tenant demand profile. For example: {"leaseTerm": 3, "layoutType": "one bedroom and one living room", "hasIndependentUtility": true}.

[0077] "Target Data Chain": This refers to the structured data object formed by standardizing and encapsulating all parameters of candidate houses selected by the system from the housing database that meet the matching criteria of the "Demand Data Chain". It is used to represent the complete asset profile of a rentable house. For example: {"houseId": "A101", "leaseTermRange": [1, 12], "layoutType": "One bedroom and one living room", "area": ​​50, "utilityConfig": ["Independent electricity meter", "Independent water meter"]}.

[0078] The "demand data chain" serves as the query condition, and is matched against the original parameters of the houses in the database. Upon successful matching, the system extracts and structures all key parameters of the selected house (not just those mentioned in the demand) to generate the "target data chain." The former is an abstraction of the demand, while the latter is a complete description of the house asset; the two are linked through a matching degree calculation.

[0079] For example:

[0080] The user's demand data chain is X-3M-1R-IndepElec, with the user having an X+3 month lease term, 1 bedroom, and an independent electricity meter.

[0081] There may be two houses in the database whose parameter thresholds match by more than 80%.

[0082] House A: 3M-1R-IndepElec, 100% match;

[0083] House B: 3M-1R-SharedElec, 90% match, only slightly different in water and electricity configuration;

[0084] The smart IoT management system will generate target data chains for these two houses respectively: chain A is X-3M-1R-IndepElec, and chain B is X-3M-1R-SharedElec.

[0085] In real-world scenarios, different properties may have some overlapping parameters—for example, multiple properties may all be one-bedroom apartments—but their complete parameter combinations will definitely differ, such as lease terms and utility configurations. The target data chain structures the property parameter thresholds as a whole, ensuring that even if some parameters are the same, the overall chain for each qualified property is different. For instance, in the example above, although chains A and B share some parameters, their overall chains are different, which the smart IoT management system can clearly distinguish.

[0086] The target data chain achieves precise screening of optimal houses by size; the target houses are matched in the preset house database module according to the size of the target data chain. Here, size is not physical size, but a quantitative representation of the matching quality of the parameters contained in the target data chain, which is a priority ranking of qualified houses.

[0087] The logic for determining size can include:

[0088] Chains with perfectly matched parameters are larger: For example, if chain A is 100% matched with the requirement data chain, and chain B has one parameter that is not perfectly matched (90%), then chain A is larger than chain B.

[0089] Chains with higher weighting for key parameters are longer: If the smart IoT management system sets the lease term as a key parameter, and the lease term of one house is a perfect match for the demand, while the lease term of another house is only a match for the apartment type, then the former chain is longer.

[0090] The target data chain contains more complete and larger effective parameters: for example, the parameter thresholds of a house include 4 items: lease term + apartment type + water and electricity + orientation, while another house only includes 2 items: lease term + apartment type. In this case, the former chain is larger.

[0091] By comparing the sizes, the smart IoT management system can select the optimal solution from multiple qualified houses and finally lock the target house. For example, in the example above, chain A is greater than chain B, so house A is selected.

[0092] If multiple properties have the same target data chain size (i.e., parameter matching quality quantification value), the target properties will be filtered according to the following priorities: First priority: rent lower than the average rent of the same type of unit in the same area, updated in real time by the property database module; Second priority: no maintenance records in the past 3 months, queried from the historical maintenance records of the property database module; Third priority: distance from the tenant's specified commuting location. If the tenant's requirements include a commuting location, the closer straight-line distance will be calculated using the map API. The specific priority determination can also be adjusted according to the tenant's needs.

[0093] The target data chain connects subsequent processes, achieving seamless integration across the entire chain from property selection to contract signing and IoT connectivity. As a structured identifier for property parameters, the target data chain is not only used for property selection but also serves as a data anchor for subsequent processes.

[0094] Generating rental information: The target data chain is directly linked to specific information about the property, such as address, rent, and equipment configuration. The smart IoT management and control system can quickly extract this information based on the chain to generate rental information.

[0095] Connecting to smart contracts: The smart contract system can directly identify the structured format of the target data chain and convert it into the basic terms of the house in the contract, such as the lease term clause in the contract corresponding to a 3-month lease term.

[0096] Linking IoT data: Data collected by subsequent IoT devices such as water and electricity meters and sensors in the house will be bound to the house through the identifier of the target data chain, realizing a precise association between the house, contract and IoT data. For example, the real-time water and electricity data of the house can be queried using the identifier of the target data chain.

[0097] The target data chain packages the parameters of eligible houses into structured data tags to avoid the screening chaos caused by scattered parameters; it prioritizes the houses by comparing their sizes to ensure that the optimal solution is selected from multiple qualified houses; and as a unified data format, it runs through the entire process of house selection, contract signing, and IoT monitoring to ensure the compatibility of all aspects of the smart IoT management and control system.

[0098] Blank Template and Information Mapping: After the smart contract system obtains the user's identity information and the previously generated housing rental contract, it will create a blank contract template in real time, which is equivalent to a standard contract form without any content. Then, the identity information, such as the user's name and ID number, and the housing rental contract, such as rent, lease term, and housing information, are mapped to this blank template. That is, the identity information is filled into the identity-related positions of the template, and the rental contract content is filled into the contract-related positions of the template.

[0099] Partitioning and Encryption of the Target Contract: The smart contract system generates a dividing line in real-time within the blank contract template. This dividing line separates the template into two areas: the identity section, specifically for storing user identity information, and the contract section, specifically for storing the rental contract content. The smart contract system then encrypts both the identity and contract sections separately, using encryption algorithms to protect information and prevent identity information leakage or contract content tampering. After encryption, the target rental contract is generated. This contract contains both identity information and contract content, and its security is guaranteed. The dividing line is an identifier used in the electronic document data structure that generates the target rental contract to logically separate the user identity information data block from the rental contract content data block. The portion before the dividing line is the identity section, which requires processing using the first encryption strategy; the portion after the dividing line is the contract section, which requires processing using a second, independent encryption strategy.

[0100] When a target lease agreement is acquired in real time, the system retrieves real-time water and electricity data and equipment operation status data collected by the building's IoT devices. This data is then integrated into the target lease agreement, such as as an attachment, to generate a final lease agreement containing IoT monitoring information. Upon acquiring the target lease agreement, the system also retrieves the corresponding lease term and adds a target identifier to the agreement based on the lease term. This identifier is used to categorize and store the target lease agreement and associated building IoT data. During the lease term, the system monitors all data uploaded by the building's IoT devices in real time. If any data anomalies are detected, such as a sudden increase in water and electricity usage or equipment malfunction, an alert is immediately sent to the user terminal and the building management terminal for timely handling. When the lease term is about to expire, if it is 7 days in advance, the smart IoT management system automatically sends a renewal reminder to the user terminal. If the user chooses to renew, the system automatically retrieves the original target lease agreement, updates the lease term and other relevant information, and generates a new lease agreement. If the user does not renew, the system reminds them to complete the termination procedures and related precautions.

[0101] During IoT data monitoring, if the data acquisition module consistently fails to receive data streams from a specific device, or if the received data consistently exceeds a reasonable threshold (which is a fixed, conventional value, such as basic thresholds for water and electricity usage set according to apartment type: 200 kWh of electricity and 10 tons of water per month for a one-bedroom apartment; 300 kWh of electricity and 15 tons of water per month for a two-bedroom apartment), exceeding these thresholds will be considered an anomaly by the system. In this case, the system will send an anomaly alarm to the rental period management module and simultaneously attempt to activate a backup communication link or trigger a device self-test command. All anomaly events, processing actions, and recovery statuses are recorded, forming an anomaly handling log for traceability and analysis.

[0102] As one implementation method, the steps for processing equipment repair requests include: when a repair instruction for a target device is received from a tenant, obtaining the device's electronic identifier associated with the repair instruction; based on the device's electronic identifier, matching repair instructions sent by a repair terminal that are associated with the same device's electronic identifier in the pending task pool; when a repair instruction and a repair instruction match successfully, authorizing the corresponding repair terminal to perform repair operations on the target device. The repair instruction must at least include a list of skill tags, a serviceable area, and a valid time period.

[0103] The pending task pool is a dynamic data structure maintained in memory or a database by the lease management module. It temporarily stores all pending repair and maintenance instructions. The data format is a list or queue, with each record containing key fields such as instruction type, device electronic identifier, generation time, and status (e.g., pending matching, matched). When the user interaction module receives a repair instruction from a tenant or a service instruction proactively submitted by a maintenance provider, it formats and sends it to the lease management module, which then stores it as a new record in the pending task pool. The system continuously scans the instructions in the pool, matching them based on the device electronic identifier. Upon successful matching, the status of the relevant instruction is updated and it is removed from the main matching queue, entering the processing flow.

[0104] It is important to note that the maintenance instructions in this invention differ from the traditional response-to-specific-repairs model. They stem from a proactive and flexible management design for maintenance resources. In this system, maintenance personnel (the maintenance end) can proactively submit their service time slots, the types of equipment they are skilled at repairing (e.g., air conditioners, plumbing, smart locks), and their service area. This submission generates a maintenance instruction. Essentially, this instruction is an online notification of service capabilities and time windows, containing the maintenance personnel's ID, skill tag, valid time slot, and geographical range, but not targeting a specific, existing equipment failure. The system aggregates all such valid maintenance instructions into a pending task pool. When a tenant submits a repair instruction for a specific device, the system uses the device's type and location as keys to match maintenance instructions from the pool that possess the corresponding skills, are within the valid time slot, and have a service area covering that location. In this way, the system transforms the traditional passive response process of fault occurrence – finding a technician – into a flexible matching model where technician capabilities are online and faults are matched instantly, thereby shortening matching time and laying the foundation for flexible scheduling and efficient utilization of maintenance human resources. Based on this design, in the scenario where the maintenance instruction in the claim fails to match the repair request instruction, that is, in the reasonable situation where the corresponding maintenance personnel have declared a service period but no corresponding repair task is generated during that period, the system can trigger an optimization strategy for the use of their idle time.

[0105] When the system receives a repair request from a tenant (e.g., a mobile app) via the user interaction module, it first parses and extracts key information from the request: the device's electronic identifier. This identifier is a unique digital identity pre-assigned by the system to each important piece of equipment in the house (e.g., air conditioner, water heater, smart door lock). It can be a code stored in the device's chip, or a QR code or RFID tag affixed to the device's surface. The system then uses this identifier as a search key to perform real-time matching within a pending task pool maintained by the rental period management module. This task pool dynamically aggregates two types of requests: repair requests initiated by the tenant and repair requests actively requested by maintenance personnel (repair end) or dispatched by the system. The matching logic involves finding repair requests associated with the same device electronic identifier as the current repair request. Upon successful matching, the system automatically authorizes the repair personnel's repair end (e.g., a repairman's app) with repair operation permissions for the target device. This permission is a set of digital keys or access tokens that enable maintenance personnel to scan the device's QR code or approach the device via NFC within a specific time frame. This allows them to verify their identity, obtain specific fault information and operation manuals, and unlock the ability to perform debugging and repair operations on the device. To ensure a secure and controllable process, the system will send a confirmation request to the tenant after the repair is completed. The process will only be closed and all operation records archived after the tenant confirms the request.

[0106] Traditional dispatching methods relying on manual communication are lengthy and inefficient. This solution, however, automatically connects supply and demand through identifiers, granting authorization upon successful matching. This eliminates all intermediate steps, reducing task response time from hours to minutes, significantly improving operational efficiency. It establishes an end-to-end, clearly defined, traceable, and secure closed loop. Each maintenance operation is strongly linked to specific personnel, equipment identifiers, and timestamps, creating an immutable digital log that ensures complete accountability. On-site access verification and tenant confirmation effectively prevent accidental operations and unauthorized access, guaranteeing the security and reliability of the process.

[0107] In one implementation, once the maintenance terminal is authorized, if it receives a first authentication signal from the smart device node containing the maintenance personnel's identity information and the device's electronic identifier, it verifies the identity information and electronic identifier. Upon successful verification, it sends an unlock command to the smart device node to allow the maintenance terminal to operate the target device. The maintenance personnel's identity information is uploaded by the maintenance personnel.

[0108] Once the maintenance personnel (the maintenance end) arrives at the physical location of the target device after being authorized by the system, the final activation of their operating permissions requires authentication through a smart device node deployed on-site. This node can be a dedicated controller tightly coupled to the target device (such as an air conditioner smart gateway or a water heater communication module), or it can be a general-purpose IoT gateway or smart panel within the space. The maintenance personnel use their authorized maintenance end APP to trigger the on-site authentication process. The APP will automatically generate and send out the first authentication signal, which is transmitted to the aforementioned smart device node via a network (such as Bluetooth, Wi-Fi, or Zigbee). The first authentication signal is a structured data packet, the core of which contains two encrypted elements: first, the maintenance personnel's identity information, which is usually a combination of their professional qualification ID, system employee number, and real-time biometric features (such as a digital signature generated by calling the phone's camera for liveness detection via the APP); second, the electronic identifier of the target device to be operated, which can be obtained automatically by scanning the device's QR code via the APP or through near-field communication (NFC).

[0109] Upon receiving the initial authentication signal, the smart device node does not process it independently but immediately forwards it to the system's core verification engine (typically located in the lease management module or a separate security authentication service). Upon receiving the signal, the system performs a rigorous two-factor authentication: First, it verifies the identity information. The system checks whether the identity information is valid, whether it matches a person in the previously authorized list, whether their certificate or token is valid, and may also verify the person's qualifications to operate such devices by referring to the backend database. Second, it simultaneously verifies the device's electronic identifier. The system verifies whether the identifier truly exists in the property database and whether its current status is precisely associated with the pending repair request. This two-factor authentication ensures that the designated person accesses the correct device at the correct time.

[0110] Only after both of the above verifications are successfully completed will the system generate an unlock command and send it precisely back to the requesting smart device node. This command contains specific control logic, such as allowing the air conditioner with device identification DEV-AC-1001 to enter engineering debugging mode for 60 minutes. The smart device node parses and executes this command; its actions vary depending on the node type: for a smart gateway, it may mean temporarily opening the device's underlying debugging protocol interface; for a smart socket, it may mean closing the circuit for power supply; for a device cabinet with an electronic lock, it may mean driving the lock to open. Only then can maintenance personnel perform substantive repair operations on the target device, such as program debugging, parameter reading, and component replacement, through the secure channel established between their APP and the device node. The entire authentication and unlocking process is completed automatically within seconds, requiring no manual intervention, but all steps are fully recorded in the system log, forming an undeniable operational audit trail.

[0111] This invention enhances the security of on-site operations and eliminates the risk of unauthorized access. Traditional maintenance management often stops at work order dispatch, allowing personnel to directly access equipment upon arrival, which poses security risks such as misuse of permissions, unauthorized task taking, or accidental entry into other rooms to operate equipment. This solution uses smart device nodes to forcibly bind online granted digital permissions with specific offline physical operation permissions. Maintenance personnel with only mobile authorization cannot directly operate equipment; they must be authenticated through on-site nodes. Unlocking these nodes relies entirely on the backend system's real-time, dual verification of personnel and equipment information. This constitutes a robust physical security barrier, effectively preventing unauthorized operations due to leaked authorization tokens, lost phones, or personnel changes. It is particularly suitable for multi-family, densely populated apartments, ensuring the safety of tenant property and public facilities.

[0112] As one implementation method, upon receiving a maintenance completion signal from a smart device node, a lock command is sent to that node to revoke its operating privileges; a confirmation request containing the maintenance results is sent to the tenant; and upon receiving confirmation information from the tenant, the recording and archiving of this maintenance process is completed.

[0113] This system ensures that every maintenance operation can be safely terminated, the results are verifiable, and the entire process is traceable through standardized maintenance completion confirmation and closed-loop processes, thus forming a data closed loop and the endpoint of responsibility for operation and maintenance management.

[0114] After completing equipment repairs and conducting preliminary testing, maintenance personnel submit a completion report to the system via their maintenance app, triggering a repair completion signal. This signal can be forwarded via on-site smart device nodes (such as the equipment's own smart controller or a nearby IoT gateway) or sent directly from the maintenance app to the system's lease period management module. The signal includes at least the repair task number, maintenance personnel ID, completion timestamp, and a brief result code (e.g., fault resolved, component replacement required). Upon receiving this signal, the system's first step is to immediately send a lock command to the corresponding smart device node. This command essentially revokes the previously granted temporary operating permissions, and its specific action depends on the node type: for smart control nodes, it might switch the equipment from engineering mode back to user mode; for smart power nodes, it might lock the settings interface after confirming stable power supply; for access control nodes, it cancels the temporary access credentials for this maintenance session. This step ensures that the maintenance intervention window is closed promptly and proactively, preventing permissions from being forgotten or maliciously retained, and returning the equipment to a controlled and safe operating state.

[0115] The system automatically generates a structured repair result confirmation request and pushes it to the tenant's end (e.g., the tenant's mobile app) that initiated the repair request. This request typically includes basic repair information (repair time, equipment name, location), a brief description of the repair process (e.g., filter cleaned and refrigerant replenished), key status comparison data before and after the repair (e.g., cooling temperature dropped from 28℃ to 24℃), and photos or short videos of the completed work uploaded by the repair personnel. After reviewing the request, if the tenant is satisfied, they can click the confirmation button or provide an electronic signature on the interface; if they have questions, they can provide feedback online or request a re-verification. The repair task is considered complete only after the system receives formal confirmation from the tenant. Subsequently, the system triggers a recording and archiving process: all data from the entire repair chain, including the initial repair request, matching repair instructions, authorization records, on-site authentication logs, repair completion signals, lock command execution receipts, and the final tenant confirmation certificate, are encapsulated and stored as an immutable and complete record in the building's historical repair archive. This record is permanently linked to the electronic identifier of the target device, forming part of the device's entire lifecycle history.

[0116] This system implements dynamic lifecycle management of permissions, completely eliminating the security gap after maintenance and ensuring the long-term safety of facilities. In traditional maintenance models, maintenance completion often equates to personnel leaving the site, and the system cannot know whether a temporary high-privilege state has been left behind. This solution, through a mandatory response mechanism of completion signal-lock command, ensures that every maintenance intervention has a clear logical and physical termination point. The system proactively revokes permissions, avoiding the risk of equipment being in an insecure configuration state for a long time due to maintenance personnel negligence or missing procedures. This adds crucial safety redundancy to the stable operation of numerous equipment and facilities in the apartment, especially for equipment involving electrical safety, water safety, or data security.

[0117] As one implementation method, if the repair request fails to match the corresponding maintenance request within a preset time, a task alarm is generated and sent to the superior management terminal based on the historical maintenance records of the target device and the current fault level.

[0118] The system starts an independent preset timer for each newly generated repair request. This preset timeout is not a fixed value, but a policy parameter that can be configured by the management terminal. Its setting can take into account factors such as equipment type, location, and time period (e.g., weekday / holiday, daytime / nighttime). For example, the preset timeout for a repair request for an air conditioner not cooling might be 2 hours during the day, but extended to 4 hours at night; for emergency issues such as burst water pipes, the preset timeout might be 30 minutes. During the timer's operation, the system continuously attempts to match the repair request with the pending task pool. If the repair request fails to find a corresponding repair request within the preset time, i.e., the timer expires, the system automatically triggers the exception handling process. At this time, the system first retrieves the historical repair records of the target equipment from the building database module based on the electronic identifier of the equipment carried in the repair request, including but not limited to recent failure frequency, previous repair content, replaced parts, repair time, and repairer information. Simultaneously, the system combines the fault description selected by the tenant during the fault report, such as no cooling at all or severe abnormal noise, with recent abnormal operating data of the device that may be provided by the IoT data acquisition module, such as abnormal current or sensor readings exceeding limits. Through the built-in rule engine or lightweight fault diagnosis model, the system comprehensively assesses the current fault level of the device. The fault level can be simply divided into low (e.g., functional defect), medium (e.g., functional failure), and high (e.g., posing a safety risk or affecting other systems).

[0119] Based on historical maintenance records (especially whether similar faults have occurred frequently recently) and the current fault level, the system automatically generates a structured task alarm. This alarm information is a highly condensed multi-dimensional data packet, including: the timed-out repair order number, equipment identifier and location, fault level assessment result, historical fault summary, and the system's suggested processing priority. The system automatically sends the alarm to the superior management terminal. The superior management terminal can be a centralized property operation management backend or the mobile terminal of the duty manager. The sending channel can be in-app push, SMS, or even robot notifications integrated into third-party office software (such as WeChat Work or DingTalk) to ensure that the information is delivered in a timely manner. The purpose of the alarm is to transform the system's automatic matching failure into a clear task requiring human intervention for decision-making and scheduling, prompting managers to immediately contact backup repairers by phone, conduct cross-regional dispatch, or activate emergency plans.

[0120] In an ideal model of purely automated matching, maintenance resources are always assumed to be sufficient. However, in reality, during peak maintenance periods, nighttime hours, or for specific equipment, situations may arise where no maintenance personnel are temporarily available. Without this mechanism, such repair requests would wait indefinitely within the system, causing tenant requests to go unanswered and severely damaging service experience and trust. This solution proactively identifies such impasses by setting preset time thresholds and converts them into explicit alerts requiring manual follow-up. This ensures that every user request receives a final response from the system, thereby building a comprehensive service assurance network and improving the reliability and resilience of the entire operations and maintenance system in the face of resource fluctuations.

[0121] As one implementation method, if a repair instruction fails to match a corresponding repair request within a preset time, the repair terminal is granted general repair permissions for devices of the same type as those with electronic device identification. The scope, validity period, and operation type of the general repair permissions are predefined by the property management terminal. The system determines whether devices are of the same type based on the device category and model series fields in the device registration information. This classification system is uniformly maintained by the property management terminal when assets are entered into the inventory.

[0122] When a maintenance technician proactively submits their available service time and area of ​​expertise (i.e., issues a maintenance instruction without a specific repair request) through their maintenance terminal, the system initiates a countdown window for that instruction with a preset duration. The length of this window can be dynamically defined by management policies, such as 4 hours during regular hours and 8 hours at night or on holidays, aiming to provide a reasonable standby period for proactive service intentions. If, within this preset time, the maintenance instruction fails to match any repair instruction initiated by any tenant with a specific device, the system determines that there is currently no immediate fault demand and a gap in available personnel time. In this case, the system does not simply invalidate the maintenance instruction but triggers a resource optimization process: based on the skill tags declared by the maintenance technician in the maintenance instruction, such as air conditioning maintenance, electrical work, or historical expertise records, the system automatically identifies and grants the maintenance terminal a general maintenance permission. This permission is not for a single faulty device but for devices similar to the electronic identifier of the device in the instruction. The system determines the category of similar devices based on the device classification tree. For example, if a maintenance command is issued based on the identifier of a Gree air conditioner of a certain model, then similar devices can be defined as all split-type air conditioners of all brands in this building; if it is based on the identifier of a smart circuit breaker, then similar devices may be defined as all circuit breakers of the same specification in this unit.

[0123] The core feature of this universal maintenance permission lies in its clearly defined, predefined, and controlled boundaries. Its scope, validity period, and operation types are all precisely defined in advance by the building management system through a policy configuration interface and stored in the system policy library. The scope defines the physical and logical boundaries of the permission, such as being limited to Unit 2 of Building 1 or to public area equipment only. The validity period specifies the duration of the permission, such as being valid for 24 hours from the date of grant or expiring at 18:00 on the same day. The operation types strictly limit the permitted actions, such as only allowing inspection operations like reading operation logs, cleaning filters, and tightening screws; modifying core parameters or replacing the motherboard is prohibited. When the system grants this permission, it issues the above policy terms to the maintenance app in the form of a digital license and synchronizes them to the smart device nodes in the relevant area. After obtaining this permission, maintenance personnel can perform permitted operations on similar equipment within the defined scope during its validity period. For example, if an air conditioning repairman obtains general access when there are no immediate work orders in the morning, they can proactively go to the outdoor units in each room of their assigned floor to perform preventative maintenance such as filter cleaning and noise checks, and record the maintenance details in the app. All operations performed under general access are linked to the repairman's identity, equipment identification, operation time, and type, and are recorded for management review. General access policy, for example: Access scope: All split-type air conditioners in Building 1; Validity period: 4 hours after grant; Operation type: Limited to reading operation logs and cleaning filters.

[0124] Improving the utilization efficiency of maintenance human resources and time windows transforms non-productive standby time into value-added maintenance activities. In the traditional model, maintenance personnel are often passively waiting when no immediate work orders are available, resulting in wasted human resources. This solution, by granting controlled general permissions, encourages and guides maintenance personnel to proactively conduct planned inspections, maintenance, and minor repairs during idle periods. This not only fills work gaps and improves personnel time utilization, but more importantly, these proactive maintenance measures effectively identify potential problems such as severely clogged filters, loose screws, and minor leaks, preventing them from escalating into subsequent emergency repairs. This reduces the overall number and urgency of unexpected work orders, achieving proactive and optimized maintenance investment and ultimately reducing costs and increasing efficiency.

[0125] This invention discloses an IoT-based smart IoT management and control system, comprising a user interaction module, a housing database module, a demand matching module, a smart contract module, an IoT data acquisition module, and a rental period management module. Each module has pre-defined dedicated interfaces, such as the DemandParamUpload interface, the IotDataSync interface, and the TargetHouseInfoSync interface, which are connected via the HTTPS transmission protocol. The system includes: a user interaction module for receiving tenant rental requests, repair requests, payment instructions, and maintenance instructions from the maintenance terminal; and pushing housing listings, contracts, warnings, reminders, and usage reports; and a housing database module. The system includes: a housing basic information module, a housing parameter threshold module, electronic identification, and historical maintenance records, with the housing parameter thresholds being consistent; a demand matching module, which analyzes rental demands to build a demand data chain, calculates its matching degree with housing parameter thresholds, filters target houses, and generates rental information; a smart contract module, which converts rental information into contracts, integrates user identity information, and generates target rental contracts by encrypting the identity and contract content in different areas; an IoT data acquisition module, which collects housing water and electricity data and equipment operating status, and integrates the data into the target rental contract; and a rental period management module, which processes equipment repair requests, monitors IoT data and issues warnings, reminds tenants to renew or terminate the lease before its expiration, and generates monthly usage reports.

[0126] This system interacts with tenants, maintenance personnel, and property management through standardized interfaces. The property management terminal refers to the operating terminal or backend interface used by property management entities such as property operators and asset holders. At the system architecture level, its functions are implemented through a dedicated administrator interface provided by the user interaction module, used to receive policy configurations from management, such as permission definitions, threshold settings, alarm handling, information review, and report viewing. Simultaneously, the lease term management module is responsible for executing these policies and interacting with them. Tenants submit rental requests, repair instructions, and payment requests through the graphical interface or API provided by the user interaction module. The data format uses JSON and includes user identification, request type, and parameter content. The maintenance terminal receives repair tasks and uploads repair progress through a dedicated interface. The data includes maintenance personnel identification tokens, device electronic identifiers, and operational status. The property management terminal reviews property information, handles emergency alarms, and views various statistical reports through a management interface. Data interaction also follows the JSON format specification. Data access for IoT devices is implemented based on a lightweight communication protocol. For real-time monitoring of water and electricity meter readings and equipment status, the equipment uses the MQTT protocol to publish data to the IoT data acquisition module, with the data subject bound to the equipment's electronic identifier. For configuration queries and command issuance scenarios, the system can use the HTTP protocol for bidirectional communication with the equipment. All transmitted data is encrypted to ensure the integrity and confidentiality of information during transmission.

[0127] The ideal deployment environment for this system is in newly built or pre-installed centralized apartments with large-scale IoT infrastructure. In such scenarios, it can directly connect to existing smart device networks, and the implementation cost is mainly concentrated in software platform deployment and system integration. For the numerous traditional housing renovation scenarios, the renovation cost and engineering complexity need to be objectively assessed. Renovation involves adding smart control nodes to key equipment in each unit (such as door locks, water and electricity meters, and air conditioners) and deploying a unified IoT communication gateway, which will generate significant hardware procurement, installation, commissioning, and potential wiring upgrade costs. It is recommended that implementers adopt a phased and regional renovation strategy, prioritizing deployment on public equipment and high-value assets. At the same time, the learning cost for users needs to be considered. The system should provide tenants and maintenance personnel with a simple and clear operating interface and guided process, and be equipped with video tutorials and online customer service support to reduce the barrier to entry and ensure a smooth transition and efficient execution of the new process.

[0128] It should be understood that those skilled in the art can make improvements or modifications based on the above description, and all such improvements and modifications should fall within the protection scope of the appended claims.

Claims

1. A smart IoT management and control system for centralized housing, characterized in that, include: When the rental demand parameters input by the user are received in real time, the corresponding target house is matched in the preset housing database according to the rental demand parameters and housing rental information is generated. The system converts housing rental information into a pre-defined smart contract system, and then integrates user identity information with the housing rental contract to generate a target rental contract. Real-time acquisition of water and electricity data and equipment operation status data of the target house collected by the house IoT device and integration into the target rental contract to complete the house rental; During the lease term, the system handles equipment repair and maintenance requests, monitors IoT data in real time and issues early warnings for anomalies, and reminds tenants to renew or terminate the lease before its expiration.

2. The intelligent IoT management and control system for centralized housing according to claim 1, characterized in that: The steps to match target properties based on rental needs parameters include: Analyze rental demand parameters and construct a demand data chain; The system detects several coherent house parameter thresholds in a pre-defined house database, calculates the matching degree between the demand data chain and each house parameter threshold, and matches the target house based on the matching degree.

3. The intelligent IoT management and control system for centralized housing according to claim 2, characterized in that: Target houses matched based on matching degree include: Real-time determination of whether the matching degree is greater than the preset matching degree threshold; If it is determined in real time that the matching degree is greater than the preset matching degree threshold, the target house parameter threshold corresponding to the preset matching degree threshold is detected, and the corresponding target data chain is generated based on the target house parameter threshold. The target house is matched against the preset house database based on the size of the target data chain.

4. The intelligent IoT management and control system for centralized housing according to claim 1, characterized in that: The steps to generate a target lease agreement include: Create a blank contract template, map user identity information and housing rental contract into the template, generate corresponding identity and contract fields and set the dividing line.

5. A smart IoT management and control system for centralized housing according to claim 1, characterized in that: The steps for processing equipment repair requests include: When a repair request for a target device is received from a tenant, the device's electronic identifier associated with the repair request is obtained. Based on the device's electronic identifier, match maintenance instructions sent by the maintenance terminal that are associated with the same device's electronic identifier in the task pool to be processed; When the repair request and maintenance command are successfully matched, the corresponding maintenance terminal is authorized to perform maintenance operations on the target device.

6. A smart IoT management and control system for centralized housing according to claim 5, characterized in that: Once the maintenance terminal is authorized, if it receives a first authentication signal from the smart device node containing the maintenance personnel's identity information and the device's electronic identifier, it will verify the identity information and electronic identifier. After successful verification, an unlock command is sent to the smart device node to allow the maintenance terminal to operate the target device.

7. A smart IoT management and control system for centralized housing according to claim 6, characterized in that: Upon receiving the maintenance completion signal from the smart device node, a lock command is sent to the node to revoke the operating permission; Send a confirmation request containing the repair results to the tenant's end; Once confirmation is received from the tenant, the maintenance process is recorded and archived.

8. A smart IoT management and control system for centralized housing according to claim 1, characterized in that: If the repair request fails to match the corresponding maintenance request within the preset time, a task alarm will be generated and sent to the superior management terminal based on the historical maintenance records and current fault level of the target device.

9. A smart IoT management and control system for centralized housing according to claim 1, characterized in that: If the repair instruction fails to match the corresponding repair request within a preset time, the repair terminal is granted general repair permissions for devices of the same type as the electronic identification device. The scope, validity period, and operation type of the general repair permissions are predefined by the building management terminal.

10. The intelligent IoT management and control system for centralized housing according to claim 1, characterized in that: It includes a user interaction module, a housing database module, a demand matching module, a smart contract module, an IoT data collection module, and a lease term management module. The user interaction module is used to receive tenants' rental needs, repair requests and payment instructions, repair instructions from the repair terminal, and push housing results, contracts, warnings, reminders and usage reports. The housing database module stores basic housing information, housing parameter thresholds, electronic identification, and historical maintenance records. The housing parameter thresholds are consistent. The demand matching module parses rental demands, constructs a demand data chain, calculates its matching degree with housing parameter thresholds, filters target houses, and generates rental information. The smart contract module converts rental information into contracts, integrates user identity information, and generates the target rental contract by encrypting the identity and contract content in different areas. The IoT data acquisition module collects data on the building's water and electricity supply and equipment operating status, and integrates the data into the target rental contract; The lease term management module handles equipment repair requests, monitors IoT data and issues alerts, reminds users to renew or terminate the lease before its expiration, and generates monthly usage reports.

Images