Platform · Integrations
Deliver to the systems you already run.
Modelled data goes out to databases, message brokers, cloud services and business systems, per target, with the transport strategy each one needs, and a delivery record you can check.
- Delivers to
- 15+ destination systems: databases, message brokers, cloud IoT services and REST endpoints
- Per target
- Its own strategy: pass-through on every read, or only on change
- Reliability
- Queued at the gateway while a target is unreachable and written in order when it returns
- Visibility
- Status, last success, last failure and last error per target, in the product
From a signal to a target
Modelled once, sent to each system the way it needs.
A target says what it receives and how; the gateway holds the data while the target is away.
- Signal MFB_RTM_L1_FILLER · GoodCount 74,414 Modelled once, in the namespace
- Target InfluxDB · on change Each target has its own strategy
- Gateway Queued while the target is down Written in order when it returns
- At the target tesis,deviceName=MFB_RTM_L1_FILLER GoodCount=74414i A point at the time it was read
In the product
Know what was sent, and what arrived.
Every target, and how it is doing
Each target shows its devices, its last success and failure, and how many records wait at each gateway.
- The last error in plain text, per gateway
- Records waiting at each gateway, counted
influx query 'from(bucket: "proxus") |> range(start: -10m)
|> filter(fn: (r) => r.deviceName == "MFB_RTM_L1_FILLER") |> last()'
_measurement deviceName _field _value
tesis MFB_RTM_L1_FILLER BearingTemp 47.46
tesis MFB_RTM_L1_FILLER FaultCode 0
tesis MFB_RTM_L1_FILLER FillDeviation 0.167
tesis MFB_RTM_L1_FILLER GoodCount 74414See it arrive at the target
In InfluxDB each value lands as a point, tagged with its device and stamped with the time it was read.
- Numbers, true/false and text keep their type
- A buffered value keeps its own time
Know the source is complete before you send it
The data feed board shows how complete each source is, hour by hour, so a gap is found at the hub before a warehouse misses it.
- Expected minutes against received, per plant
- Every gap with its start, end and minutes missing
Real Proxus screens; the machine data shown is simulated.
Want to see your own targets like this? Check your targets
Technical details Problems it solves, every capability and the full protocol table
What it solves
What teams run into without it.
-
A pipeline per consumer
Each new system means another script, another credential and another thing to maintain at 3am.
-
Silent delivery failures
The dashboard looks fine because it reads a cache; the warehouse has been missing rows for a week.
-
Duplicated transformation
The same scaling and renaming logic re-implemented slightly differently in every integration.
What you get
Built in, not bolted on.
-
Outbound channels per device
Choose which signals go where, without rebuilding the collection layer for each destination.
-
Transport strategies
Pass-through for every reading, or on-change to move only what actually changed.
-
Message brokers
Kafka, RabbitMQ, MQTT and Sparkplug B for event-driven consumers.
-
Databases
PostgreSQL, SQL Server, Oracle, MySQL, Firebird, ClickHouse, InfluxDB and TDengine.
-
Cloud services
AWS IoT Core, Azure IoT and REST endpoints, from your own network outward.
-
Delivery visibility
Status, last success, last failure and last error per target, and how many messages are queued at the gateway while it is unreachable.
What this enables
What the capabilities add up to, in practice.
- Add a consuming system without adding a collection layer
- Match transport to each target instead of flooding all of them
- Prove a feed is intact before the consumer complains
- Change where data goes without touching how it is collected
Proven in production
Feeding the systems these teams already run.
-
Manufacturing
Digital factory data management
MEXT Digital Factory
Read the case study -
Mining & energy
Mining, fleet and solar on one platform
Kaltun Mining
Ask us about this deployment -
Energy
Grid monitoring at the edge
CK Enerji
Ask us about this deployment -
Manufacturing
Unified Namespace with Oracle ERP
Pilenpak
Ask us about this deployment
Do targets read from Proxus, or does Proxus push?
Proxus pushes to configured targets, which means delivery is initiated from inside your network. Targets can also read through the API or the namespace where that suits them better.
What is the difference between pass-through and on-change?
Pass-through sends every reading the gateway takes. On-change sends only when the value actually changes. Choose per target: a historian may want everything, a cloud warehouse usually does not.
How do we know a delivery actually happened?
Each target shows its status, last success, last failure and last error in the product, and while it is unreachable, how many messages are queued at the gateway. A broken feed surfaces before the consuming team notices it.
Can one signal go to several systems at once?
Yes. A signal is defined once and can be attached to any number of outbound channels, each with its own format and strategy.
What if our target system is not on the list?
Most systems accept data through a database write, a message broker or a REST endpoint, all of which are standard targets. Anything genuinely bespoke can be handled with a custom function.
Continue
- Platform Unified Namespace Read more
- Platform Historian & analytics Read more
- Platform Security & deployment Read more
Two numbers set your price: the gateways you run and the data rate they carry. See pricing
Check your targets
Where should the data go?
Tick the systems you want to feed. An engineer checks each one against the destination list and replies within one working day.