A highway bridge remote real-time monitoring method and device based on the Internet of Things
By using status publishers and blank status publishers during sensor replacement, the problems of data errors and category confusion in bridge monitoring were solved, and accurate data transmission and reasonable server operation were achieved.
Patent Information
- Application Number
- CN202510630379.2
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2025-05-16
- Publication Date
- 2025-11-07
- Estimated Expiration
- 2045-05-16
AI Technical Summary
In existing technologies, sensor replacement during highway bridge monitoring can easily lead to errors in monitoring data or misclassification of data, resulting in inaccurate analysis results.
By setting up status publishers and blank status publishers and specifying operating procedures, we can ensure that sensors correctly update their status information during replacement, thus avoiding data errors and category confusion.
This effectively avoids monitoring data errors and category confusion, ensures the accuracy of monitoring data and the rationality of server operation logic, and simplifies the sensor replacement process.
Smart Images

Figure CN120378455B_ABST
Abstract
Description
TECHNICAL FIELD
[0001] The present application relates to the field of new generation information technology, in particular to a highway bridge remote real-time monitoring method and device based on Internet of Things. BACKGROUND
[0002] Highway bridges are the key areas of highway monitoring. With the rapid development of intelligent transportation and digital transformation, highway bridge monitoring is required to be transformed from manual inspection to "data-driven", and real-time, efficient and accurate monitoring data is required.
[0003] For super-long and super-high highway bridges, multiple sensors are generally required for monitoring, which can be black and white cameras, color cameras, temperature sensors, vibration sensors, infrared cameras, etc. Because the types of monitoring data provided by various sensors are different, the monitoring data provided by various sensors is generally stored independently in the server and analyzed by different analysis software. However, in the prior art, when replacing sensors, the problem of monitoring data error or monitoring data category disorder often occurs, which leads to incorrect analysis results. SUMMARY
[0004] To solve the problems of the prior art, the present application provides a highway bridge remote real-time monitoring method based on Internet of Things. The method of the present application avoids the problem of monitoring data category disorder by setting a state publisher and a blank state publisher and specifying the operation steps of the state publisher.
[0005] The present application provides a highway bridge remote real-time monitoring method based on Internet of Things, the method comprising:
[0006] Before the first sensor is disengaged from the connector, the first state publisher of the first sensor is triggered, wherein the connector provides a physical address of the connector;
[0007] After the first state publisher is triggered, the first sensor sends a first state indicator to the server, and the first sensor stops sending monitoring data to the server, wherein the first state indicator indicates to the server that the first sensor will be disengaged from the connector, and wherein the first state indicator further includes the physical address of the connector;
[0008] After the first sensor is disengaged from the connector, the connector is connected to the blank state publisher;
[0009] After the connector is connected to the blank state publisher, the blank state publisher sends a blank state indicator to the server; wherein the blank state indicator includes the physical address of the connector;
[0010] After the server receives the blank status indicator, the server no longer requests monitoring data from the first sensor.
[0011] In a preferred embodiment, the method further comprises:
[0012] Before the second sensor is plugged with the connector, sending, by the blank status publisher, an occupancy status indicator to the server, wherein the occupancy status indicator indicates to the server that the connector is to be plugged with a sensor, wherein the first sensor and the second sensor are different classes of sensors;
[0013] After the server receives the occupancy status indicator, starting, by the server, to listen for a status indicator sent by the second sensor;
[0014] After the second sensor is plugged with the connector, triggering a second status publisher of the second sensor.
[0015] In a preferred embodiment, the method further comprises:
[0016] After the second status publisher is triggered, sending, by the second sensor, a second status indicator to the server, wherein the second status indicator indicates to the server that the second sensor has been plugged with the connector, wherein the second status indicator further comprises a physical address of the connector;
[0017] After the server receives the second status indicator, starting, by the server, to send a sensor class request command to the second sensor;
[0018] After the second sensor receives the class request command, sending, by the second sensor, a sensor class to the server, wherein the server does not receive monitoring data sent by the second sensor until the server receives the sensor class.
[0019] In a preferred embodiment, the method further comprises:
[0020] Before the first sensor is plugged with the connector, sending, by the blank status publisher, an occupancy status indicator to the server, wherein the occupancy status indicator indicates to the server that the connector is to be plugged with a sensor;
[0021] After the server receives the occupancy status indicator, starting, by the server, to listen for a status indicator sent by the first sensor;
[0022] After the first sensor is plugged with the connector, triggering a first status publisher of the first sensor.
[0023] In a preferred embodiment, the method further comprises:
[0024] after the first status publisher is triggered, sending, by the first sensor, a third status indicator to the server, wherein the third status indicator indicates to the server that the first sensor has been mated with the connector, and wherein the third status indicator further includes a physical address of the connector;
[0025] after the server receives the third status indicator, requesting, by the server, the monitoring data directly from the first sensor;
[0026] after the first sensor receives the request for the monitoring data, sending, by the first sensor, the monitoring data to the server.
[0027] The application also provides a highway bridge remote real-time monitoring device based on the Internet of Things, which comprises modules for the following operations:
[0028] before unmating the first sensor from the connector, triggering a first status publisher of the first sensor, wherein the connector provides a physical address of the connector;
[0029] after the first status publisher is triggered, sending, by the first sensor, a first status indicator to the server, and the first sensor stops sending monitoring data to the server, wherein the first status indicator indicates to the server that the first sensor will be unmated from the connector, and wherein the first status indicator further includes the physical address of the connector;
[0030] after unmating the first sensor from the connector, mating the connector with a blank status publisher;
[0031] after mating the connector with the blank status publisher, sending, by the blank status publisher, a blank status indicator to the server; wherein the blank status indicator includes the physical address of the connector;
[0032] after the server receives the blank status indicator, the server no longer requests monitoring data from the first sensor.
[0033] In a preferred embodiment, the device further comprises modules for the following operations:
[0034] before mating the second sensor with the connector, sending, by the blank status publisher, an occupancy status indicator to the server, wherein the occupancy status indicator indicates to the server that the connector will be mated with a sensor, and wherein the first sensor and the second sensor are different types of sensors;
[0035] after the server receives the occupancy status indicator, starting, by the server, to listen for a status indicator sent by the second sensor;
[0036] after mating the second sensor with the connector, triggering a second status publisher of the second sensor.
[0037] In a preferred embodiment, the apparatus further comprises means for:
[0038] After the second state publisher is triggered, sending, by the second sensor, a second state indicator to the server, wherein the second state indicator indicates to the server that the second sensor has been plugged with the hub, and wherein the second state indicator further comprises a physical address of the hub;
[0039] After the server receives the second state indicator, starting, by the server, to send a sensor category request command to the second sensor;
[0040] After the second sensor receives the category request command, sending, by the second sensor, a sensor category to the server, wherein the server does not receive monitoring data sent by the second sensor until the server receives the sensor category.
[0041] In a preferred embodiment, the apparatus further comprises means for:
[0042] Before the first sensor is plugged with the hub, sending, by the blank state publisher, an occupancy state indicator to the server, wherein the occupancy state indicator indicates to the server that the hub will be plugged with a sensor;
[0043] After the server receives the occupancy state indicator, starting, by the server, to listen for a state indicator sent by the first sensor;
[0044] After the first sensor is plugged with the hub, triggering the first state publisher of the first sensor.
[0045] In a preferred embodiment, the apparatus further comprises means for:
[0046] After the first state publisher is triggered, sending, by the first sensor, a third state indicator to the server, wherein the third state indicator indicates to the server that the first sensor has been plugged with the hub, and wherein the third state indicator further comprises a physical address of the hub;
[0047] After the server receives the third state indicator, requesting, by the server, monitoring data directly from the first sensor;
[0048] After the first sensor receives the request for monitoring data, sending, by the first sensor, the monitoring data to the server.
[0049] Compared with the prior art, the present application has the following advantages: the present application provides a highway bridge remote real-time monitoring method based on the Internet of Things, and by setting the state publisher and the blank state publisher and stipulating the operation steps of the state publisher, the problems of monitoring data errors and monitoring data category disorder are avoided. BRIEF DESCRIPTION OF DRAWINGS
[0050] Figure 1 is a structural schematic diagram of an embodiment of the present application.
[0051] Figure 2 is a flow chart of a method of an embodiment of the present application.
[0052] Figure 3 is a schematic diagram of a first state publisher of an embodiment of the present application. DETAILED DESCRIPTION
[0053] The specific embodiments of the present application will now be described in detail with reference to the accompanying drawings, but the scope of protection of the present application is not limited by the specific embodiments.
[0054] As described above, in the prior art, when replacing the sensor, the monitoring data error or the monitoring data category confusion problem often occurs, and the specific analysis of the problem is as follows: due to the particularity of the bridge structure, the sensor is required to be strictly located at the pre-designed position during the real-time monitoring of the bridge, therefore, the bridge monitoring server generally needs the sensor to report its physical position while the sensor transmits the monitoring data, which is generally realized through the power supply connector, for example, some sensors can be powered by USB, and the physical position of the USB power supply connector can be transmitted to the sensor while the USB power supply connector is powered, for example, some sensors can be powered by type-c, and the physical position of the type-c power supply connector can be transmitted to the sensor while the type-c power supply connector is powered. When the sensor needs to be replaced due to hardware upgrade or the sensor position needs to be replaced due to monitoring scheme update, the operation steps of the prior art will cause the monitoring data error. Taking a black and white camera as an example, the black and white camera can communicate with the server wirelessly, when the sensor position needs to be replaced due to the monitoring scheme update, for example, the engineer first removes the black and white camera from the power supply connector (that is, removes the USB connector connected to the black and white camera), at this time, although the black and white camera is separated from the power supply connector, the black and white camera can still work due to the battery inside the black and white camera, but since the position of the black and white camera has deviated from the original predetermined position, the photos taken by the black and white camera are obviously incorrect monitoring data, but since the black and white camera still communicates with the server at this time, the black and white camera may send these incorrect data to the server. A possible solution to solve this problem is: before removing the black and white camera from the power supply connector, first turn off the black and white camera, and then turn on the black and white camera after the black and white camera is reconnected with other connectors. The problem of this solution is that for bridge monitoring, the black and white camera needs to go through complicated settings before it is used again after being turned on, and if the black and white camera is moved every time, it needs to be reconfigured, which is too cumbersome. Another possible solution is that when the black and white camera is removed from the connector, the physical position of the connector stored by the black and white camera is automatically deleted, so that the server cannot receive incorrect format monitoring data, thereby solving the problem of incorrect monitoring data. However, in fact, the current electronic products judge whether the USB interface is occupied by the voltage at the USB interface, that is, when the USB connector stops supplying power to the black and white camera due to failure or power failure, the black and white camera also considers that the black and white camera is removed from the connector, and at this time, it is unreasonable for the black and white camera to delete the physical position of the connector. In addition, sending data to the server in this way will cause the server to be unable to know the reason why the sensor is removed from the connector, which may cause the operation logic of the server to be confused.
[0055] When the sensor position needs to be exchanged due to the monitoring scheme update, the prior art will have the problem of monitoring data category confusion. Taking the camera and thermometer exchanging positions as an example, the data monitored by the camera are all photos, and the data monitored by the thermometer are numerical values. When the positions of the two sensors are exchanged, the current standard operation process is that the engineer first removes the camera from the connector, then reinserts the thermometer into the connector, and then the engineer uses the terminal carried by the engineer to configure the data type at the position of the connector as "numerical value" (the data type at the position of the connector is originally "photo"). However, this scheme depends on the manual operation of the engineer, and if the engineer mistakenly selects the wrong data type, it will cause the server to store the monitoring data to the wrong position, and the analysis software will use the wrong data for analysis, which will cause errors. The scheme proposed by the present application can solve the problem of the prior art. It should be understood that the above analysis is the conclusion of the researchers of our company based on their knowledge and reasoning, and does not constitute prior art in the sense of the Patent Law.
[0056] Figure 1 is a structural schematic diagram of an embodiment of the present application. As shown in the figure, the monitoring system can arrange a plurality of sensors at the bridge deck and the pier. These sensors can send monitoring data to the server through wireless communication. In Figure 1 , the sensors can be arranged at a plurality of positions of the bridge deck, and can be arranged at the bottom of the pier and the top of the pier.
[0057] Embodiment 1
[0058] Figure 2 is a method flowchart of an embodiment of the present application. As shown in the figure, the method of the present application comprises the following steps:
[0059] Step 1: before removing the first sensor from the connector, trigger the first state publisher of the first sensor, wherein the connector provides the physical address of the connector; in one example, the first sensor can be powered by USB, and at this time the connector is a USB connector; in one example, removing the first sensor from the connector means pulling out the USB connector on the first sensor; in one example, the first sensor can be a black and white camera, a color camera, a temperature sensor, a vibration sensor or an infrared camera; in one example, the format of the physical address of the connector can be "xx Bridge No. 1 monitoring site"; in one example, the example of the first state publisher can refer to Figure 3 , the first state publisher can include two physical buttons (in Figure 3 , the two buttons are arranged on the side of the camera), which are shown as "insert" and "remove" buttons in Figure 3 , when the engineer presses the "remove" button, the first sensor will send a first state indicator to the server;
[0060] Step 2: After the first status publisher is triggered, the first sensor sends a first status indicator to the server, and the first sensor stops sending monitoring data to the server, wherein the first status indicator indicates to the server that the first sensor will be disengaged from the adapter, and wherein the first status indicator further comprises the physical address of the adapter; in one example, the status indicator can comprise a plurality of fields, wherein one field can be a binary number indicating the status of the sensor and the adapter, wherein "0" can represent that the first sensor will be disengaged from the adapter, and "1" represents that the first sensor is engaged with the adapter; the status indicator can further comprise an identity identifier of the sensor; in embodiment 1, since the first sensor stops sending monitoring data to the server as soon as "disengagement" is triggered, embodiment 1 can avoid the problem of monitoring data errors in the prior art; at the same time, since the server knows that the first sensor stops sending monitoring data because it is about to be disengaged from the adapter (i.e. the first sensor is about to leave the predetermined position), this helps the software on the server side to clarify the operation logic;
[0061] Step 3: After disengaging the first sensor from the adapter, the adapter is engaged with a blank status publisher;
[0062] Step 4: After the adapter is engaged with the blank status publisher, the blank status publisher sends a blank status indicator to the server; wherein the blank status indicator comprises the physical address of the adapter; in one example, the blank status publisher can be an electronic device that is engaged with the adapter and sends the blank status indicator and the occupancy status indicator; the main function of the blank status publisher is to prevent the adapter from being in a suspended state for a long time. For example, if there is no blank status publisher, after the first sensor is disengaged from the adapter, the adapter is in a suspended state (i.e. the adapter is not connected to any device), and since the adapter is not connected to any device, the server cannot update the status of the adapter in real time, for example, the server can only know that the first sensor has been removed, but the monitoring position has reconnected the first sensor, but the monitoring data is sent to another server, or the monitoring position has reconnected the first sensor, but the first sensor is damaged and cannot send monitoring data to the server, and the server does not know about these, so the server cannot reasonably perform the next operation; according to the current operation logic of the software, the server will try to request monitoring data from the first sensor when the first sensor is reconnected at the monitoring position, but if the first sensor happens to be in a powered-on state and is not at the original monitoring position, the first sensor will still send incorrect monitoring data to the server; the blank status indicator can be sent periodically;
[0063] After the server receives the blank status indicator, the server no longer requests monitoring data from the first sensor.
[0064] Embodiment 2
[0065] In embodiment 2, the method further comprises:
[0066] Before the second sensor is plugged with the junction, the blank status publisher sends an occupancy status indicator to the server, wherein the occupancy status indicator indicates to the server that the junction is about to be plugged with a sensor, wherein the first sensor and the second sensor are different types of sensors; in one example, the occupancy status indicator can be triggered by an engineer to send, for example, a physical button can be set on the blank status publisher, when the engineer wants to install a second sensor at the location of the junction, the engineer can trigger the physical button, so that the blank status publisher sends an occupancy status indicator to the server, in one example, the second sensor can be a black and white camera, a color camera, a temperature sensor, a vibration sensor or an infrared camera, but the second sensor is different from the first sensor type; the occupancy status indicator helps the server to clearly know that the junction is not currently plugged with a sensor, and the junction is about to be plugged with a sensor;
[0067] After the server receives the occupancy status indicator, the server starts to listen to the status indicator sent by the second sensor;
[0068] After the second sensor is plugged with the junction, the second status publisher of the second sensor is triggered. In one example, the example of the second status publisher can also be seen from Figure 3 .
[0069] Embodiment 3
[0070] In embodiment 3, the method further comprises:
[0071] After the second status publisher is triggered, the second sensor sends a second status indicator to the server, wherein the second status indicator indicates to the server that the second sensor has been plugged with the junction, wherein the second status indicator further comprises the physical address of the junction; in one example, the second status indicator can comprise a plurality of fields, wherein one field can be a binary number, which is used to indicate the plugging state of the sensor with the junction, and the second status indicator can further comprise the identity identifier of the sensor;
[0072] After the server receives the second status indicator, the server starts to send a sensor category request command to the second sensor;
[0073] After the second sensor receives the category request command, the second sensor sends a sensor category to the server, wherein the server does not receive the monitoring data sent by the second sensor before the server receives the sensor category. In embodiment 3, the second sensor automatically reports the sensor category to the server without human intervention, thus reducing the probability of setting an error of the sensor category.
[0074] Embodiment 4
[0075] In embodiment 4, the method further comprises:
[0076] Before the first sensor is plugged with the connector, the blank state publisher sends an occupancy status indicator to the server, wherein the occupancy status indicator indicates to the server that the connector will be plugged with the sensor;
[0077] After the server receives the occupancy status indicator, the server starts to listen to the status indicator sent by the first sensor;
[0078] After the first sensor is plugged with the connector, the first state publisher of the first sensor is triggered.
[0079] In a preferred embodiment, the method further comprises:
[0080] After the first state publisher is triggered, the first sensor sends a third status indicator to the server, wherein the third status indicator indicates to the server that the first sensor has been plugged with the connector, wherein the third status indicator further comprises the physical address of the connector; the third status indicator further comprises the identity identifier of the first sensor;
[0081] After the server receives the third status indicator, the server directly requests the monitoring data from the first sensor;
[0082] After the first sensor receives the request for the monitoring data, the first sensor sends the monitoring data to the server.
[0083] Embodiment 5
[0084] The application also provides a highway bridge remote real-time monitoring device based on the Internet of Things, the device comprising modules for the following operations:
[0085] Before the first sensor is unplugged from the connector, the first state publisher of the first sensor is triggered, wherein the connector provides the physical address of the connector;
[0086] after the first status publisher is triggered, sending, by the first sensor, a first status indicator to the server, and the first sensor ceasing to send monitoring data to the server, wherein the first status indicator indicates to the server that the first sensor will be unpaired from the connector, and wherein the first status indicator further comprises a physical address of the connector;
[0087] after the first sensor is unpaired from the connector, pairing the connector with a blank status publisher;
[0088] after pairing the connector with the blank status publisher, sending, by the blank status publisher, a blank status indicator to the server, wherein the blank status indicator comprises the physical address of the connector;
[0089] after the server receives the blank status indicator, the server ceasing to request monitoring data from the first sensor.
[0090] In a preferred embodiment, the apparatus further comprises means for:
[0091] before pairing the second sensor with the connector, sending, by the blank status publisher, an occupancy status indicator to the server, wherein the occupancy status indicator indicates to the server that the connector will be paired with a sensor, and wherein the first sensor and the second sensor are different classes of sensors;
[0092] after the server receives the occupancy status indicator, the server beginning to listen for a status indicator sent by the second sensor;
[0093] after pairing the second sensor with the connector, triggering a second status publisher of the second sensor.
[0094] In a preferred embodiment, the apparatus further comprises means for:
[0095] after the second status publisher is triggered, sending, by the second sensor, a second status indicator to the server, wherein the second status indicator indicates to the server that the second sensor has been paired with the connector, and wherein the second status indicator further comprises the physical address of the connector;
[0096] after the server receives the second status indicator, the server beginning to send a sensor class request command to the second sensor;
[0097] after the second sensor receives the class request command, sending, by the second sensor, a sensor class to the server, and wherein the server does not receive monitoring data sent by the second sensor until the server receives the sensor class.
[0098] In a preferred embodiment, the apparatus further comprises means for:
[0099] before the first sensor is plugged with the connector, sending, by the blank state publisher, an occupancy status indicator to the server, wherein the occupancy status indicator indicates to the server that the connector is to be plugged with the sensor;
[0100] after the server receives the occupancy status indicator, starting, by the server, to listen for a status indicator sent by the first sensor;
[0101] after the first sensor is plugged with the connector, triggering the first state publisher of the first sensor.
[0102] In a preferred embodiment, the apparatus further comprises means for:
[0103] after the first state publisher is triggered, sending, by the first sensor, a third status indicator to the server, wherein the third status indicator indicates to the server that the first sensor has been plugged with the connector, wherein the third status indicator further comprises the physical address of the connector;
[0104] after the server receives the third status indicator, requesting, by the server, the monitoring data directly from the first sensor;
[0105] after the first sensor receives the request for the monitoring data, sending, by the first sensor, the monitoring data to the server.
[0106] It should be understood that the foregoing detailed description of the application, rather than limiting the application, is provided merely for the purpose of illustrative description of the principles of the application. Therefore, any modification, equivalent replacement, improvement, etc. made without departing from the spirit and scope of the application should be included in the protection scope of the application. In addition, the appended claims of the application are intended to cover all variations and modifications falling within the scope and boundary of the appended claims, or the equivalent forms of such scope and boundary.
Claims
1. A method for monitoring a highway bridge in real time remotely based on Internet of Things, the method comprising: triggering a first status publisher of a first sensor before disengaging the first sensor from a connector, wherein the connector provides a physical address of the connector; after the first status publisher is triggered, sending, by the first sensor, a first status indicator to a server and the first sensor stops sending monitoring data to the server, wherein the first status indicator indicates to the server that the first sensor will be disengaged from the connector, wherein the first status indicator further comprises the physical address of the connector; after disengaging the first sensor from the connector, engaging the connector with a blank status publisher; after engaging the connector with the blank status publisher, sending, by the blank status publisher, a blank status indicator to the server, wherein the blank status indicator comprises the physical address of the connector; after the server receives the blank status indicator, the server no longer requests monitoring data from the first sensor.
2. The method of claim 1, wherein, The method further comprises: before engaging a second sensor with the connector, sending, by the blank status publisher, an occupancy status indicator to the server, wherein the occupancy status indicator indicates to the server that the connector will be engaged with a sensor, wherein the first sensor and the second sensor are different types of sensors; after the server receives the occupancy status indicator, the server starts listening for a status indicator sent by the second sensor; after engaging the second sensor with the connector, triggering a second status publisher of the second sensor.
3. The method of claim 2, wherein, The method further comprises: after the second status publisher is triggered, sending, by the second sensor, a second status indicator to the server, wherein the second status indicator indicates to the server that the second sensor has been engaged with the connector, wherein the second status indicator further comprises the physical address of the connector; after the server receives the second status indicator, the server starts sending a sensor type request command to the second sensor; after the second sensor receives the type request command, sending, by the second sensor, a sensor type to the server, wherein the server does not receive monitoring data sent by the second sensor until the server receives the sensor type.
4. The method of claim 1, wherein, The method further comprises: before engaging the first sensor with the connector, sending, by the blank status publisher, an occupancy status indicator to the server, wherein the occupancy status indicator indicates to the server that the connector will be engaged with a sensor; after the server receives the occupancy status indicator, the server starts listening for a status indicator sent by the first sensor; after engaging the first sensor with the connector, triggering a first status publisher of the first sensor.
5. The method of claim 4, wherein, The method further comprises: after the first status publisher is triggered, sending, by the first sensor, a third status indicator to the server, wherein the third status indicator indicates to the server that the first sensor has been plugged with the dongle, and wherein the third status indicator further comprises a physical address of the dongle; after the server receives the third status indicator, requesting, by the server, monitoring data directly from the first sensor; after the first sensor receives the request for monitoring data, sending, by the first sensor, the monitoring data to the server.
6. An Internet of Things based highway bridge remote real-time monitoring device, the device comprising modules for: triggering a first state publisher of the first sensor before disengaging the first sensor from the fitting, wherein the dongle providing a physical address of the dongle; after the first status publisher is triggered, sending, by the first sensor, a first status indicator to the server, and the first sensor stops sending monitoring data to the server, wherein the first status indicator indicates to the server that the first sensor will be unplugged from the dongle, and wherein the first status indicator further comprises a physical address of the dongle; after the first sensor is unplugged from the dongle, plugging the dongle with a blank status publisher; after the dongle is plugged with the blank status publisher, sending, by the blank status publisher, a blank status indicator to the server, wherein the blank status indicator comprises the physical address of the dongle; after the server receives the blank status indicator, the server no longer requests monitoring data from the first sensor.
7. The apparatus of claim 6, wherein, the device further comprising modules for: before the second sensor is plugged with the dongle, sending, by the blank status publisher, an occupancy status indicator to the server, wherein the occupancy status indicator indicates to the server that the dongle will be plugged with a sensor, and wherein the first sensor and the second sensor are different classes of sensors; after the server receives the occupancy status indicator, starting, by the server, to listen for a status indicator sent by the second sensor; after the second sensor is plugged with the dongle, triggering a second status publisher of the second sensor.
8. The apparatus of claim 7, wherein, the device further comprising modules for: after the second status publisher is triggered, sending, by the second sensor, a second status indicator to the server, wherein the second status indicator indicates to the server that the second sensor has been plugged with the dongle, and wherein the second status indicator further comprises a physical address of the dongle; after the server receives the second status indicator, starting, by the server, to send a sensor class request command to the second sensor; after the second sensor receives the class request command, sending, by the second sensor, a sensor class to the server, wherein the server does not receive monitoring data sent by the second sensor until the server receives the sensor class.
9. The apparatus of claim 6, wherein, the device further comprising modules for: before the first sensor is plugged with the hub, sending, by a blank state publisher, an occupancy state indicator to the server, wherein the occupancy state indicator indicates to the server that the hub is to be plugged with a sensor; after the server receives the occupancy state indicator, starting, by the server, to listen for a state indicator sent by the first sensor; after the first sensor is plugged with the hub, triggering a first state publisher of the first sensor.
10. The apparatus of claim 9, wherein, The apparatus further includes means for: after the first state publisher is triggered, sending, by the first sensor, a third state indicator to the server, wherein the third state indicator indicates to the server that the first sensor has been plugged with the hub, wherein the third state indicator further includes a physical address of the hub; after the server receives the third state indicator, requesting, by the server, monitoring data directly from the first sensor; after the first sensor receives the request for monitoring data, sending, by the first sensor, the monitoring data to the server.
Citation Information
Patent Citations
Method and plug-in connection for informing a process control center about a sensor being disconnected from a measuring transducer
CN105675036A
Multi-node wireless monitoring system for operation state of key facilities of common highway bridge
CN117692949A