High formwork remote intelligent monitoring and early warning system

Abstract

The application relates to the technical field of construction engineering construction safety monitoring, in particular to a high-formwork remote intelligent monitoring and early warning system, which comprises a monitoring host, a weight sensor, an offset sensor, a settlement sensor, an inclination sensor, an audible and visual alarm, a cloud server and a mobile terminal. The monitoring host generates an equipment identity graphic code for the mobile terminal to bind, the cloud server issues configuration instructions or collection instructions according to the binding result and heartbeat time, the monitoring host writes in a threshold value and reads back for verification, and the current value of the sensor is compared with the early warning threshold value and the alarm threshold value to generate a state record. Through equipment identity verification, configuration effective rewriting, on-demand collection, hierarchical audible and visual alarm and remote pushing, manual input errors and configuration waiting are reduced, the device state, parameter state and alarm state are continuously updated in the same business link, and a continuous link of inspection and verification, danger notification and alarm tracing is formed.

Description

Technical Field

[0001] This invention relates to the field of construction safety monitoring technology, and in particular to a remote intelligent monitoring and early warning system for high-formwork structures. Background Technology

[0002] The field of construction safety monitoring technology encompasses the technical scope of collecting status data, transmitting signals, comparing thresholds, and providing alarms for high-risk support structures, temporary components, load-bearing areas, and deformation-sensitive parts at construction sites. It typically relies on sensors, on-site data acquisition equipment, communication devices, display terminals, and remote platforms to continuously record physical quantities such as load-bearing capacity, displacement, settlement, tilt angle, and temperature generated during construction. Traditional high-formwork monitoring systems involve deploying weight sensors, displacement sensors, settlement sensors, and tilt angle sensors on the formwork support system. Each sensor is connected to a field data acquisition device via a bus or power interface. The data acquisition device reads the sensor values ​​at fixed sampling intervals, converts analog quantities to digital quantities, stores them in local storage, and then uploads data packets to a cloud platform via a mobile communication network. The platform displays real-time curves, alarm lists, device online status, and historical records on a webpage. Threshold parameters are usually set by on-site button displays or entered in the backend and read during periodic device communication. Device access is typically handled manually by management personnel, who register the device number, project name, and device information.

[0003] Traditional high-support formwork monitoring relies on setting thresholds via on-site buttons. Cloud-based parameter changes require waiting for periodic equipment reports to take effect. Mobile terminals cannot directly view the current working conditions. Equipment access depends on manual input of numbers and project information. Remote platforms can only passively receive data at fixed intervals. Inspections lack real-time verification basis. On-site sensor status and threshold configurations lack simultaneous comparison on the same screen. Alarm records are scattered across the host and platform sides. Cross-project searches require entering each equipment page one by one. Abnormal information arrives at on-site personnel and supervisors with delays, making it difficult to simultaneously form a basis for safety handling. Summary of the Invention

[0004] To address the aforementioned technical problems, this invention provides a remote intelligent monitoring and early warning system for high-support formwork, comprising a monitoring host, weight sensors, offset sensors, settlement sensors, tilt sensors, an audible and visual alarm, a cloud server, and a mobile terminal. The monitoring host is communicatively connected to the weight sensors, offset sensors, settlement sensors, and tilt sensors, and electrically connected to the audible and visual alarm. The monitoring host is connected to the cloud server via a wireless communication link, and the mobile terminal is connected to the cloud server via a network. The monitoring host outputs a device identification graphic code. The mobile terminal collects the device identification graphic code and sends a binding request and a threshold configuration request to the cloud server. The cloud server generates configuration instructions or acquisition instructions based on the device binding status and the device online status. The monitoring host writes and reads back the early warning threshold and alarm threshold according to the configuration instructions, reads the current sensor values ​​according to the acquisition instructions, compares the current sensor values ​​with the early warning threshold and alarm threshold, and then drives the audible and visual alarm and uploads the alarm record.

[0005] As a progressive solution, the monitoring host includes a main control circuit, a display screen, a local memory, a button circuit, a wireless communication circuit, and an alarm drive circuit. The main control circuit is electrically connected to the display screen, local memory, button circuit, wireless communication circuit, and alarm drive circuit. The display screen shows the device identification graphic code and the device's operating status. The local memory stores warning thresholds, alarm thresholds, and alarm records. The alarm drive circuit drives the audible and visual alarms based on the status signals output by the main control circuit. The main control circuit sends read commands sequentially to the weight sensor, offset sensor, settlement sensor, and tilt sensor via the bus interface. The weight sensor returns the current weight value, the offset sensor returns the current offset value, the settlement sensor returns the current settlement value, and the tilt sensor returns the current tilt angle value. The main control circuit writes the current weight, offset, settlement, and tilt angle values ​​obtained in the same round of readings into the memory cache, and uses this memory cache as the data source for threshold comparison and record uploading.

