IO Telemetry Gateway
A supported appliance that reads the power and cooling plant over Modbus and delivers clean, named, correctly scaled readings to the monitoring platform you already run.
Modbus TCP and RTU in. Prometheus and OTLP out. DIN rail, 24V DC, typ. 8W.
The whole product, in one comparison
Somebody has to know. It should not be you, and it should not be a spreadsheet on a shared drive.
What integrating a meter looks like today.
Register 40117
16-bit integer
x0.1 multiplier
big-endian
Is that kW or kVA?
Which phase?
Is 65535 a reading, or a fault code?
Does 40117 mean holding register 117,
or wire offset 40117?Repeat for every point, on every device, on every site. Then keep it correct through a firmware update.
What integrating a meter looks like with the gateway.
devices:
- id: pdu_a1
endpoint: gw_pwr_a
address: "2"
profile: schneider_pdu
tags: {site: LON1, room: dh1, row: A}The maintained device definition does the ugly bit. You name the device, say where it is, and tag it the way your site is actually organised.
io_pdu_active_power_kilowatts{site="LON1",room="dh1",row="A",device="pdu_a1"} 34.1
io_pdu_current_amperes{site="LON1",room="dh1",row="A",device="pdu_a1",phase="l1"} 48.2
io_pdu_current_imbalance_percent{site="LON1",room="dh1",row="A",device="pdu_a1"} 4.8
io_ups_battery_charge_percent{site="LON1",room="dh1",row="A",device="ups_a1"} 97.5
io_ups_battery_runtime_minutes{site="LON1",room="dh1",row="A",device="ups_a1"} 11.5
io_ups_operating_mode{site="LON1",room="dh1",row="A",device="ups_a1",mode="normal"} 1Named, scaled, carrying its units, and labelled with your site vocabulary. Something you can put on a dashboard or alert on without a translation step in the query.
How it works
01
Modbus TCP and RTU to the equipment you already own. Devices on an RS485 bus are reached through the gateway that already fronts them; a UPS with its own Ethernet port is read directly. Nothing is replaced and nothing is rewired.
02
Maintained device definitions hold the registers, data types, word order, scaling, units and naming. That work is done once, by us, and kept up to date — it is not a spreadsheet your team maintains after the person who wrote it leaves.
03
A Prometheus endpoint today, with OpenTelemetry export for vendor-neutral delivery. Series are named and labelled to Prometheus conventions, so they behave like everything else in your platform.
Where it sits
The gateway is a translation device between the plant and the monitoring you already run. There is no new dashboard to adopt, no agent on your servers, and no second user-access model to administer.
Device packs
Anything can read a register. Knowing which register, what type it is, how it scales, what to call it and what it means when it reads 65535 — that is the part that takes time, and the part that goes stale.
UPS
APC by Schneider Electric
UPS
Vertiv · Liebert
UPS
Socomec
Power distribution
Schneider Electric
Metering
Carlo Gavazzi
Cooling
CRAH and CRAC units · Chillers · Coolant distribution units
Environmental
Modbus temperature and humidity transmitters · Differential pressure sensors · Leak detection controllers
Device definitions are maintained and updated as part of the subscription. When a manufacturer changes a register map in a firmware revision, that is our problem to track, not a fault you discover from a graph that has been flat for three weeks.
New and bespoke equipment can be mapped on request. A pack is a file the appliance loads at runtime, so a new mapping is something you receive and drop in — no firmware update to the appliance, and no waiting for a release.
Scope
This is not DCIM. It reads plant and hands the readings to your monitoring platform. That is the whole job, and keeping it that small is why it is supportable.
The gateway does not want to be the record of what you own.
No elevations, no U-space, no floor plans.
Not a port, not a patch, not a run.
No tickets, no maintenance scheduling, no permits.
It supplies the readings a capacity model needs. It is not the model.
No portal to sign in to and no second set of user accounts to administer.
Resilience
High availability that a facilities team can actually operate at three in the morning, without a runbook that starts “check cluster quorum”.
The configuration is portable, held outside the appliance as well as on it. The spare is preconfigured and powered down. There is no clustering, no failover layer and no shared state to go wrong.
Move the power, the network and the Modbus connection to the spare.
Start it.
Confirm collection — the unit’s own terminal interface shows what is answering.
Return the failed unit to us.
We send a replacement, preconfigured for your site, back to the shelf.
Specification
Who is behind it
Industrial Observability is built by former Grafana Professional Services engineers and co-authors of Observability with Grafana (Packt). We have spent our working lives putting other people’s infrastructure onto dashboards, and the physical layer was always the part that got left out.
We are deliberately vendor-neutral. We work with several monitoring platforms and can help you choose, procure or implement one if that is useful. The gateway speaks Prometheus and OTLP because those are the interfaces your platform already has, so it works with whichever you run.
Questions
Yes. The gateway exposes a Prometheus endpoint, so anything that scrapes Prometheus can read it — your existing Prometheus, Grafana Alloy, Grafana Agent, VictoriaMetrics, or a commercial platform with a Prometheus receiver. An OpenTelemetry export is the vendor-neutral route where OTLP suits you better.
There is no plugin to install, no data source to buy and no dashboard you are obliged to use. Metric and label naming follows Prometheus conventions, so the series behave like everything else already in your platform.
Tell us what it is. Mapping new equipment is normal work, not an exception, and new and bespoke devices can be mapped on request.
A device pack is a file the appliance loads at runtime, so a new mapping is something you receive and drop in. If the equipment is genuinely one of a kind, you can write the mapping yourself: the format is documented and the appliance includes a register decoder that shows a raw reading interpreted every plausible way, so a type and word order are settled against the equipment’s own display rather than guessed.
No. The gateway polls equipment on your network and serves metrics on your network. It runs in an isolated OT segment with no route to the internet, which is where most of this equipment already sits.
Device definition updates arrive as files. You can take them over your own management path, or by hand. Nothing in the appliance calls home, and there is no vendor portal to sign in to.
The collector is a single static binary with no runtime and no interpreter underneath it. It runs as an unprivileged service under systemd with the standard sandboxing options applied, and needs no inbound connection except the metrics endpoint you choose to expose — which can be bound to localhost and scraped by a local agent if you would rather it were not on the network at all.
Modbus is a protocol with no authentication of its own. The gateway reads; writing is not part of what it is for. Where a configuration is owned by Ansible or another configuration manager, the appliance can be started in a mode that refuses to save changes made on the box, so a local edit fails loudly rather than being silently reverted on the next deploy.
Updates to the collector and to device definitions are supplied as part of the subscription and applied on your schedule.
You fit the cold spare. Sites are specified with two identical units: one live, one preconfigured on the shelf.
The configuration is portable, held outside the appliance as well as on it. Recovery is moving power, network and the Modbus connection to the spare, starting it, confirming collection, and returning the failed unit. We send a replacement, preconfigured for your site, so you are back to two units without doing the commissioning again. There is no cluster to rebuild, no quorum, and no HA layer for your team to learn and administer.
While a unit is down you lose collection, not history. Everything already gathered is in your monitoring platform, where it always was.
No, and it is not trying to be. There is no asset database, no rack elevation, no cable management, no work orders and no capacity planning.
The gateway does one job: it reads the plant and hands the readings to your monitoring platform in a form that platform already understands. If you run DCIM, this sits alongside it. If you do not, this is not a reason to start.
It depends on how reachable the equipment is, which is usually the real variable. The gateway itself is DIN-rail mounted, takes 24V DC and needs a network path to the equipment.
Before it connects to anything, it will validate a configuration and print the resolved addressing of every point — the table to hold against a datasheet. It will then read every device once and exit with a status code, which is enough to drive a commissioning script. A local terminal interface on the unit shows what is answering and what is not, which is where fault-finding actually happens.
Talk to us. Cost depends on the number of sites, how many devices are behind each unit, and whether any equipment needs mapping — so a figure quoted before that conversation would be a guess.
The commercial model is an appliance with a subscription that covers device definition updates, collector updates and support. Tell us about your site and we will give you a real number.
Send the equipment list and the sites. We will tell you what is already mapped, what needs mapping, and what it costs.