Modbus TCP Device Tracking
Complete real polling, message parsing, pause, one-shot execution, fault, circuit breaking, and recovery with an FMQX Modbus TCP slave. FMQX is a FastBee self-developed client tool, different from the third-party MQTTX.
Page Guide
Use CasesFor operators who need to verify each polling request and response with Device Tracking and confirm recovery when Modbus TCP polling, message parsing, or circuit breaking behaves abnormally.
PrerequisitesDevice Tracking view and corresponding runtime operation permissions; prepare one FMQX Modbus TCP slave kept online. Estimated time: 15 minutes.
Acceptance CriteriaPolling requests and responses appear in pairs on the timeline, and pause, one-shot execution, circuit breaking, and recovery events all align with device-side actions.
How to Read
Confirm the entry point, permissions, and target object first, then complete the operations in numbered order. Each step includes the expected result; detailed fields and options are collected in expandable reference tables.
About the Screenshots
The screenshots come from the original operation manual. The public version hides real node addresses, connection addresses, and credentials; the statuses, times, and data in the examples do not represent the current production environment.
Before You Start
| Item | Description |
|---|---|
| What you can do | Complete real polling, message parsing, pause, one-shot execution, fault, circuit breaking, and recovery with an FMQX Modbus TCP slave. |
| Entry point | Tracking → Device Tracking |
| Required permissions | Device Tracking view and corresponding runtime operation permissions |
| Estimated time | 15 minutes |
Procedure
1. Establish the Device Connection in FMQX
Location: FMQX → Connection Session
Confirm the device session name, protocol, endpoint, and connection status.
Figure: the Modbus TCP session is connected, with the device-side identity and send/receive statistics visible.
2. Make the Device Generate Real Data
Location: FMQX → Data Area
Keep the slave online, wait for the platform to issue polling requests, and return real responses.
Figure: FMQX real-time evidence shows this round's request and response, proving the slave has received and replied to the platform's polling.
3. Locate the Object on the Workbench
Location: Tracking → Device Tracking
Enter the device identifier and use Open Tracked Object.
Figure: enter a client ID, device number, or tracking key, then open the same tracked object.
Field Descriptions
| Field / Control | Description |
|---|---|
| Identifier Input | You can enter a client ID, IP, device number, deviceKey, sessionId, or a full tracking key. |
| Open Tracked Object | Parses the input and opens the same object; not used to create a device profile. |
4. Read the Object Status and Entry Actions
Location: Tracking → Device Tracking → Tracked Object List
Only review the status, protocol, and risk conclusion of the current protocol object, then enter the details.
Figure: the current Modbus TCP object card centrally shows tracking status, protocol, and risk conclusion, and provides delete and view details.
Field Descriptions
| Field / Control | Description |
|---|---|
| Tracking Status | Distinguishes Not Started, Tracking, and Ended; new evidence is collected only while tracking is active. |
| Protocol | Indicates which communication method the current object is parsed and displayed by. |
| Risk Conclusion | The troubleshooting priority given by the platform based on current evidence; not equivalent to the final fault cause. |
| Tracking Key | The unique runtime identifier of the current tracked object, used to avoid cross-wiring objects with the same name. |
5. Understand the Full Tracking Details Page First
Location: Tracking → Device Tracking → Tracking Details
First confirm the positional relationship of the top tools, object summary, left timeline, and the three detail tabs on the right from the whole page.
Figure: Tracking Details consists of the top tools, object summary, left timeline, and right analysis area; select an event first, then switch evidence tabs.
6. Master the Details Top Toolbar
Location: Tracking Details → Top Toolbar
Confirm back, the tracking switch, download, refresh, search, and the reserved entry.
Figure: the top toolbar is used to go back, toggle tracking, download evidence, refresh, and search other objects; AI Deep Tracking is currently a reserved entry.
Field Descriptions
| Field / Control | Description |
|---|---|
| Back to Workbench | Returns to the object list without stopping tracking. |
| Enable/Disable Tracking | Starts ten minutes of real-time collection, or stops collecting new events. |
| Download Evidence | Downloads the current object's evidence text, suitable for handover troubleshooting. |
| Refresh | Reads the latest status immediately; the page also auto-refreshes every three seconds. |
| AI Deep Tracking | Currently only a reserved entry; do not treat it as a completed diagnosis. |
| Global Search | Switches to another tracked object without returning to the workbench. |
7. Read the Object Status Summary
Location: Tracking Details → Object Summary
Verify identity, online status, remaining time, evidence count, and key issues.
Figure: confirm the object identity, tracking remaining time, timeline count, source evidence, and key issues first, then continue to individual events.
Field Descriptions
| Field / Control | Description |
|---|---|
| Object Identity | Distinguishes registered devices from runtime-discovered objects; an unconfirmed identity does not mean communication failed. |
| Running Status | Indicates whether the object is currently online or collecting; judge it separately from individual message results. |
| Remaining Time | How long remains before this real-time tracking session ends automatically. |
| Timeline Count | The number of readable events aggregated for the current object. |
| Source Evidence | Indicates which runtime source this conclusion is based on. |
| Key Issues | The number of abnormal or identity issues that should be reviewed first. |
| Collection Mode | Live means collecting; Standby means read-only access to existing evidence. |
8. Select an Event from the Timeline
Location: Tracking Details → Timeline List
Filter by stage and select this real communication event.
Figure: the timeline groups request, reply, parsing, and output by polling round, and can be filtered by All, Abnormal, Awaiting Reply, Parsed, and Output.
Field Descriptions
| Field / Control | Description |
|---|---|
| Occurrence Time | The time the event entered the tracking timeline, used to align with FMQX device time. |
| Stage | Indicates whether the event is in the connect, report, parse, output, or recovery stage. |
| Event Type | The stable type of the runtime raw event, used for precise location. |
| Flow Status | Indicates whether downstream links have captured, are waiting for, or lack evidence. |
| Stage Filter | Only changes the current list scope; does not delete evidence. |
9. View Event Source Evidence
Location: Tracking Details → Event Evidence
Confirm the event source, time, protocol context, and associated evidence.
Figure: Event Evidence answers when this record occurred, where it came from, which stage it belongs to, and what context the platform holds.
Field Descriptions
| Field / Control | Description |
|---|---|
| Source Evidence | Indicates which runtime source this conclusion is based on. |
| Protocol Context | Modbus TCP does not use topic subscription; it relies on the TCP session, Unit ID, and the published polling plan. |
| Source Time | The time the evidence was generated, used to verify it belongs to this operation. |
| View All Source Evidence | Expands all sources of the current object without changing the runtime state. |
10. Read the Full Message and Flow
Location: Tracking Details → Message Tracing
From top to bottom, verify the link conclusion, the device-side Unit ID and register addresses with the raw message, the MQ forwarded message, the forwarding process, and the technical fields.
Figure: full message tracing starts from the link conclusion, then shows the device raw message, MQ forwarded message, forwarding process, and technical fields in order.
Field Descriptions
| Field / Control | Description |
|---|---|
| Link Type | Indicates whether the current comparison is between device reporting and MQ forwarding, or a device command or Modbus poll. |
| Event Time | The time the currently selected event occurred; should be close to the device-side send or reply time. |
| Device Report Status | Captured means the platform retained the raw message entering FMQ from the device; a non-report event does not mean communication failed. |
| Platform Rule or Connector Status | Indicates whether the current event found matching uplink rules and connector flow evidence. |
| MQ Forwarding Status | Forwarded means the connector has submitted; when waiting or not captured, continue checking rules and connectors. |
| Link Conclusion | A complete link only proves tracking has seen the device message and forwarding evidence; whether the business system consumed it must be confirmed separately. |
| Device Protocol | The protocol on the device report card; should match the current tracked object. |
| Source Topic or Address | MQTT shows the Topic, TCP shows the remote address, and Modbus TCP shows the polling endpoint or response clue. |
| Device Event Type | The raw event type recorded by the platform, used to distinguish connect, report, parse, and reply. |
| Running Node | The FMQ node that processed this message, used to troubleshoot cluster node differences. |
| traceId | The correlation identifier of the device-side event, used to cross-check with logs, rules, or downstream records. |
| Device Raw Message | The raw Payload or hexadecimal frame retained when the device entered FMQ; the basis for judging what the device actually sent. |
| Output Target | Indicates which connector or external target this uplink message is about to be delivered to. |
| Delivery Address | Shows the Topic, Exchange/RoutingKey, or other actual delivery address, used to verify the target selection. |
| flowId | The correlation identifier of one platform forwarding process, used to string processing stages into the same link. |
| MQ Forwarded Message | The message body handed to the connector after rule processing; can be compared with the device raw message for field changes. |
| Forwarding Process and Duration | When expanded, shows rule matching, action submission, and connector execution times by stage; on failure, find the first abnormal stage first. |
| Technical Fields | When expanded, lists message, node, exception, and correlation identifiers for implementation and R&D to locate further. |
11. Understand Comprehensive Diagnosis and Protocol Actions
Location: Tracking Details → Comprehensive Diagnosis
Read the conclusion, causes, and suggested actions; only execute buttons supported by the current protocol and session.
Figure: Comprehensive Diagnosis gives the current conclusion, possible causes, and suggested actions; whether an action appears depends on the protocol, session, and selected event.
Field Descriptions
| Field / Control | Description |
|---|---|
| Diagnosis Conclusion | A plain-language conclusion about the currently selected event. |
| Possible Causes | Troubleshooting directions listed by the platform from existing evidence; does not mean the root cause is confirmed. |
| Suggested Actions | The next step matching the current event, protocol, and session context. |
| Action Conditions | Reschedule only rearranges the plan; Run One Round Now enqueues immediately; pause does not disconnect the device; Clear Circuit Breaker should be used after the endpoint recovers. |
12. Verify the Action with Device-Side Counters
Location: FMQX → Session Summary
Compare the uplink/downlink counters and connection generation to confirm this round of actions produced new device communication.
Figure: after the FMQX slave recovers, the uplink/downlink counters keep growing, proving new polling requests and replies have occurred again.
13. Confirm Real Receipt on the Device Side
Location: FMQX → Real-time Evidence
Verify the received requests and sent responses appearing in pairs at the same time.
Figure: FMQX real-time evidence shows received requests and sent responses in time-ordered pairs, proving the slave genuinely participates in polling.
14. Align Disconnection, Abnormality, and Recovery
Location: Tracking Details → Timeline List
Review disconnection or timeout records, then locate the new events after recovery.
Figure: the same timeline retains the failure and the new polls after recovery; recovery must be based on new reply and parse events.
Field Descriptions
| Field / Control | Description |
|---|---|
| Abnormality Time | The time the fault or disconnection was recorded. |
| Abnormality Stage | Indicates whether the failure occurred in connect, send, waiting for reply, parse, or output. |
| Abnormality Cause | The observable error or offline cause this time. |
| New Events After Recovery | After the slave disconnects, timeout and circuit breaking appear; after restoring the same endpoint, clearing the circuit breaker, and rescheduling, new replies and parsing appear again. |
15. Complete the Recovery Judgment
Location: Tracking Details → Comprehensive Diagnosis
Confirm together the device-side real receipt, the new events after recovery, and the current diagnosis.
Figure: finally judge the device-side real receipt, platform new events, and comprehensive diagnosis together; historical abnormalities remain but do not mean current communication still fails.
Field Descriptions
| Field / Control | Description |
|---|---|
| Current Conclusion | The current judgment formed from the latest evidence. |
| Historical Abnormalities | Old fault records that are retained; the presence of historical abnormalities does not mean current communication still fails. |
| Recovery Signal | After the slave disconnects, timeout and circuit breaking appear; after restoring the same endpoint, clearing the circuit breaker, and rescheduling, new replies and parsing appear again. |
| Next Checkpoint | The location recommended to check first when current evidence is insufficient. |
Client Page Field Reference
The following explains page fields in the reading order of the client list and detail tabs; areas not applicable to the protocol are explicitly marked, and technical logs are not treated as page fields.
Full Reference
| Field / Unit | Plain Meaning | Data Direction / Source | Normal Judgment | Abnormal Signals and First Checkpoint |
|---|---|---|---|---|
| Locate the Tracked Object | ||||
| Identifier Input- | You can enter a client ID, IP, device number, deviceKey, sessionId, or a full tracking key. | Page runtime state | Consistent with this operation's time, object identity, and protocol. | Data is empty, the time does not belong to this operation, the protocol does not match, or the page shows waiting while the device has already acted. First checkpoint: verify the object identity and that tracking is enabled, then generate a new piece of data in FMQX and refresh. |
| Open Tracked Object- | Parses the input and opens the same object; not used to create a device profile. | Page runtime state | Consistent with this operation's time, object identity, and protocol. | Data is empty, the time does not belong to this operation, the protocol does not match, or the page shows waiting while the device has already acted. First checkpoint: verify the object identity and that tracking is enabled, then generate a new piece of data in FMQX and refresh. |
| Read Workbench Object Status | ||||
| Tracking Status- | Distinguishes Not Started, Tracking, and Ended; new evidence is collected only while tracking is active. | Page runtime state | Consistent with this operation's time, object identity, and protocol. | Data is empty, the time does not belong to this operation, the protocol does not match, or the page shows waiting while the device has already acted. First checkpoint: verify the object identity and that tracking is enabled, then generate a new piece of data in FMQX and refresh. |
| Protocol- | Indicates which communication method the current object is parsed and displayed by. | Page runtime state | Consistent with this operation's time, object identity, and protocol. | Data is empty, the time does not belong to this operation, the protocol does not match, or the page shows waiting while the device has already acted. First checkpoint: verify the object identity and that tracking is enabled, then generate a new piece of data in FMQX and refresh. |
| Risk Conclusion- | The troubleshooting priority given by the platform based on current evidence; not equivalent to the final fault cause. | Page runtime state | Consistent with this operation's time, object identity, and protocol. | Data is empty, the time does not belong to this operation, the protocol does not match, or the page shows waiting while the device has already acted. First checkpoint: verify the object identity and that tracking is enabled, then generate a new piece of data in FMQX and refresh. |
| Tracking Key- | The unique runtime identifier of the current tracked object, used to avoid cross-wiring objects with the same name. | Page runtime state | Consistent with this operation's time, object identity, and protocol. | Data is empty, the time does not belong to this operation, the protocol does not match, or the page shows waiting while the device has already acted. First checkpoint: verify the object identity and that tracking is enabled, then generate a new piece of data in FMQX and refresh. |
| Master the Details Toolbar | ||||
| Back to Workbench- | Returns to the object list without stopping tracking. | Page runtime state | Consistent with this operation's time, object identity, and protocol. | Data is empty, the time does not belong to this operation, the protocol does not match, or the page shows waiting while the device has already acted. First checkpoint: verify the object identity and that tracking is enabled, then generate a new piece of data in FMQX and refresh. |
| Enable/Disable Tracking- | Starts ten minutes of real-time collection, or stops collecting new events. | Page runtime state | Consistent with this operation's time, object identity, and protocol. | Data is empty, the time does not belong to this operation, the protocol does not match, or the page shows waiting while the device has already acted. First checkpoint: verify the object identity and that tracking is enabled, then generate a new piece of data in FMQX and refresh. |
| Download Evidence- | Downloads the current object's evidence text, suitable for handover troubleshooting. | Page runtime state | Consistent with this operation's time, object identity, and protocol. | Data is empty, the time does not belong to this operation, the protocol does not match, or the page shows waiting while the device has already acted. First checkpoint: verify the object identity and that tracking is enabled, then generate a new piece of data in FMQX and refresh. |
| Refresh- | Reads the latest status immediately; the page also auto-refreshes every three seconds. | Page runtime state | Consistent with this operation's time, object identity, and protocol. | Data is empty, the time does not belong to this operation, the protocol does not match, or the page shows waiting while the device has already acted. First checkpoint: verify the object identity and that tracking is enabled, then generate a new piece of data in FMQX and refresh. |
| AI Deep Tracking- | Currently only a reserved entry; do not treat it as a completed diagnosis. | Page runtime state | Consistent with this operation's time, object identity, and protocol. | Data is empty, the time does not belong to this operation, the protocol does not match, or the page shows waiting while the device has already acted. First checkpoint: verify the object identity and that tracking is enabled, then generate a new piece of data in FMQX and refresh. |
| Global Search- | Switches to another tracked object without returning to the workbench. | Page runtime state | Consistent with this operation's time, object identity, and protocol. | Data is empty, the time does not belong to this operation, the protocol does not match, or the page shows waiting while the device has already acted. First checkpoint: verify the object identity and that tracking is enabled, then generate a new piece of data in FMQX and refresh. |
| Read the Object Status Summary | ||||
| Object Identity- | Distinguishes registered devices from runtime-discovered objects; an unconfirmed identity does not mean communication failed. | Page runtime state | Consistent with this operation's time, object identity, and protocol. | Data is empty, the time does not belong to this operation, the protocol does not match, or the page shows waiting while the device has already acted. First checkpoint: verify the object identity and that tracking is enabled, then generate a new piece of data in FMQX and refresh. |
| Running Status- | Indicates whether the object is currently online or collecting; judge it separately from individual message results. | Page runtime state | Consistent with this operation's time, object identity, and protocol. | Data is empty, the time does not belong to this operation, the protocol does not match, or the page shows waiting while the device has already acted. First checkpoint: verify the object identity and that tracking is enabled, then generate a new piece of data in FMQX and refresh. |
| Remaining Time- | How long remains before this real-time tracking session ends automatically. | Page runtime state | Consistent with this operation's time, object identity, and protocol. | Data is empty, the time does not belong to this operation, the protocol does not match, or the page shows waiting while the device has already acted. First checkpoint: verify the object identity and that tracking is enabled, then generate a new piece of data in FMQX and refresh. |
| Timeline Count- | The number of readable events aggregated for the current object. | Page runtime state | Consistent with this operation's time, object identity, and protocol. | Data is empty, the time does not belong to this operation, the protocol does not match, or the page shows waiting while the device has already acted. First checkpoint: verify the object identity and that tracking is enabled, then generate a new piece of data in FMQX and refresh. |
| Source Evidence- | Indicates which runtime source this conclusion is based on. | Page runtime state | Consistent with this operation's time, object identity, and protocol. | Data is empty, the time does not belong to this operation, the protocol does not match, or the page shows waiting while the device has already acted. First checkpoint: verify the object identity and that tracking is enabled, then generate a new piece of data in FMQX and refresh. |
| Key Issues- | The number of abnormal or identity issues that should be reviewed first. | Page runtime state | Consistent with this operation's time, object identity, and protocol. | Data is empty, the time does not belong to this operation, the protocol does not match, or the page shows waiting while the device has already acted. First checkpoint: verify the object identity and that tracking is enabled, then generate a new piece of data in FMQX and refresh. |
| Collection Mode- | Live means collecting; Standby means read-only access to existing evidence. | Page runtime state | Consistent with this operation's time, object identity, and protocol. | Data is empty, the time does not belong to this operation, the protocol does not match, or the page shows waiting while the device has already acted. First checkpoint: verify the object identity and that tracking is enabled, then generate a new piece of data in FMQX and refresh. |
| Read the Timeline | ||||
| Occurrence Time- | The time the event entered the tracking timeline, used to align with FMQX device time. | Page runtime state | Consistent with this operation's time, object identity, and protocol. | Data is empty, the time does not belong to this operation, the protocol does not match, or the page shows waiting while the device has already acted. First checkpoint: verify the object identity and that tracking is enabled, then generate a new piece of data in FMQX and refresh. |
| Stage- | Indicates whether the event is in the connect, report, parse, output, or recovery stage. | Page runtime state | Consistent with this operation's time, object identity, and protocol. | Data is empty, the time does not belong to this operation, the protocol does not match, or the page shows waiting while the device has already acted. First checkpoint: verify the object identity and that tracking is enabled, then generate a new piece of data in FMQX and refresh. |
| Event Type- | The stable type of the runtime raw event, used for precise location. | Page runtime state | Consistent with this operation's time, object identity, and protocol. | Data is empty, the time does not belong to this operation, the protocol does not match, or the page shows waiting while the device has already acted. First checkpoint: verify the object identity and that tracking is enabled, then generate a new piece of data in FMQX and refresh. |
| Flow Status- | Indicates whether downstream links have captured, are waiting for, or lack evidence. | Page runtime state | Consistent with this operation's time, object identity, and protocol. | Data is empty, the time does not belong to this operation, the protocol does not match, or the page shows waiting while the device has already acted. First checkpoint: verify the object identity and that tracking is enabled, then generate a new piece of data in FMQX and refresh. |
| Stage Filter- | Only changes the current list scope; does not delete evidence. | Page runtime state | Consistent with this operation's time, object identity, and protocol. | Data is empty, the time does not belong to this operation, the protocol does not match, or the page shows waiting while the device has already acted. First checkpoint: verify the object identity and that tracking is enabled, then generate a new piece of data in FMQX and refresh. |
| Verify Protocol Context | ||||
| Source Evidence- | Indicates which runtime source this conclusion is based on. | Page runtime state | Consistent with this operation's time, object identity, and protocol. | Data is empty, the time does not belong to this operation, the protocol does not match, or the page shows waiting while the device has already acted. First checkpoint: verify the object identity and that tracking is enabled, then generate a new piece of data in FMQX and refresh. |
| Protocol Context- | Modbus TCP does not use topic subscription; it relies on the TCP session, Unit ID, and the published polling plan. | Page runtime state | Consistent with this operation's time, object identity, and protocol. | Data is empty, the time does not belong to this operation, the protocol does not match, or the page shows waiting while the device has already acted. First checkpoint: verify the object identity and that tracking is enabled, then generate a new piece of data in FMQX and refresh. |
| Source Time- | The time the evidence was generated, used to verify it belongs to this operation. | Page runtime state | Consistent with this operation's time, object identity, and protocol. | Data is empty, the time does not belong to this operation, the protocol does not match, or the page shows waiting while the device has already acted. First checkpoint: verify the object identity and that tracking is enabled, then generate a new piece of data in FMQX and refresh. |
| View All Source Evidence- | Expands all sources of the current object without changing the runtime state. | Page runtime state | Consistent with this operation's time, object identity, and protocol. | Data is empty, the time does not belong to this operation, the protocol does not match, or the page shows waiting while the device has already acted. First checkpoint: verify the object identity and that tracking is enabled, then generate a new piece of data in FMQX and refresh. |
| Read Full Message Tracing | ||||
| Link Type- | Indicates whether the current comparison is between device reporting and MQ forwarding, or a device command or Modbus poll. | Modbus TCP Device ↔ FMQ | Consistent with this operation's time, object identity, and protocol. | Data is empty, the time does not belong to this operation, the protocol does not match, or the page shows waiting while the device has already acted. First checkpoint: verify the object identity and that tracking is enabled, then generate a new piece of data in FMQX and refresh. |
| Event Time- | The time the currently selected event occurred; should be close to the device-side send or reply time. | Modbus TCP Device ↔ FMQ | Consistent with this operation's time, object identity, and protocol. | Data is empty, the time does not belong to this operation, the protocol does not match, or the page shows waiting while the device has already acted. First checkpoint: verify the object identity and that tracking is enabled, then generate a new piece of data in FMQX and refresh. |
| Device Report Status- | Captured means the platform retained the raw message entering FMQ from the device; a non-report event does not mean communication failed. | Modbus TCP Device ↔ FMQ | Consistent with this operation's time, object identity, and protocol. | Data is empty, the time does not belong to this operation, the protocol does not match, or the page shows waiting while the device has already acted. First checkpoint: verify the object identity and that tracking is enabled, then generate a new piece of data in FMQX and refresh. |
| Platform Rule or Connector Status- | Indicates whether the current event found matching uplink rules and connector flow evidence. | Modbus TCP Device ↔ FMQ | Consistent with this operation's time, object identity, and protocol. | Data is empty, the time does not belong to this operation, the protocol does not match, or the page shows waiting while the device has already acted. First checkpoint: verify the object identity and that tracking is enabled, then generate a new piece of data in FMQX and refresh. |
| MQ Forwarding Status- | Forwarded means the connector has submitted; when waiting or not captured, continue checking rules and connectors. | Modbus TCP Device ↔ FMQ | Consistent with this operation's time, object identity, and protocol. | Data is empty, the time does not belong to this operation, the protocol does not match, or the page shows waiting while the device has already acted. First checkpoint: verify the object identity and that tracking is enabled, then generate a new piece of data in FMQX and refresh. |
| Link Conclusion- | A complete link only proves tracking has seen the device message and forwarding evidence; whether the business system consumed it must be confirmed separately. | Modbus TCP Device ↔ FMQ | Consistent with this operation's time, object identity, and protocol. | Data is empty, the time does not belong to this operation, the protocol does not match, or the page shows waiting while the device has already acted. First checkpoint: verify the object identity and that tracking is enabled, then generate a new piece of data in FMQX and refresh. |
| Device Protocol- | The protocol on the device report card; should match the current tracked object. | Modbus TCP Device ↔ FMQ | Consistent with this operation's time, object identity, and protocol. | Data is empty, the time does not belong to this operation, the protocol does not match, or the page shows waiting while the device has already acted. First checkpoint: verify the object identity and that tracking is enabled, then generate a new piece of data in FMQX and refresh. |
| Source Topic or Address- | MQTT shows the Topic, TCP shows the remote address, and Modbus TCP shows the polling endpoint or response clue. | Modbus TCP Device ↔ FMQ | Consistent with this operation's time, object identity, and protocol. | Data is empty, the time does not belong to this operation, the protocol does not match, or the page shows waiting while the device has already acted. First checkpoint: verify the object identity and that tracking is enabled, then generate a new piece of data in FMQX and refresh. |
| Device Event Type- | The raw event type recorded by the platform, used to distinguish connect, report, parse, and reply. | Modbus TCP Device ↔ FMQ | Consistent with this operation's time, object identity, and protocol. | Data is empty, the time does not belong to this operation, the protocol does not match, or the page shows waiting while the device has already acted. First checkpoint: verify the object identity and that tracking is enabled, then generate a new piece of data in FMQX and refresh. |
| Running Node- | The FMQ node that processed this message, used to troubleshoot cluster node differences. | Modbus TCP Device ↔ FMQ | Consistent with this operation's time, object identity, and protocol. | Data is empty, the time does not belong to this operation, the protocol does not match, or the page shows waiting while the device has already acted. First checkpoint: verify the object identity and that tracking is enabled, then generate a new piece of data in FMQX and refresh. |
| traceId- | The correlation identifier of the device-side event, used to cross-check with logs, rules, or downstream records. | Modbus TCP Device ↔ FMQ | Consistent with this operation's time, object identity, and protocol. | Data is empty, the time does not belong to this operation, the protocol does not match, or the page shows waiting while the device has already acted. First checkpoint: verify the object identity and that tracking is enabled, then generate a new piece of data in FMQX and refresh. |
| Device Raw Message- | The raw Payload or hexadecimal frame retained when the device entered FMQ; the basis for judging what the device actually sent. | Modbus TCP Device ↔ FMQ | Consistent with this operation's time, object identity, and protocol. | Data is empty, the time does not belong to this operation, the protocol does not match, or the page shows waiting while the device has already acted. First checkpoint: verify the object identity and that tracking is enabled, then generate a new piece of data in FMQX and refresh. |
| Output Target- | Indicates which connector or external target this uplink message is about to be delivered to. | Modbus TCP Device ↔ FMQ | Consistent with this operation's time, object identity, and protocol. | Data is empty, the time does not belong to this operation, the protocol does not match, or the page shows waiting while the device has already acted. First checkpoint: verify the object identity and that tracking is enabled, then generate a new piece of data in FMQX and refresh. |
| Delivery Address- | Shows the Topic, Exchange/RoutingKey, or other actual delivery address, used to verify the target selection. | Modbus TCP Device ↔ FMQ | Consistent with this operation's time, object identity, and protocol. | Data is empty, the time does not belong to this operation, the protocol does not match, or the page shows waiting while the device has already acted. First checkpoint: verify the object identity and that tracking is enabled, then generate a new piece of data in FMQX and refresh. |
| flowId- | The correlation identifier of one platform forwarding process, used to string processing stages into the same link. | Modbus TCP Device ↔ FMQ | Consistent with this operation's time, object identity, and protocol. | Data is empty, the time does not belong to this operation, the protocol does not match, or the page shows waiting while the device has already acted. First checkpoint: verify the object identity and that tracking is enabled, then generate a new piece of data in FMQX and refresh. |
| MQ Forwarded Message- | The message body handed to the connector after rule processing; can be compared with the device raw message for field changes. | Modbus TCP Device ↔ FMQ | Consistent with this operation's time, object identity, and protocol. | Data is empty, the time does not belong to this operation, the protocol does not match, or the page shows waiting while the device has already acted. First checkpoint: verify the object identity and that tracking is enabled, then generate a new piece of data in FMQX and refresh. |
| Forwarding Process and Duration- | When expanded, shows rule matching, action submission, and connector execution times by stage; on failure, find the first abnormal stage first. | Modbus TCP Device ↔ FMQ | Consistent with this operation's time, object identity, and protocol. | Data is empty, the time does not belong to this operation, the protocol does not match, or the page shows waiting while the device has already acted. First checkpoint: verify the object identity and that tracking is enabled, then generate a new piece of data in FMQX and refresh. |
| Technical Fields- | When expanded, lists message, node, exception, and correlation identifiers for implementation and R&D to locate further. | Modbus TCP Device ↔ FMQ | Consistent with this operation's time, object identity, and protocol. | Data is empty, the time does not belong to this operation, the protocol does not match, or the page shows waiting while the device has already acted. First checkpoint: verify the object identity and that tracking is enabled, then generate a new piece of data in FMQX and refresh. |
| Understand Diagnosis and Protocol Actions | ||||
| Diagnosis Conclusion- | A plain-language conclusion about the currently selected event. | Page runtime state | Consistent with this operation's time, object identity, and protocol. | Data is empty, the time does not belong to this operation, the protocol does not match, or the page shows waiting while the device has already acted. First checkpoint: verify the object identity and that tracking is enabled, then generate a new piece of data in FMQX and refresh. |
| Possible Causes- | Troubleshooting directions listed by the platform from existing evidence; does not mean the root cause is confirmed. | Page runtime state | Consistent with this operation's time, object identity, and protocol. | Data is empty, the time does not belong to this operation, the protocol does not match, or the page shows waiting while the device has already acted. First checkpoint: verify the object identity and that tracking is enabled, then generate a new piece of data in FMQX and refresh. |
| Suggested Actions- | The next step matching the current event, protocol, and session context. | Page runtime state | Consistent with this operation's time, object identity, and protocol. | Data is empty, the time does not belong to this operation, the protocol does not match, or the page shows waiting while the device has already acted. First checkpoint: verify the object identity and that tracking is enabled, then generate a new piece of data in FMQX and refresh. |
| Action Conditions- | Reschedule only rearranges the plan; Run One Round Now enqueues immediately; pause does not disconnect the device; Clear Circuit Breaker should be used after the endpoint recovers. | Page runtime state | Consistent with this operation's time, object identity, and protocol. | Data is empty, the time does not belong to this operation, the protocol does not match, or the page shows waiting while the device has already acted. First checkpoint: verify the object identity and that tracking is enabled, then generate a new piece of data in FMQX and refresh. |
| Identify Abnormal and Recovery Events | ||||
| Abnormality Time- | The time the fault or disconnection was recorded. | Page runtime state | Consistent with this operation's time, object identity, and protocol. | Data is empty, the time does not belong to this operation, the protocol does not match, or the page shows waiting while the device has already acted. First checkpoint: verify the object identity and that tracking is enabled, then generate a new piece of data in FMQX and refresh. |
| Abnormality Stage- | Indicates whether the failure occurred in connect, send, waiting for reply, parse, or output. | Page runtime state | Consistent with this operation's time, object identity, and protocol. | Data is empty, the time does not belong to this operation, the protocol does not match, or the page shows waiting while the device has already acted. First checkpoint: verify the object identity and that tracking is enabled, then generate a new piece of data in FMQX and refresh. |
| Abnormality Cause- | The observable error or offline cause this time. | Page runtime state | Consistent with this operation's time, object identity, and protocol. | Data is empty, the time does not belong to this operation, the protocol does not match, or the page shows waiting while the device has already acted. First checkpoint: verify the object identity and that tracking is enabled, then generate a new piece of data in FMQX and refresh. |
| New Events After Recovery- | After the slave disconnects, timeout and circuit breaking appear; after restoring the same endpoint, clearing the circuit breaker, and rescheduling, new replies and parsing appear again. | Page runtime state | Consistent with this operation's time, object identity, and protocol. | Data is empty, the time does not belong to this operation, the protocol does not match, or the page shows waiting while the device has already acted. First checkpoint: verify the object identity and that tracking is enabled, then generate a new piece of data in FMQX and refresh. |
| Confirm Recovery Status | ||||
| Current Conclusion- | The current judgment formed from the latest evidence. | Page runtime state | Consistent with this operation's time, object identity, and protocol. | Data is empty, the time does not belong to this operation, the protocol does not match, or the page shows waiting while the device has already acted. First checkpoint: verify the object identity and that tracking is enabled, then generate a new piece of data in FMQX and refresh. |
| Historical Abnormalities- | Old fault records that are retained; the presence of historical abnormalities does not mean current communication still fails. | Page runtime state | Old records may remain; new post-recovery evidence should also appear. | Data is empty, the time does not belong to this operation, the protocol does not match, or the page shows waiting while the device has already acted. First checkpoint: verify the object identity and that tracking is enabled, then generate a new piece of data in FMQX and refresh. |
| Recovery Signal- | After the slave disconnects, timeout and circuit breaking appear; after restoring the same endpoint, clearing the circuit breaker, and rescheduling, new replies and parsing appear again. | Page runtime state | Consistent with this operation's time, object identity, and protocol. | Data is empty, the time does not belong to this operation, the protocol does not match, or the page shows waiting while the device has already acted. First checkpoint: verify the object identity and that tracking is enabled, then generate a new piece of data in FMQX and refresh. |
| Next Checkpoint- | The location recommended to check first when current evidence is insufficient. | Page runtime state | Consistent with this operation's time, object identity, and protocol. | Data is empty, the time does not belong to this operation, the protocol does not match, or the page shows waiting while the device has already acted. First checkpoint: verify the object identity and that tracking is enabled, then generate a new piece of data in FMQX and refresh. |
FMQX Modbus TCP Session
Full Reference
| Field/Control | Purpose | Default/Recommended/Example | Options | Effect | Effective Conditions |
|---|---|---|---|---|---|
| Connect/Reconnect | Establishes a real device session of the current protocol in FMQX. | Default: — Recommended: — Example: — | N/A | Establishes a real device session of the current protocol in FMQX. | Scope: current tracked object · Publish: not required · Restart: not required · Reconnect: not required |
| Slave Auto-Reply | FMQX replies to real Modbus requests based on register data. | Default: — Recommended: — Example: — | N/A | FMQX replies to real Modbus requests based on register data. | Scope: current tracked object · Publish: not required · Restart: not required · Reconnect: not required |
Device Tracking Workbench
Full Reference
| Field/Control | Purpose | Default/Recommended/Example | Options | Effect | Effective Conditions |
|---|---|---|---|---|---|
| Open Tracked Object | Parses the input identifier and enters the corresponding tracking details. | Default: — Recommended: — Example: — | N/A | Parses the input identifier and enters the corresponding tracking details. | Scope: current tracked object · Publish: not required · Restart: not required · Reconnect: not required |
| Status/Protocol Filter | Narrows the workbench list scope without changing the tracking state. | Default: — Recommended: — Example: — | All: All; shows only the All scope. Not Started: Not Started; shows only the Not Started scope. Tracking: Tracking; shows only the Tracking scope. Ended: Ended; shows only the Ended scope. Modbus TCP: Modbus TCP; shows only the Modbus TCP scope. | Narrows the workbench list scope without changing the tracking state. | Scope: current tracked object · Publish: not required · Restart: not required · Reconnect: not required |
| Delete | Removes the current object from the workbench; an active object also has its tracking closed. | Default: — Recommended: — Example: — | N/A | Removes the current object from the workbench; an active object also has its tracking closed. | Scope: current tracked object · Publish: not required · Restart: not required · Reconnect: not required |
| Clear List | Clears the workbench objects and closes any tracking still active among them. | Default: — Recommended: — Example: — | N/A | Clears the workbench objects and closes any tracking still active among them. | Scope: current tracked object · Publish: not required · Restart: not required · Reconnect: not required |
| View Details | Opens the tracking details of the current object. | Default: — Recommended: — Example: — | N/A | Opens the tracking details of the current object. | Scope: current tracked object · Publish: not required · Restart: not required · Reconnect: not required |
Modbus TCP Tracking Details
Full Reference
| Field/Control | Purpose | Default/Recommended/Example | Options | Effect | Effective Conditions |
|---|---|---|---|---|---|
| Back to Workbench | Returns to the Device Tracking workbench. | Default: — Recommended: — Example: — | N/A | Returns to the Device Tracking workbench. | Scope: current tracked object · Publish: not required · Restart: not required · Reconnect: not required |
| Enable/Disable Tracking | Starts ten minutes of real-time collection or stops further collection; already displayed evidence is retained. | Default: — Recommended: — Example: — | N/A | Starts ten minutes of real-time collection or stops further collection; already displayed evidence is retained. | Scope: current tracked object · Publish: not required · Restart: not required · Reconnect: not required |
| Download Evidence Package | Downloads the current object's text evidence for offline troubleshooting. | Default: — Recommended: — Example: — | N/A | Downloads the current object's text evidence for offline troubleshooting. | Scope: current tracked object · Publish: not required · Restart: not required · Reconnect: not required |
| Refresh | Immediately re-reads the current object's latest status and evidence. | Default: — Recommended: — Example: — | N/A | Immediately re-reads the current object's latest status and evidence. | Scope: current tracked object · Publish: not required · Restart: not required · Reconnect: not required |
| AI Deep Tracking | Currently a reserved entry; does not mean an AI diagnosis has been executed. | Default: — Recommended: — Example: — | N/A | Currently a reserved entry; does not mean an AI diagnosis has been executed. | Scope: current tracked object · Publish: not required · Restart: not required · Reconnect: not required |
| Details Page Global Search | Switches the tracked object after entering another object identifier. | Default: — Recommended: — Example: — | N/A | Switches the tracked object after entering another object identifier. | Scope: current tracked object · Publish: not required · Restart: not required · Reconnect: not required |
| Timeline Filter | Narrows the timeline scope by stage or polling state. | Default: — Recommended: — Example: — | All Polls: All Polls; shows only the All Polls scope. Abnormal: Abnormal; shows only the Abnormal scope. Awaiting Reply: Awaiting Reply; shows only the Awaiting Reply scope. Parsed: Parsed; shows only the Parsed scope. Output: Output; shows only the Output scope. | Narrows the timeline scope by stage or polling state. | Scope: current tracked object · Publish: not required · Restart: not required · Reconnect: not required |
| Event Evidence | Views the source and context of the selected event. | Default: — Recommended: — Example: — | N/A | Views the source and context of the selected event. | Scope: current tracked object · Publish: not required · Restart: not required · Reconnect: not required |
| Message Tracing | Views the raw message, flow direction, and processing layers. | Default: — Recommended: — Example: — | N/A | Views the raw message, flow direction, and processing layers. | Scope: current tracked object · Publish: not required · Restart: not required · Reconnect: not required |
| Comprehensive Diagnosis | Views the conclusion, causes, and suggested actions. | Default: — Recommended: — Example: — | N/A | Views the conclusion, causes, and suggested actions. | Scope: current tracked object · Publish: not required · Restart: not required · Reconnect: not required |
| View All Source Evidence | Expands all source evidence of the current object. | Default: — Recommended: — Example: — | N/A | Expands all source evidence of the current object. | Scope: current tracked object · Publish: not required · Restart: not required · Reconnect: not required |
| Trigger Reschedule | Rearranges the current device's polling plan. | Default: — Recommended: — Example: — | N/A | Rearranges the current device's polling plan. | Scope: current tracked object · Publish: not required · Restart: not required · Reconnect: not required |
| Run One Round Now | Immediately enqueues all published polling commands into the execution queue; also available while paused. | Default: — Recommended: — Example: — | N/A | Immediately enqueues all published polling commands into the execution queue; also available while paused. | Scope: current tracked object · Publish: not required · Restart: not required · Reconnect: not required |
| Pause/Resume Polling | Pause only removes the periodic schedule and does not disconnect the slave; after resuming, polling follows the plan again. | Default: — Recommended: — Example: — | N/A | Pause only removes the periodic schedule and does not disconnect the slave; after resuming, polling follows the plan again. | Scope: current tracked object · Publish: not required · Restart: not required · Reconnect: not required |
| Clear Circuit Breaker | Clears the current circuit-breaking protection after the endpoint recovers, then reschedules to verify. | Default: — Recommended: — Example: — | N/A | Clears the current circuit-breaking protection after the endpoint recovers, then reschedules to verify. | Scope: current tracked object · Publish: not required · Restart: not required · Reconnect: not required |
FAQ
How do I troubleshoot abnormal Modbus TCP polling with Device Tracking?
Keep an FMQX Modbus TCP slave online and verify each polling round's request, response, and message parsing result in the Tracking Details timeline; after the slave disconnects, timeout and circuit breaking appear, and after restoring the same endpoint, clearing the circuit breaker, and rescheduling, new replies and parsing should appear again.
Does "Pause Polling" in tracking disconnect the device?
No. Pause only removes the periodic schedule and does not disconnect the slave; "Run One Round Now" is also available while paused to manually trigger all published polling commands, and after resuming, polling follows the plan again.
What should I do after circuit breaking occurs on Modbus TCP?
Circuit breaking is the platform's protection for abnormal endpoints; use "Clear Circuit Breaker" after the endpoint recovers, then reschedule to verify — seeing new replies and parsing means recovery.
Production Operation Notice
The screenshots and examples illustrate operation locations and judgment methods and do not represent the current production state. Before publishing, starting/stopping, rebinding, retrying, or deleting, confirm the target environment, scope of impact, and recovery plan, and have authorized personnel perform the operation.
Fengxin IoT (FastBee) · FMQ Operation Manual