[0006] As a progressive solution, the device identification graphic code is generated by the monitoring host based on the device number and device name. After the mobile terminal collects the device identification graphic code, it sends a binding request composed of the user account, device number, and binding action identifier to the cloud server. The cloud server queries the device registration record and binding relationship record based on the device number. If the device registration record exists and the binding relationship record does not record an occupancy relationship, it writes the binding relationship between the user account and the device number and returns the binding result to the mobile terminal. The threshold configuration request includes weight warning threshold, weight alarm threshold, offset warning threshold, offset alarm threshold, settlement warning threshold, settlement alarm threshold, tilt angle warning threshold, tilt angle alarm threshold, and operation time. The mobile terminal compares the alarm threshold and warning threshold within the same monitoring type. If the alarm threshold is greater than the warning threshold, it sends a threshold configuration request. The cloud server verifies the configuration permission based on the binding result and determines the device's online status based on the most recent heartbeat time. If the device is online, it generates a configuration command; if it is offline, it marks the device as waiting for delivery.

[0007] As a progressive scheme, the configuration command includes a frame header, device number, command type, configuration data body, and checksum. After receiving the configuration command, the monitoring host verifies the frame header, device number, command type, and checksum. If verification is successful, the monitoring host writes the configuration data body to the local configuration storage area. The monitoring host reads back the written threshold from the local configuration storage area and compares the read-back threshold with the sent threshold in the configuration data body item by item. If they match, a configuration activation message is generated; if they do not match, a configuration failure message is generated, and the activation or failure message is returned to the cloud server. This ensures that threshold configuration is effective not based on the completion of transmission, but on the consistency between the host's write and read-back operations.

[0008] As a progressive solution, the mobile terminal sends a real-time data retrieval request to the cloud server. This request includes the target device ID, request type, and request time. The cloud server queries the device's online status cache based on the target device ID. If the cached online status is offline, it returns an offline notification to the mobile terminal. If the cached online status is online, it generates a data acquisition command and sends it to the monitoring host. The monitoring host reads the current sensor values ​​based on the acquisition command and uploads the current sensor values, acquisition time, and target device ID to the cloud server. The cloud server then forwards this data to the mobile terminal, enabling inspection personnel to obtain current operating data during parameter configuration and on-site inspections.

[0009] As a progressive scheme, the monitoring host compares the current value of the same monitoring type with the corresponding early warning threshold and alarm threshold. When any current value reaches or exceeds the corresponding alarm threshold, the monitoring host outputs an alarm status. When any current value reaches or exceeds the corresponding warning threshold and falls below the corresponding alarm threshold, and all current values ​​are below the corresponding alarm threshold, the monitoring host outputs a warning status. When all current values ​​are below the corresponding warning threshold, the monitoring host outputs a normal status. When the monitoring host outputs a normal status, the audible and visual alarms remain in a non-alarm response state. When an early warning status is output, the audible and visual alarm is driven to emit warning lights and intermittent buzzers, and the warning record consisting of the trigger monitoring type, current value, warning level and trigger time is uploaded to the cloud server. When an alarm is output, the audible and visual alarm is activated to emit alarm lights and a continuous buzzer, and the alarm record consisting of the trigger monitoring type, current value, alarm level, and trigger time is uploaded to the cloud server.

[0010] As a progressive solution, after receiving alarm or warning records, the cloud server establishes a bidirectional index based on the device number and trigger time, and maintains the alarm list in reverse chronological order of trigger time. The cloud server determines the remote notification path based on the alarm level. When the alarm level is a warning level, a warning notification is sent to the bound user's mobile terminal; when the alarm level is an alarm level, an alarm notification is sent to the bound user's mobile terminal, triggering an SMS notification. The mobile terminal sends query conditions to the cloud server based on the project name, device name, or device number. The cloud server returns the corresponding alarm list and alarm details based on the bidirectional index and query conditions, enabling alarm records to be continuously queried across device, time, and project dimensions.

[0011] Compared with the prior art, the advantages and positive effects of the present invention are as follows: In this invention, by collecting and verifying the device identity graphic code and binding status, the device access is transformed from manual input to on-site identity reading. Through online status verification and threshold write-back confirmation, the configuration distribution results become verifiable and effective. By initiating a collection command through a mobile terminal and having the monitoring host instantly read the current sensor values, the inspection team obtains the current operating conditions. By comparing early warning thresholds and alarm thresholds in a graded manner and linking local audible and visual alarms with remote notifications, dangerous states are transmitted according to their levels. By establishing an alarm index by device and trigger time, multi-item alarm queries and handling traceability form a continuous data link and maintain consistent record sources. Attached Figure Description

