The Missing Layer
Here is the IoT stack as it actually exists in production today:
Siemens S7-1500 / Rockwell Allen-Bradley / Schneider Modicon /
Omron Sysmac / ABB AC500 / Beckhoff TwinCAT / Particle Boron /
Honeywell / Johnson Controls / Dexcom / Masimo / Philips
↓
MQTT / OPC UA / Modbus / BACnet / Zigbee / Matter / Sparkplug B
↓
HiveMQ / EMQX / Mosquitto / AWS IoT Core / Azure IoT Hub /
Google Cloud IoT / IBM Watson IoT / Cirrus Link Chariot / Solace PubSub+
↓
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
[ MISSING ]
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
↓
AVEVA PI / Inductive Automation Ignition / Wonderware /
Rockwell FactoryTalk / Epic / Cerner / Samsara / Geotab
↓
Grafana / PagerDuty / Azure Stream Analytics /
AWS IoT Analytics / C3.ai / Palantir / MES / BMS
Every platform in that stack is doing exactly what it was designed to do. The Siemens S7-1500 is generating accurate readings. HiveMQ is delivering every message. Ignition is storing every event. Grafana is displaying exactly what it received.
Your device is still showing offline when it has been online for four minutes.
The gap between the broker and the historian — the blank space in that diagram — is not an oversight by any of these vendors. AWS IoT Core was not designed to arbitrate conflicting state. AVEVA PI was not designed to question the ordering of the events it receives. Grafana was not designed to distinguish between a state that reflects physical reality and a state that reflects event arrival order. Each of these platforms does its job correctly and hands the data to the next layer with complete confidence.
Nobody owns the gap. Until now.
Siemens S7-1500 / Rockwell Allen-Bradley / Schneider Modicon /
Omron Sysmac / ABB AC500 / Beckhoff TwinCAT / Particle Boron /
Honeywell / Johnson Controls / Dexcom / Masimo / Philips
↓
MQTT / OPC UA / Modbus / BACnet / Zigbee / Matter / Sparkplug B
↓
HiveMQ / EMQX / Mosquitto / AWS IoT Core / Azure IoT Hub /
Google Cloud IoT / IBM Watson IoT / Cirrus Link Chariot / Solace PubSub+
↓
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
S I G N A L C E N D
Multi-Signal State Arbitration
One POST. 47ms. One authoritative verdict.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
↓
AVEVA PI / Inductive Automation Ignition / Wonderware /
Rockwell FactoryTalk / Epic / Cerner / Samsara / Geotab
↓
Grafana / PagerDuty / Azure Stream Analytics /
AWS IoT Analytics / C3.ai / Palantir / MES / BMS
Why the Gap Exists — and Why Every Platform Above It Is Blameless
Events are generated at the edge in one order. They arrive at the broker in a different order.
This is not a bug in HiveMQ. It is not a misconfiguration in AWS IoT Core. It is not a firmware issue in the Siemens S7-1500 or the Particle Boron or the Dexcom G7. It is a structural property of every distributed network ever built — documented, understood, and accepted as a foundational constraint since the first packet was routed across ARPANET.
MQTT's Quality of Service levels — QoS 0, QoS 1, QoS 2 — govern delivery guarantees. Not one of them governs delivery order. Cirrus Link's Sparkplug B specification adds sequence numbers to MQTT payloads specifically to help consumers detect out-of-order delivery. It does not tell them what to do about it. OPC UA's session model provides far more deterministic ordering than MQTT in controlled environments — but the moment an OPC UA gateway touches a cloud broker, or a Schneider Modicon talks through an EMQX cluster with partitioned consumers, the ordering guarantees that OPC UA provides within the control network do not survive the handoff.
The Rockwell Allen-Bradley ControlLogix knows exactly what state the device is in. The FactoryTalk Historian stores exactly what it receives from the broker. Neither of them has visibility into the 340-millisecond window between a device dropping and reconnecting — the window where a disconnect event and a reconnect event are both in transit simultaneously, racing toward the broker in an order that has nothing to do with the order they were generated.
When the disconnect event wins that race and arrives last, HiveMQ delivers it correctly. AWS IoT Core routes it correctly. Ignition stores it correctly. Grafana displays it correctly. PagerDuty pages someone correctly.
The device was never offline.
In an analysis of 1.3 million real device state resolution events, this pattern accounted for 34% of all offline classifications in standard event-driven IoT architectures. Not edge cases. Not misconfigured deployments. Thirty-four percent of the time a device appeared offline, it was already back online before the offline event was processed.
SignalCend resolves this. Not by modifying HiveMQ. Not by replacing AWS IoT Core. Not by touching the Siemens PLC or the Ignition historian. By sitting between the broker and everything downstream and answering the question none of them were designed to answer: given everything available — device timestamp, server arrival time, RF signal quality, sequence continuity, reconnect window context — what actually happened?
The Integration
This is what it looks like for an engineer integrating SignalCend for the first time — whether their stack runs on AWS IoT Core, Azure IoT Hub, HiveMQ, or a Mosquitto edge broker sitting next to an Ignition gateway on a factory floor.
In production, the signing and resolution happen automatically inside a single client call. No manual steps. No workflow to manage. The integrator writes the following once and the arbitration layer is live.
// 1. Sign the payload — automatic in production, shown here for clarity
POST /v1/sign
{
"api_key": "your-api-key",
"state": {
"device_id": device.id,
"status": device.reported_status,
"timestamp": device.event_timestamp,
"signal_strength": device.rssi
}
}
→ { "signature": "a3f2c1d4e5b6..." }
// 2. Resolve authoritative state
POST /v1/resolve
X-Signature: a3f2c1d4e5b6...
{
"api_key": "your-api-key",
"state": {
"device_id": device.id,
"status": device.reported_status,
"timestamp": device.event_timestamp,
"signal_strength": device.rssi
}
}
→ {
"authoritative_status": "online",
"recommended_action": "ACT",
"confidence": 0.95
}
What Those Three Values Are Worth
authoritative_status — what actually happened, after arbitration
recommended_action — ACT, CONFIRM, or LOG_ONLY
confidence — a float between 0.20 and 1.0
The engineer who writes those lines is not writing a utility function. They are installing the layer that every platform upstream and downstream of SignalCend — HiveMQ, AWS IoT Core, Ignition, AVEVA PI, Grafana, PagerDuty — has always assumed was someone else's responsibility.
It was not someone else's responsibility. It was nobody's responsibility. It is now four lines of HTTP and one POST call.
Here is what those four lines recover:
1,000 devices → $47,000 per year
10,000 devices → $470,000 per year
100,000 devices → $4.7 million per year
1,000,000 devices → $47 million per year
A 12-month production case study documented $4.2 million in recovered operational value from a single integration. The arithmetic is the same regardless of whether the devices are Siemens PLCs reporting through HiveMQ into AVEVA PI, or Particle Boron sensors reporting through AWS IoT Core into a Samsara analytics backend, or Dexcom CGMs reporting through Azure IoT Hub into an Epic clinical data repository.
The gap is industry-agnostic. The recovery is industry-agnostic. The integration is four lines of HTTP.
SignalCend Across Every Industry — Same Layer, Different Stakes
Industrial and Manufacturing
A Siemens S7-1500 on an automotive line feeds HiveMQ through Sparkplug B. HiveMQ feeds Inductive Automation Ignition. Ignition feeds AVEVA PI. AVEVA PI feeds the MES. SignalCend sits between HiveMQ and Ignition and ensures that the state the MES acts on reflects what the Siemens PLC actually reported — not what order the events arrived at the broker.
A Rockwell Allen-Bradley ControlLogix on an adjacent line feeds Cirrus Link Chariot through OPC UA. Chariot feeds FactoryTalk Historian. SignalCend sits between Chariot and FactoryTalk and provides the same arbitration on the same boundary. Both lines. One SignalCend integration. One arbitration layer across the entire plant floor.
When Schneider Electric's Modicon M580 manages a chemical process through EcoStruxure and that process generates a reconnect storm during a scheduled maintenance window — 400 devices simultaneously dropping and reconnecting as a network switch reboots — SignalCend resolves 400 independent arbitration verdicts in a single batch call before a single false offline event reaches the historian, the dashboard, or the alarm management system.
Healthcare IoT
A Philips IntelliVue patient monitor in a hospital ICU feeds Azure IoT Hub through MQTT. Azure IoT Hub feeds a Cerner clinical data repository. SignalCend sits between Azure IoT Hub and Cerner and ensures that a false offline classification generated by a reconnect event arriving in the wrong order never reaches the clinical decision support system, never fires a nursing alert, and never generates a documentation entry in the patient record.
A Masimo pulse oximeter generating continuous SpO2 telemetry through AWS IoT Core into an Epic repository. A Dexcom G7 continuous glucose monitor feeding real-time readings through a cellular gateway into a hospital analytics platform. A Medtronic implantable cardiac device transmitting through a bedside communicator into a remote monitoring system. Every one of these deployments shares the same broker architecture and the same ordering vulnerability. SignalCend sits at the same boundary in all of them — between the broker and the clinical data store — and provides the same arbitrated ground truth before any clinical system acts on it.
In healthcare, the unit cost of a false critical alert is not $47 in engineering time. It is a nursing response, a physician notification, a potential care interruption, and a persistent documentation burden. The SignalCend integration is the same four lines of HTTP. The return on those four lines is not the same arithmetic.
Smart Buildings and Energy
A Honeywell thermostat, a Johnson Controls HVAC controller, and a Lutron lighting system all feed a Mosquitto edge broker in a commercial building. That broker feeds a Siemens Desigo CC building management system. SignalCend sits between Mosquitto and Desigo CC and ensures that the energy optimization logic in the BMS acts on arbitrated state rather than raw events. Schneider Electric's EcoStruxure cannot hit its efficiency targets when the occupancy sensor data driving its algorithms contains 23% false positives. Johnson Controls' OpenBlue platform cannot optimize building performance on corrupted telemetry. SignalCend provides the arbitrated input layer that both platforms need and neither provides.
Logistics and Fleet
A Samsara GPS tracker on a delivery vehicle feeds EMQX through MQTT. EMQX feeds a cloud analytics platform. Every time the vehicle enters a tunnel, exits cellular coverage, or passes through a network handoff boundary, the broker receives a disconnect event and a reconnect event in an order that has nothing to do with which happened first. Geotab, CalAmp, and Verizon Connect fleet systems share the same architecture. SignalCend sits between the broker and the analytics backend and resolves the reconnect storm that every fleet generates every day across every route with connectivity gaps.
Consumer IoT
An Amazon Alexa ecosystem running Philips Hue lighting, a Ring security camera, and an August smart lock through AWS IoT Core. A Google Home environment running Nest thermostats and Honeywell sensors through Google Cloud IoT. A Samsung SmartThings hub managing Zigbee devices through an MQTT bridge into a cloud backend. An Apple HomeKit environment running Thread-connected sensors through a HomePod hub. A Home Assistant installation managing a mixed fleet of Z-Wave, Zigbee, and MQTT devices through Mosquitto.
Every one of these environments generates ghost offline events. Every one of them fires false automations on state that never existed in the physical world. SignalCend sits between the broker and the application layer in all of them — providing the same arbitrated state verdict that, in a smart home context, is the difference between an automation that fires correctly and a notification that wakes someone at 3am for a device that reconnected before the alert was generated.
Domain Context Intelligence — The Capability the Stack Assumed It Already Had
HiveMQ routes events. AWS IoT Core ingests them. Ignition stores them. Grafana displays them. None of them know the difference between an expected RF dip during a Particle Boron cellular reconnect and a genuine signal anomaly on a Honeywell building sensor.
Both events produce identical raw readings at the broker. Both arrive with weak RF signal strength. Both have slightly misaligned timestamps. From HiveMQ's perspective they are indistinguishable. From AWS IoT Core's perspective they are indistinguishable. From Ignition's perspective they are indistinguishable.
SignalCend distinguishes them.
The reconnect boundary context — the sequence of events, the timing relative to the reconnect window, the session history for this device — changes the interpretation of the same raw signal reading entirely. An RF dip during a reconnect is expected behavior. The same RF dip on a stable device with no reconnect context is an anomaly that warrants a CONFIRM recommendation before any downstream system acts on it.
This is domain context intelligence. It is the capability that AWS IoT Core assumed Ignition had. That Ignition assumed the MES had. That the MES assumed the alerting system had. That the alerting system assumed someone, somewhere, had already handled.
Nobody had handled it.
SignalCend handles it. Between the broker and everything downstream. In 47 milliseconds. Without touching HiveMQ. Without touching Ignition. Without touching AVEVA PI or FactoryTalk or Grafana or PagerDuty or Epic or Cerner or Samsara or any other platform in the stack.
The integration is four lines of HTTP.
The recovery is $47,000 per 1,000 devices per year.
The stack that needed this layer has been running without it since the first MQTT broker was deployed.
signalcend.com — Run 1,000 resolutions 100% FREE. No card required. No sign-up.
Top comments (0)