Product · Guide
Keep data flowing when the network drops.
Networks between plants and the cloud fail. MaestroHub runs next to your machines and keeps a buffer on disk for every destination, so an outage becomes a pause, not a gap in your data.
Try it
Pull the cable.
A simulation of what MaestroHub does. Four machines send a value every half second to a historian on site and three destinations in the cloud.
Your plant network
- PLC
- CNC
- Robot
- Sensor
0 values made
MaestroHub0 waiting on diskone buffer per cloud destinationCloud
Everything flows. Nothing is buffered, because nothing has failed.
How it works
One buffer per destination
Live3.1
A buffer exists for each pipeline and destination pair. A cloud warehouse going offline does not stop the historian, the broker or the dashboards.
No overhead when all is well
Live3.1
While a destination is reachable, values go straight through. A buffer appears only when something fails, and retires itself once it is empty.
On disk, survives restarts
Live3.1
What was waiting before a restart or a crash is still waiting after it. A power loss can cost what was acknowledged in the last second.
An outage is held, not counted
Livefrom 3.1
While a destination cannot be reached, its buffer holds every write for as long as the outage lasts and the disk has room. Nothing expires by age unless you set a retention age, and an outage uses up no attempts. The buffer checks whether the destination is back with a request that carries no data, so waiting creates no copies.
Only a refusal is counted
Livefrom 3.1
A write counts against itself only when the destination refuses it while taking others. After 10 counted refusals, with growing waits, it goes to Failed messages with the destination's own reason, grouped by cause; on an output set to In order, the buffer stops at it until you decide. Fix the cause, replay one to test, then the rest.
One write, one outcome
Livefrom 3.1
Delivered, refused, or possibly delivered when no answer came. A possibly delivered write is never resent on a timer, and replaying it asks you to confirm. Over plain TCP, where nothing acknowledges a write, it is sent, not confirmed.
A promise per destination
Livefrom 3.1
Every buffered write has a write key, the same on every resend and replay, and most connectors pass it to the destination. Destinations that drop repeats get effectively once. Others get at least once: at most one extra copy, only of a write that was on its way when the link was cut, MaestroHub crashed or restarted, or its buffer moved to another replica. UDP is not buffered.
Proof, before and after
Livefrom 3.1
Every outage gets a report whose sum must close: everything held is delivered, sent and not confirmed, in Failed messages, lost or still waiting. Run a drill on one of your own outputs, see in advance how long an outage you can hold, and get a warning while there is still room.
You can pull the brake
Live3.1
Pause a buffer, stop it accepting new messages, or discard what it holds, from the same page.
The full rules are in the Store & Forward documentation. Why an outage should hold and only the destination decides a write's fate: Delivered must mean delivered.
Questions
How do I keep factory data flowing when the network to the cloud drops?
Buffer at the edge, per destination, on disk, and deliver automatically when the link returns. MaestroHub runs next to the machines and keeps a separate on-disk buffer for every destination, so a cloud outage only pauses that destination. When the link is back, the buffer drains without anyone touching the pipeline, and the records produced during the outage arrive, as long as their buffer had room for them. If room runs out, every record dropped is counted and shown. From release 3.1 a buffer has no size of its own: it holds until the shared disk pool runs short.
What is store and forward?
Store and forward means keeping data locally while a destination is unreachable and sending it on once it is reachable again. It turns an outage into a pause instead of a gap in the data.
Does a long outage use up retries, or expire buffered data?
From release 3.1, no. An outage is held for as long as it lasts and the disk has room: nothing expires by age unless you set a retention age, and no attempt is used up. Only a write the destination refuses while it takes others is counted. After 10 counted refusals it goes to Failed messages with the reason, ready to replay, or, on an output set to In order, the buffer stops at it until you decide. In 3.0, temporary errors such as timeouts use up a write's attempts, 10 by default, while a stopped or reconnecting connection does not.
Can a retry deliver a reading twice?
From release 3.1, retries and outage checks add no copies: the buffer checks the destination with a request that carries no data, and a write with no answer is never resent on a timer. Destinations that drop repeats by the write key get effectively once. Elsewhere the promise is at least once, with at most one extra copy of a write that was on its way when the link was cut, MaestroHub crashed or restarted, or its buffer moved to another replica. On most connectors that copy carries the same write key, so a consumer can drop it.
Can I test an outage before it happens?
Yes. The Store & Forward page in MaestroHub has a How it works guide with an outage simulator: publish messages, take a destination offline, drop a bad message, and watch the buffer absorb the outage and drain. From release 3.1 you can also run a drill on one of your own outputs and read its outage report.
Does order matter for setpoints and commands?
Yes, and you choose per output. In order holds everything behind a refused message until an operator decides, so a newer value never overtakes an older one, which is right for setpoints. Any order lets newer readings keep flowing past a refused one, which is right for timestamped telemetry. You set it per output.
Is MaestroHub a long-term historian?
No. It keeps an operational window by design (the same for every licence: one day by default, and from release 3.0 each topic keeps 1, 7, 14 or 32 days) and sends long-term history to your own system of record. Store and forward protects that delivery.
Pull the cable yourself.
The outage simulator is in the free trial. In the six-week pilot we take a destination offline on your own system and watch it drain when it comes back.