[0012] Figure 1 This is a schematic diagram of the overall architecture of a remote intelligent monitoring and early warning system for high-support formwork. Figure 2 A diagram illustrating the write-back process for device identity binding and threshold configuration to take effect; Figure 3 This is a diagram illustrating the real-time data retrieval and sensor reading flow. Figure 4 A schematic diagram of graded status determination and on-site audible and visual alarms; Figure 5 This is a diagram illustrating the alarm record index and remote notification. Detailed Implementation

[0013] To make the technical objectives, technical composition, and implementation process of the technical solution described in this invention clearer, the following description is provided in conjunction with embodiments and accompanying drawings. In the following embodiments, the monitoring host refers to the field equipment deployed at the high-formwork construction site, responsible for sensor reading, threshold storage, status determination, alarm activation, and wireless communication; the cloud server refers to the server that receives data uploaded by the monitoring host and issues configuration and acquisition instructions to the monitoring host, as well as returning display data to the mobile terminal; the mobile terminal refers to the terminal device held by on-site management or supervisory personnel and used for barcode binding, threshold configuration, real-time data retrieval, alarm querying, and notification reception. In the following embodiments, the current weight value, current offset value, current settlement value, and current tilt angle value are returned by the weight sensor, offset sensor, settlement sensor, and tilt sensor respectively during the same round of reading. Warning thresholds and alarm thresholds are stored separately according to monitoring type, and alarm thresholds are used for determining dangerous states of a higher level than the warning threshold.

[0014] Please see Figure 1 This embodiment provides a remote intelligent monitoring and early warning system for high-formwork structures. The system is applied to high-formwork support systems before, during, and after concrete pouring in building construction projects. On-site, a monitoring host, weight sensors, offset sensors, settlement sensors, tilt sensors, and an audible and visual alarm are installed. Remotely, a cloud server and a mobile terminal are installed. The weight sensors detect the load-bearing status of the high-formwork support system; the offset sensors detect lateral offset; the settlement sensors detect vertical settlement; and the tilt sensors detect tilt angle. The monitoring host is communicatively connected to the weight sensors, offset sensors, settlement sensors, and tilt sensors, and electrically connected to the audible and visual alarm. The monitoring host communicates with the cloud server via a wireless communication link, and the mobile terminal communicates with the cloud server via a network. Thus, the on-site sensors form the monitoring input end, the monitoring host forms the on-site data acquisition and judgment end, the cloud server forms the configuration, forwarding, indexing, and push end, and the mobile terminal forms the identity binding, parameter operation, real-time viewing, and alarm query end.

[0015] The monitoring host includes a main control circuit, a display screen, a local memory, a button circuit, a wireless communication circuit, and an alarm drive circuit. The main control circuit is electrically connected to the display screen, local memory, button circuit, wireless communication circuit, and alarm drive circuit. The alarm drive circuit is electrically connected to the audible and visual alarm. The main control circuit sends read commands to the weight sensor, offset sensor, settlement sensor, and tilt sensor via a bus interface and receives digital detection values ​​returned by each sensor. The display screen shows the device identification graphic code, device operating status, current monitoring value, and alarm status. The local memory stores the device number, device name, configuration version, warning threshold, alarm threshold, and alarm records. The button circuit receives local switching operations from on-site personnel. The wireless communication circuit receives configuration and acquisition commands from the cloud server and uploads heartbeat data, current sensor values, configuration activation information, configuration failure information, warning records, and alarm records to the cloud server. The alarm drive circuit drives the audible and visual alarm based on the status signal output by the main control circuit, causing the alarm to output different light and buzzer responses in the warning and alarm states.

[0016] Please see Figure 2 After the monitoring host is powered on, the main control circuit reads the device number, device name, and configuration version pre-stored in the local memory, and generates a device identification graphic code based on the device number and device name, outputting the graphic code to the display screen. The mobile terminal collects this graphic code, obtains the device number and device name, and sends a binding request composed of the user account, device number, and binding action identifier to the cloud server. Upon receiving the binding request, the cloud server queries the device registration record using the device number as the search condition, and checks if a binding relationship already exists between the device number and another user account. If the device registration record exists and the binding relationship record does not record a binding relationship, the cloud server writes the binding relationship between the user account and the device number and returns a successful binding status to the mobile terminal. If the device registration record does not exist or the binding relationship record already records a binding relationship, the cloud server returns a failed binding status to the mobile terminal, and the mobile terminal displays a message on the device page indicating that threshold configuration and real-time fetching operations cannot continue.

