Developers

Connection health

What the platform does when a connection degrades, what it does not do, and how a site works back from a flag to the break that caused it.

What connection health monitoring does

Connection health monitoring watches each connection continuously and flags a drop before a module works from stale data. It runs across everything the Integration Hub reaches, which includes site telemetry arriving over MQTT and the business systems reached over the other protocols.

A flag is a statement about the connection, not about the machine. It says data stopped arriving on a path. What caused it to stop is a separate question, and it is almost always answered somewhere other than the platform.

Stale data is the failure mode

The failure mode of an operational platform is rarely a loud error. It is a screen that still shows a number after the machine behind it stopped reporting.

A module cannot tell an idle machine from a machine that stopped publishing. Idle is a legitimate equipment state. A machine sitting between jobs reports a counter that is not moving and a state that is not changing. A machine whose connection died reports the last thing it ever said, forever, and it looks identical.

Everything downstream inherits that ambiguity. A counter that stopped moving looks like a line that stopped running. A chart recorder run that opened when an asset went to Running stays open, because the state change that would have completed it never arrived. Availability, utilization and anything else calculated from a state enum are computed from a value that is no longer being asserted.

Connection health is what separates the two cases. Without it, the difference between quiet and dead is invisible.

Restoring a connection is work at the source

The flag tells you a connection is down. Restoring it is work at the source, and for site telemetry that means somewhere between a machine and the collection hub.

Walk the path in the order it runs. Equipment exposes its signals. Ignition on site collects them over OPC UA, Modbus or BACnet. The MQTT Transmission module publishes the collected tags outbound to the mode40 cloud broker. The break sits at one of those handoffs, and the earlier one is fine, the later one is where to look.

One rule catches a large share of them: only tags under the transmitter’s tag provider publish. A tag that lives anywhere else in the Gateway is invisible to the platform no matter how healthy it looks in Ignition. Connecting a site has the full setup and the topic structure.

What is not specified

Nothing below is documented.

Reconnect behaviour
Not specified. What the transmitter does after a drop, how often it retries, and how long it keeps trying are not documented.
Backfill
Not specified. Whether data produced during an outage is replayed once the connection returns is not documented.
Store and forward
Not specified. Whether readings are buffered on site during an outage, and what happens to them if they are not, is not documented.

What the documentation does say is that the client should handle transmission failures gracefully, with mechanisms in place to retry sending data or to log errors. It places the requirement on your client and describes no platform behaviour behind it. If an outage-recovery guarantee is a condition of your deployment, get it answered in writing during implementation. Do not read the absence above as a promise in either direction.

Troubleshooting

Each symptom below has a documented cause. Start at the row that matches what you are seeing.

Symptom Likely cause Where to look
A machine is clearly connected in Ignition but never appears downstream Its tags are not under the tag provider the transmitter is bound to Ignition Gateway, Configuration, Tags, Realtime, and the Tag Provider set on the transmitter
An asset appears twice, one of them nearly empty A segment of the topic path is spelled or capitalized two ways, so the platform is addressing two assets The topic the transmitter publishes on, against the agreed hierarchy in the asset model
A configured channel records nothing while the asset is running The configured tag path is not an exact match for the topic the control system publishes The MQTT Tag Path on the channel, in Admin Configuration, Site Configuration, Assets
Readings arrive but every value is wrong by a consistent amount The unit configured on the channel is not the unit the control system is sending The channel’s Unit, which must match what SCADA sends
A device on the floor is not publishing at all It is not reachable by the collection hub over OPC UA, Modbus or BACnet, or it speaks none of them The device’s own interface first, then the Ignition connection to it
The connection drops and returns repeatedly The outbound session between the transmitter and the cloud broker is not holding Outbound internet from the host Ignition runs on, and the firewall and VLAN posture around it
The transmitter cannot authenticate to the broker The certificate or credential issued for the site is missing, wrong, or has reached the end of its life MQTT Transmission, Settings, Servers tab, against the certificate and credential mode40 issued for that site
A chart recorder run stays active long after the machine stopped The asset’s state stopped updating rather than moving to Idle, so nothing completed the run Connection health for that asset, then the State tag itself. Digital Process Records covers the run lifecycle

What a site should settle in advance

Certificate lifecycle and naming are both avoidable at implementation.

Certificate lifecycle. mode40 issues the certificate and credential the transmitter authenticates with, and provisioning is manual per site. Where a site has a certificate lifecycle policy of its own, raise it during implementation rather than at renewal.

Naming, once. Duplicate assets and dead channel bindings are both naming failures that present as connectivity problems. Settling the hierarchy before the first transmitter goes live removes the whole class. Asset model covers it.

What does not exist

There is no status page. Availability is a contractual term, 99.5% measured monthly, excluding scheduled downtime and force majeure, and it is the only availability number that exists.

Support hours, channels, severity levels and response targets are not defined as a standard tier. The support model is set per engagement, so settle yours in the agreement rather than assuming one. Division of responsibilities has the rest of the split, and Protocols covers what the Integration Hub reaches.