[0017] The successful binding status serves as the input basis for subsequent threshold configuration and real-time data collection permissions. After the mobile terminal enters the configuration page of the bound device, it reads the user-inputted weight warning threshold, weight alarm threshold, offset warning threshold, offset alarm threshold, settlement warning threshold, settlement alarm threshold, tilt angle warning threshold, and tilt angle alarm threshold. The mobile terminal compares the alarm threshold with the warning threshold within the same monitoring type. The weight alarm threshold should be greater than the weight warning threshold, the offset alarm threshold should be greater than the offset warning threshold, the settlement alarm threshold should be greater than the settlement warning threshold, and the tilt angle alarm threshold should be greater than the tilt angle warning threshold. If any monitoring type does not meet the above relationship, the mobile terminal stops sending threshold configuration requests and displays a parameter relationship error status in the input area of ​​the corresponding monitoring type on the configuration page. When all monitoring types meet the above relationship, the mobile terminal sends a threshold configuration request consisting of the device number, the eight thresholds, and the operation time to the cloud server.

[0018] After receiving a threshold configuration request, the cloud server first verifies that the user account sending the request has configuration permissions for the target device based on the binding relationship. Then, it determines the device's online status based on the target device's most recent heartbeat time. The device's online status is formed by the cloud server receiving heartbeat data periodically sent by the monitoring host. The heartbeat data carries at least the device ID and heartbeat time. If the difference between the current server time and the most recent heartbeat time does not exceed the online judgment duration, the cloud server determines the device's online status as online; if the difference exceeds the online judgment duration, the cloud server determines the device's online status as offline. When the device is online, the cloud server encapsulates the device ID, instruction type, eight thresholds, and verification information into a configuration instruction. When the device is offline, the cloud server marks the configuration record corresponding to the threshold configuration request as awaiting distribution and returns the awaiting distribution status to the mobile terminal, preventing the mobile terminal's configuration page from displaying the parameters as already effective.

[0019] Please see Figure 2 and Figure 3The configuration command includes a frame header, device number, command type, configuration data body, and checksum. The configuration data body carries the weight warning threshold, weight alarm threshold, offset warning threshold, offset alarm threshold, settlement warning threshold, settlement alarm threshold, tilt angle warning threshold, and tilt angle alarm threshold in a fixed order. The cloud server sends the configuration command to the monitoring host via a wireless communication link. After receiving the configuration command, the wireless communication circuit transmits it to the main control circuit. The main control circuit first verifies whether the frame header conforms to the configuration command format, then verifies whether the device number in the configuration command matches the device number stored in the local memory, then verifies whether the command type is a configuration distribution type, and checks whether any errors occurred during the transmission of the configuration command based on the checksum. When all the above verifications pass, the main control circuit parses the eight thresholds sequentially from the configuration data body and writes the eight parsed thresholds into the local configuration storage area.

[0020] After the main control circuit completes the write operation, it does not immediately consider the configuration to be effective. Instead, it reads back the eight thresholds written from the same storage address in the local configuration storage area and compares these read-back thresholds with the issued thresholds in the configuration data body item by item. When all eight read-back thresholds match the corresponding issued thresholds, the main control circuit generates configuration effectiveness information, which includes the device number, configuration version, and confirmation time. Simultaneously, the main control circuit updates the local configuration version, ensuring that subsequent sampling and judgments are based on the newly written thresholds. If any verification of the configuration command's frame header, device number, command type, or checksum fails, the main control circuit does not execute the configuration data body write and threshold read-back actions. Instead, it generates configuration failure information, marked as command verification failure, which includes the device number, failure type, and confirmation time. After the configuration command verification passes and the configuration data body has been written to the local configuration storage area, if any read-back threshold is inconsistent with the corresponding issued threshold, the main control circuit generates configuration failure information, marked as read-back verification failure, which includes the device number, failure type, and confirmation time. The wireless communication circuit sends configuration activation or failure information to the cloud server. The cloud server updates the configuration record status based on this information and sends the updated configuration status to the mobile terminal. The mobile terminal displays "successful," "failed," or "waiting for configuration" on the configuration page according to the configuration status, thus forming a closed loop in the threshold configuration process: mobile terminal submission, cloud online judgment, host writing, host readback, cloud update, and mobile terminal display.

[0021] Please see Figure 3During inspections or pre-configuration checks, mobile terminals can send real-time data retrieval requests to the cloud server. These requests include the target device ID, request type, and request time. Upon receiving the request, the cloud server queries the device's online status cache based on the target device ID. If the device's online status cache shows it as offline, the cloud server returns an offline notification to the mobile terminal, which then displays the device's offline status on the sensor data page and stops waiting for the current sensor value. If the device's online status cache shows it as online, the cloud server generates a data acquisition command based on the target device ID and request type, and sends it to the monitoring host via the wireless communication link.

[0022] After receiving the acquisition command, the monitoring host verifies the frame header, device number, command type, and checksum of the acquisition command via the main control circuit. Upon successful verification, the main control circuit sends read commands to the weight sensor and receives the current weight value via the bus interface in a fixed sequence; sends read commands to the offset sensor and receives the current offset value; sends read commands to the settlement sensor and receives the current settlement value; and sends read commands to the tilt sensor and receives the current tilt angle value. The current values ​​from all four types of sensors originate from the same acquisition cycle. The main control circuit writes the current weight, offset, settlement, and tilt angle values, along with the acquisition time, into a memory cache. The wireless communication circuit then uploads the device number, acquisition time, and the current values ​​of the four types of sensors to the cloud server. Upon receiving the data, the cloud server forwards it to the mobile terminal. The mobile terminal displays the current weight, offset, settlement, tilt angle, and acquisition time on the sensor data page. The acquisition time indicates the moment when the current values ​​of the four types of sensors displayed on the mobile terminal were generated, allowing on-site personnel to compare the current operating conditions with the warning and alarm thresholds in the configuration page.

[0023] The monitoring host also performs periodic data acquisition according to the sampling cycle. Both periodic acquisition and real-time data retrieval trigger the acquisition by obtaining the current values ​​of the four types of sensors through the same sensor reading path. The difference lies in that periodic acquisition is triggered by the main control circuit according to the sampling cycle, while real-time data retrieval is triggered by the cloud server issuing acquisition commands. For periodic acquisition, after completing the same round of sensor readings, the main control circuit writes the current values ​​of weight, offset, settlement, and tilt angle to the memory cache, and reads the weight warning threshold, weight alarm threshold, offset warning threshold, offset alarm threshold, settlement warning threshold, settlement alarm threshold, tilt angle warning threshold, and tilt angle alarm threshold from the local configuration storage area. Since the current values ​​of each monitoring type and their corresponding thresholds have the same physical meaning and unit, the main control circuit only performs size comparisons within the same monitoring type, and does not directly add, subtract, or merge data from different monitoring types.

[0024] Please see Figure 4When the main control circuit performs graded state determination, it first compares the current values ​​of the four types of sensors with alarm thresholds. If any of the following conditions are met: the current weight value reaches or exceeds the weight alarm threshold, the current offset value reaches or exceeds the offset alarm threshold, the current settlement value reaches or exceeds the settlement alarm threshold, or the current tilt angle value reaches or exceeds the tilt angle alarm threshold, the main control circuit outputs the overall system status as alarm state. If none of the current values ​​of the four types of sensors reach their respective alarm thresholds, the main control circuit continues to compare the current values ​​of the four types of sensors with warning thresholds. If any of the following conditions are met: the current weight value reaches or exceeds the weight warning threshold but is lower than the weight alarm threshold, the current offset value reaches or exceeds the offset warning threshold but is lower than the offset alarm threshold, the current settlement value reaches or exceeds the settlement warning threshold but is lower than the settlement alarm threshold, or the current tilt angle value reaches or exceeds the tilt angle warning threshold but is lower than the tilt angle alarm threshold, the main control circuit outputs the overall system status as warning state. If all four types of sensor current values ​​are lower than their respective warning thresholds, the main control circuit outputs the overall system status as normal state.

[0025] Normal, warning, and alarm states correspond to different on-site response and remote data processing paths. When the main control circuit outputs a normal state, the alarm drive circuit does not output an alarm drive signal to the audible and visual alarm, and the display shows the current values ​​and normal status of the four types of sensors. When the main control circuit outputs a warning state, it identifies the monitoring type that triggered the warning and outputs a warning drive signal to the alarm drive circuit, causing the audible and visual alarm to output a warning light and intermittent buzzer. Simultaneously, the main control circuit generates a warning record based on the device number, trigger time, current values ​​of the four types of sensors, triggered monitoring type, and warning level, and uploads it to the cloud server via a wireless communication circuit. When the main control circuit outputs an alarm state, it identifies the monitoring type that triggered the alarm and outputs an alarm drive signal to the alarm drive circuit, causing the audible and visual alarm to output an alarm light and continuous buzzer. Simultaneously, the main control circuit generates an alarm record based on the device number, trigger time, current values ​​of the four types of sensors, triggered monitoring type, and alarm level, and uploads it to the cloud server via a wireless communication circuit. Therefore, monitoring types that reach the alarm threshold are given priority to enter the alarm path, monitoring types that do not reach the alarm threshold but reach the warning threshold are entered into the warning path, and monitoring types that do not reach the warning threshold are not triggered into the alarm path.

[0026] Both warning and alarm records have a record structure that can be parsed by the cloud server. The device number in the record structure identifies the monitoring host to which the record belongs, the trigger time determines the moment the record was created, the current values ​​of the four types of sensors are used to reproduce the high formwork state at the time of triggering, the trigger monitoring type indicates which monitoring type (weight, offset, settlement, or tilt) triggered the change in state, and the alarm level distinguishes between warning and alarm levels. After receiving a warning or alarm record, the cloud server first verifies whether the device number in the record belongs to a registered device before writing the record to the alarm data table. During writing, the cloud server creates indexes for both the device number and the trigger time, and maintains the alarm list in reverse chronological order. The device number index is used for searching by device, the trigger time index is used for searching by time range, and the reverse chronological order alarm list is used to retrieve the most recently created records when a mobile terminal accesses the alarm page.

[0027] Please see Figure 5 The cloud server determines the remote notification path based on the alarm level in the warning or alarm records. When the alarm level is warning, the cloud server queries the user account bound to the device number and sends a warning notification to the bound user's mobile terminal. The warning notification includes at least the device name, triggered monitoring type, current value, corresponding warning threshold, and trigger time. When the alarm level is alarm, the cloud server sends an alarm notification to the bound user's mobile terminal and triggers an SMS notification path. Both the alarm notification and the SMS notification include at least the device name, triggered monitoring type, current value, corresponding alarm threshold, and trigger time. By using different notification paths for warning and alarm levels, the cloud server ensures that low-level and high-level risks are addressed through different remote arrival methods. Both on-site audible and visual responses and remote notification responses are triggered by the same record, avoiding inconsistencies between on-site conditions and remote records.

[0028] The mobile terminal provides alarm list query and alarm details viewing. When a user enters a project name, device name, or device number as query criteria on the mobile terminal, the mobile terminal sends the query criteria and user account to the cloud server. The cloud server first determines the set of allowed device numbers based on the user account, then matches the query criteria with the project name, device name, or device number. The matched device number is used as the retrieval object in the alarm data table. The cloud server uses the device number index and trigger time index to retrieve the alarm data table and returns the alarm list to the mobile terminal in reverse chronological order of trigger time. The mobile terminal displays the device name, trigger monitoring type, trigger time, and alarm level in the alarm list. After the user selects a record in the alarm list, the mobile terminal sends an alarm details request to the cloud server. The cloud server reads the device number, trigger time, current values ​​of the four types of sensors, trigger monitoring type, alarm level, and corresponding threshold of the record based on the record identifier, and returns the alarm details to the mobile terminal. The mobile terminal thus displays the current values ​​of the four types of sensors and the corresponding thresholds at the time of triggering on the same page, enabling inspection personnel to verify the cause of the alarm.

[0029] In cases of abnormal configuration status, the cloud server and monitoring host handle the situation according to a defined state. After the cloud server issues a configuration command, if it receives configuration activation information within the configuration waiting period, it updates the corresponding configuration record to an activated state and sends the configuration version and confirmation time to the mobile terminal. If it receives configuration failure information within the configuration waiting period, it updates the corresponding configuration record to a failed issuance state and sends the failure type to the mobile terminal. If it does not receive any information from the monitoring host within the configuration waiting period, it updates the corresponding configuration record to a device unresponsive state and returns a device unresponsive prompt to the mobile terminal. Upon receiving a failed issuance state or a device unresponsive state, the mobile terminal does not change the historically effective configuration values ​​on the page; it only displays the newly submitted configuration as inactive and provides a re-issuance entry. During re-issuance, the mobile terminal resends the same set of thresholds and a new operation time. The cloud server re-executes binding relationship verification, online status judgment, and configuration command generation to ensure that the inactive configuration is not mistakenly considered to have entered the monitoring host's local configuration storage area.

[0030] In the event of a real-time data retrieval anomaly, the cloud server and mobile terminal handle the situation according to the device's online status and data acquisition response status. If the device's online status cache is offline, the cloud server does not generate a data acquisition command but directly returns an offline notification to the mobile terminal. If the device's online status cache is online but the monitoring host does not return the sensor's current value within the data acquisition waiting time, the cloud server returns a data acquisition timeout notification to the mobile terminal. If the monitoring host returns acquired data but the verification information does not match, the cloud server does not write the acquired data into the real-time display results but returns a data verification failure notification. After receiving an offline notification, a data acquisition timeout notification, or a data verification failure notification, the mobile terminal retains the last valid data acquisition time on the sensor data page and indicates that no new valid current value was generated in this real-time retrieval. By distinguishing between the three states of offline, timeout, and verification failure, the mobile terminal can display different states indicating the reasons for not being able to obtain the current value, avoiding the use of invalid data for threshold verification.

[0031] The monitoring host's local memory is also used to store alarm records. After generating a warning or alarm record, the main control circuit, in addition to uploading it to the cloud server via wireless communication, also writes the same record to the alarm record storage area in the local memory. The alarm record storage area saves records in chronological order. When the storage area reaches its capacity limit, the main control circuit overwrites the earliest triggered record with a new one. When on-site personnel trigger the historical record to view it via the button circuit, the main control circuit reads the alarm record from the local memory and outputs it to the display screen in reverse chronological order of trigger time. This local record path does not replace the alarm index path on the cloud server, but serves as the on-site viewing path, allowing the monitoring host to still display the already generated local records even when network communication is abnormal.

[0032] During the operation of this system, heartbeat data, configuration data, collected data, early warning records, and alarm records have distinct data identities. Heartbeat data is used to establish the device's online status and is not directly used for threshold comparisons; configuration data is used to establish early warning and alarm thresholds in the local configuration storage area and is not directly used to display the current operating condition; collected data is used to establish the current weight, offset, settlement, and tilt angle values ​​and participates in status determination; early warning and alarm records are used to record triggered status events and participate in indexing, notification, and querying. The cloud server maintains that data identities are not mixed when writing or forwarding the above data. Mobile terminals display the binding status, configuration status, sensor current values, and alarm records on different pages, ensuring that device identity, device online status, configuration status, current operating condition status, and alarm traceability status are each formed by their corresponding data.

[0033] The specific structures, processes, field states, processing order, judgment conditions, parameter sources, device collaboration, sensor reading, circuit driving, cloud forwarding, and mobile terminal display relationships described in the above embodiments are used to explain the possible implementations of the present invention and should not limit the present invention to the specific embodiments listed. Without departing from the technical solutions described in the present invention and the technical solutions described in the application documents, any equivalent substitutions, equivalent modifications, equivalent combinations, order adjustments, module-to-module replacements, equivalent transformations of field names, equivalent acceptance of the executing entity, or equivalent changes in the carrier form that can be conceived by those skilled in the art should fall within the scope of protection of this patent, but should not be extended to unclaimed topics, nor should the substantive correspondence of the technical objects be changed through changes in reference numerals.

Claims

1. A remote intelligent monitoring and early warning system for high-support formwork, characterized in that, include: Monitoring host, weight sensor, offset sensor, settlement sensor, tilt sensor, audible and visual alarm, cloud server and mobile terminal; The monitoring host is communicatively connected to the weight sensor, the offset sensor, the settlement sensor and the tilt sensor respectively, and electrically connected to the audible and visual alarm. The monitoring host is connected to the cloud server through a wireless communication link, and the mobile terminal is connected to the cloud server through a network. The monitoring host is used to output the device identification graphic code, and the mobile terminal is used to collect the device identification graphic code and send a binding request and a threshold configuration request to the cloud server. The cloud server is used to generate configuration instructions or acquisition instructions based on the device binding status and the device online status. The monitoring host is used to write and read back the early warning threshold and the alarm threshold according to the configuration instructions, read the current value of the sensor according to the acquisition instructions, compare the current value of the sensor with the early warning threshold and the alarm threshold, drive the audible and visual alarm device and upload the alarm record.

2. The high-support formwork remote intelligent monitoring and early warning system according to claim 1, characterized in that: The monitoring host includes a main control circuit, a display screen, a local memory, a key circuit, a wireless communication circuit, and an alarm drive circuit; The main control circuit is electrically connected to the display screen, the local memory, the key circuit, the wireless communication circuit and the alarm drive circuit respectively; The display screen is used to display the device identification graphic code and the device operating status. The local memory is used to store the warning threshold, the alarm threshold and the alarm record. The alarm driving circuit is used to drive the audible and visual alarm according to the status signal output by the main control circuit.

3. The high-support formwork remote intelligent monitoring and early warning system according to claim 2, characterized in that: The main control circuit sends read commands sequentially to the weight sensor, the offset sensor, the settlement sensor, and the tilt sensor via the bus interface; The weight sensor is used to return the current weight value, the offset sensor is used to return the current offset value, the settlement sensor is used to return the current settlement value, and the tilt sensor is used to return the current tilt angle value. The main control circuit writes the current values ​​of weight, offset, settlement and tilt angle obtained in the same round of reading into the memory cache, and uses the memory cache as the data source for threshold comparison and recording upload.

4. The high-support formwork remote intelligent monitoring and early warning system according to claim 1, characterized in that: The device identification graphic code is generated by the monitoring host based on the device number and device name; After the mobile terminal collects the device identity graphic code, it combines the user account, the device number, and the binding action identifier into a binding request and sends it to the cloud server. The cloud server queries the device registration record and binding relationship record based on the device number. When the device registration record exists and the binding relationship record does not record the occupancy relationship, it writes the binding relationship between the user account and the device number and returns the binding result to the mobile terminal.

5. The high-support formwork remote intelligent monitoring and early warning system according to claim 4, characterized in that: The threshold configuration request includes weight warning threshold, weight alarm threshold, offset warning threshold, offset alarm threshold, settlement warning threshold, settlement alarm threshold, tilt angle warning threshold, tilt angle alarm threshold, and operation time; The mobile terminal performs a size comparison between the alarm threshold and the early warning threshold within the same monitoring type, and sends the threshold configuration request when the alarm threshold is greater than the early warning threshold. The cloud server verifies the configuration permissions based on the binding result and determines the online status of the device based on the most recent heartbeat time. When the device is online, the configuration instruction is generated, and when the device is offline, it is marked as waiting to be issued.

6. The high-support formwork remote intelligent monitoring and early warning system according to claim 1, characterized in that: The configuration instruction includes a frame header, device number, instruction type, configuration data body, and checksum; After receiving the configuration instruction, the monitoring host verifies the frame header, the device number, the instruction type, and the check code. If the verification is successful, the host writes the configuration data body into the local configuration storage area. The monitoring host reads back the threshold values ​​written from the local configuration storage area, compares the read-back threshold values ​​with the distribution threshold values ​​in the configuration data body item by item, generates configuration effective information when the comparison matches, generates configuration failure information when the comparison does not match, and returns the configuration effective information or the configuration failure information to the cloud server.

7. The high-support formwork remote intelligent monitoring and early warning system according to claim 1, characterized in that: The mobile terminal sends a real-time fetch request to the cloud server. The real-time fetch request includes the target device number, request type, and request time. The cloud server queries the device online status cache based on the target device number, returns an offline prompt to the mobile terminal when the device online status cache is offline, and generates the collection command and sends it to the monitoring host when the device online status cache is online. The monitoring host reads the current value of the sensor according to the acquisition command, and uploads the current value of the sensor, the acquisition time, and the target device number to the cloud server, which then forwards them to the mobile terminal.

8. The high-support formwork remote intelligent monitoring and early warning system according to claim 1, characterized in that: The monitoring host compares the current value of the same monitoring type with the corresponding early warning threshold and alarm threshold; When any of the current values ​​reaches or exceeds the corresponding alarm threshold, the monitoring host outputs an alarm status. When any of the current values ​​reaches or exceeds the corresponding warning threshold and is lower than the corresponding alarm threshold, the monitoring host outputs a warning status. When all the current values ​​are lower than the corresponding warning threshold, the monitoring host outputs a normal status.

9. The high-support formwork remote intelligent monitoring and early warning system according to claim 8, characterized in that: When the monitoring host outputs the normal status, it keeps the audible and visual alarm device in a non-alarm response state. When the monitoring host outputs the warning status, it drives the audible and visual alarm to emit warning lights and intermittent buzzers, and uploads the warning record, which consists of the trigger monitoring type, current value, warning level and trigger time, to the cloud server. When the monitoring host outputs the alarm status, it drives the audible and visual alarm to emit alarm lights and continuous buzzers, and uploads the alarm record, consisting of the trigger monitoring type, current value, alarm level and trigger time, to the cloud server.

10. The high-support formwork remote intelligent monitoring and early warning system according to claim 8, characterized in that: After receiving the alarm record or warning record, the cloud server establishes a bidirectional index based on the device number and trigger time, and maintains the alarm list in reverse order of the trigger time. The cloud server determines the remote notification path based on the alarm level. When the alarm level is a warning level, it sends a warning notification to the mobile terminal of the bound user. When the alarm level is an alarm level, it sends an alarm notification to the mobile terminal of the bound user and triggers an SMS notification. The mobile terminal sends query conditions to the cloud server based on the project name, device name, or device number. The cloud server returns the corresponding alarm list and alarm details based on the bidirectional index and the query conditions.

Images