2kw.io
Sign inBook a 15-min demo
AI-native IoT platform

Ask your machines.

2kw.io is an AI-native industrial IoT platform. It brings machines and sensors online, validates and stores every reading, and runs computer vision on the device itself — then lets you ask questions of the result in plain language, from the app or the command line.

Hosted and inferred in the EU · Your data exports as Parquet, any time
app.2kw.io
eu-central
Devices
42/44
online
Readings
1.2M
last 24 h
Alerts
3
active
Ingest
180ms
p95
Conveyor drive · powerlast 7 days
L1L2L3
Fleet
gw-werk2-01Modbus · camera
gw-lager-03BLE · 6 nodes
node-07last seen 4 h ago
Assistantgw-werk2-01 · 24 h
Why did the conveyor draw more power this afternoon?
getReadingStats
Total power averaged 6.2 kW between 14:00 and 16:00, against 4.8 kW for the rest of the day, peaking at 8.4 kW at 14:02. That peak lines up with the overload event on drive motor 1.
scoped to this device · your organisation only
assistant tools
6
The assistant reads devices and sensor history through typed tools — scoped to the device in view, inside your organisation's row-level security
vision on the device
ONNX
Detection runs on the gateway through GStreamer and reacts locally — it keeps working with the link down
hosting and inference
EU
Platform infrastructure and model inference both run in the EU, with per-organisation row-level isolation
export format
Parquet
A ZIP of Parquet files plus a manifest — your data leaves whenever you want it
Use cases

One platform. The use case is a file.

Everything specific to a job — the data model, dashboards, alert rules, capture rules — ships as a pack you install into your organisation in one step. The platform underneath stays the same, which is why a distillery and a conveyor belt run on one system.

Conveyor monitoring

Pack available

A jamming or wearing conveyor shows up in its motor's power draw before it shows up anywhere else. Watch three-phase power in real time, get told the moment it crosses an overload threshold, and get a video clip of what happened, captured automatically.

Sensors
  • Three-phase energy meter over Modbus
  • IP camera
What you see
  • Live per-phase and total power, current and voltage
  • An alert the moment power crosses your overload threshold
  • A short clip of each incident, with pre-roll and post-roll
  • A labelled history of jams, maintenance and power anomalies
Talk to us
Conveyor drive · total power8.0 kW limit
CRITICALOverload · 8.4 kW · 14:02:11
clip captured · 5 s pre-roll / 9 s post-roll · cam-conveyor-01
The pack installs
  • Three-phase energy-meter sensor profile
  • Gateway device profile with a Modbus meter and a camera
  • Overview dashboard
  • Overload alert rule
  • Media capture rule
  • Maintenance and jam annotation classes

Distillery

Pack available

Every cask loses spirit to evaporation, and nobody can tell you how much until it is gauged. A gas-sensing node on each cask, plus a classifier trained on your own warehouse, turns raw sensor scans into an ethanol-vapour estimate you can watch over time.

Sensors
  • Battery gas-sensing node per cask, over Bluetooth
  • Reference instrument
  • Weather station
What you see
  • Per-cask ethanol-vapour trends across a whole warehouse
  • Temperature, humidity, pressure and the raw gas scans behind the estimate
  • A labelled history of fills, gaugings, sample draws and cleanings
  • An alert when vapour climbs — a possible leak
Talk to us
Warehouse 2 · ethanol vapour by cask24 casks · live
cask 14 · 30 d
The pack installs
  • Gas-scan, reference-instrument, weather and battery sensor profiles
  • Cask event annotation classes
  • Correlation job pairing casks against reference measurements
  • Vapour-rise alert rule

Energy submetering

Pattern

A site-level electricity bill tells you what you spent, not where it went. Meter each machine or line separately and the number becomes actionable — consumption per shift, cost attributed to the machine that caused it, and a baseline that makes waste visible.

Sensors
  • Modbus or RS485 energy meters per circuit
What you see
  • Consumption per machine, line or shift
  • Cost attributed to the thing that spent it
  • Alerts when a machine drifts from its own baseline

The platform supports this today; the pack gets written for you.

Talk to us
Reading · kWshift baseline
min 22 kWmax 31 kWbreach highlighted
A pack would install
  • Meter sensor profiles matching your hardware
  • Consumption dashboard
  • Baseline-drift alert rules

Cold chain

Pattern

A cold-chain excursion is only a problem if you cannot prove what happened. Continuous temperature and humidity per unit, an alert on breach, and an export that stands up as a record turn a dispute into a chart with a timestamp on it.

Sensors
  • Temperature and humidity probes per unit
  • Door state sensors
What you see
  • Temperature per unit, continuously, with the breach highlighted
  • An alert the moment a threshold or a sustained average is crossed
  • An export covering any window, as Parquet plus a manifest

The platform supports this today; the pack gets written for you.

Talk to us
Reading · °C8 °C limit
min 4 °Cmax 8.4 °Cbreach highlighted
A pack would install
  • Temperature and humidity sensor profiles
  • Per-unit dashboard
  • Breach and sustained-average alert rules

Indoor air quality

Pattern

Air quality complaints are hard to act on without data. Measure CO₂, particulates, temperature and humidity per room, and the argument stops being a matter of opinion and becomes a chart with a threshold on it.

Sensors
  • Multi-gas and particulate sensor nodes per room
What you see
  • CO₂, particulates, temperature and humidity per room
  • Alerts when a room stays above a limit rather than briefly touching it
  • A labelled history of occupancy and ventilation changes

The platform supports this today; the pack gets written for you.

Talk to us
Reading · ppm1000 ppm
min 520 ppmmax 1120 ppmbreach highlighted
A pack would install
  • Air-quality sensor profile
  • Per-room dashboard
  • Sustained-threshold alert rules

Fermentation

Pattern

Fermentation goes wrong slowly and then all at once. Track temperature, pressure and gravity per vessel, and catch a stall or a runaway against the vessel's own recent normal, while there is still something to be done about it.

Sensors
  • Temperature and pressure probes per vessel
  • Gravity sensing
What you see
  • Per-vessel temperature, pressure and gravity curves
  • Alerts on a stall or a runaway, judged against recent normal
  • A labelled history of pitches, transfers and interventions

The platform supports this today; the pack gets written for you.

Talk to us
Reading · °Canomaly band
min 18 °Cmax 24.1 °Cbreach highlighted
A pack would install
  • Vessel sensor profile
  • Batch dashboard
  • Statistical-anomaly alert rules
  • Batch-event annotation classes
01 · Ask

The dashboard answers back.

An assistant sits inside the app with tools that read your devices and their sensor history. It resolves the same time window the chart is showing, so “what happened around 14:00?” means the range you are looking at. It cannot reach sensors outside the device in view, and every query runs inside your organisation’s row-level security.

The assistant runs on 2kw.ai, the AI platform from the same company — which routes the model, meters what each answer costs, and keeps inference in the EU.

The second surface is the command line. iot is built to be driven by a program: a global --json flag, spinners and prompts suppressed off a terminal or in CI, and an OpenAPI reference it browses offline. Today it covers authentication, environment contexts and device provisioning.

Assistantgw-werk2-01 · 24 h
Why did the conveyor draw more power this afternoon?
getReadingStats
Total power averaged 6.2 kW between 14:00 and 16:00, against 4.8 kW for the rest of the day, peaking at 8.4 kW at 14:02. That peak lines up with the overload event on drive motor 1.
scoped to this device · your organisation only
zsh
# authenticate once, per named environment
$ iot auth login
✓ signed in — context: production
# discover the API without a network call
$ iot docs list --json
[{"tag":"devices","operations":14},
{"tag":"readings","operations":9},
{"tag":"alert-rules","operations":6}]
# no spinners, no update banner — clean stdout
Plus

The rest of the platform.

Configure & control

Declare intent. Watch it converge.

Immutable versioned configuration bound to a device, a group, or a whole profile — most specific wins. Commands carry a full acknowledgement lifecycle, and firmware updates over the air. The device reports back what it actually applied.

Packs

A use case is a manifest.

Profiles, dashboards, alert rules, capture rules and annotation classes, installed into your organisation in one step. Idempotent, applied in dependency order, and reversible.

Analytics & annotations

Label it once, analyse it forever.

Schema-driven labels on any scope, reference pairs linking a field sensor to a lab instrument, and scheduled jobs that write their findings back as annotations — so analytics lands in the same timeline as everything else.

Export

Your data, in a format that outlives us.

A ZIP of Parquet files plus a JSON manifest, for any scope and any window. It drops straight into standard data tooling, so there is nothing proprietary to unpick if you leave.

Build vs buy

None of this is impossible. It is just a year.

Build it yourself
  • Stand up a broker, a certificate authority, and a device-provisioning flow
  • Write ingest validation, then somewhere to put what fails it
  • Build dashboards, an alert engine, and the notification plumbing behind them
  • Wire a vision model onto a gateway and keep it updated by hand
  • Bolt an LLM onto your database and hope the scoping holds
With 2kw.io
  • Devices provision their own identity on first boot
  • Readings are validated against a profile; rejects stay inspectable, not lost
  • Dashboards, three alerting strategies, and notifications included
  • Vision models bound to devices as versioned desired state, with rollback
  • An assistant scoped per device and per organisation, inference in the EU
Pricing

Priced against your fleet.

No tiers, and nothing held back behind one. Every deployment gets the whole platform; what changes is the size of it. We quote per deployment rather than pretending one number fits a ten-sensor pilot and a five-site rollout.

Cost driver

How many devices

Gateways, sensor nodes and cameras. The count you run, not the count you might one day run.

Cost driver

How long you keep data

Retention on the time-series store. Long histories cost more to keep and are worth more to have.

Cost driver

How much media you capture

Video is the expensive part. A capture rule that fires twice a week is not a live wall of streams.

Included in every deployment
  • Every alerting strategy — threshold, sliding window, statistical anomaly
  • The in-app assistant, with inference in the EU
  • On-device computer vision and ML pipeline delivery
  • Dashboards, annotations and scheduled analytics jobs
  • Event-triggered video capture and brokered live view
  • Use-case pack installation
  • Bulk export as Parquet, whenever you ask for it
  • EU hosting and per-organisation row-level isolation

Tell us what you are monitoring.

Roughly how many machines or sensors, how long you need the history, and whether cameras are involved. That is enough for a number. If it turns out we are the wrong fit, we will say so on the call.

Get a quote

Frequently asked questions.

Something not covered here? Talk to us.

What is 2kw.io?

2kw.io is an AI-native industrial IoT platform. It brings machines and sensors online over MQTT with per-device certificates, validates and stores every reading in a time-series database, runs computer vision on the gateway itself, and lets you ask questions about the result in plain language from the app.

What can the assistant actually do?

The assistant answers questions about the device you are viewing. It has typed tools that fetch device details, raw sensor history, statistics over a time range, and the exact aggregated series the chart is drawing. It resolves the same time window your chart is showing, so asking what happened at a particular moment means the range in front of you.

Can the assistant see other customers' data?

No. The assistant's tools are restricted to a server-side allow-list of sensors belonging to the device you are viewing, and every tool call executes inside your organisation's row-level security context. A request for a sensor outside that list is rejected before any query runs.

Which model does the assistant use, and where does it run?

AI functions run on 2kw.ai, the AI platform from the same company, which routes the request to a frontier model and meters what each answer costs. Model inference is served in the EU, as is the platform itself.

Is my data used to train models?

No. Your readings, annotations and the questions you ask the assistant are not used to train models. They stay isolated to your organisation under row-level security, and inference runs in the EU.

Does computer vision need a cloud connection?

No. Detection runs on the gateway as an ONNX model inside a GStreamer pipeline, and the gateway acts on a detection locally. The line keeps working when the network does not. Detections are forwarded to the platform as events when connectivity allows.

Can I bring my own model?

Yes. A model is uploaded as a versioned configuration artefact and bound to devices as desired state. The device reports back which version it is actually running, so you can watch convergence and roll back to a previous version.

Is there an MCP server?

Not today. The programmatic surfaces are the REST API and the iot command-line tool, which is built to be driven by a program: a global JSON output flag, output that stays clean off a terminal or in CI, and an OpenAPI reference it can browse offline.

What kinds of devices can I connect?

Anything that can speak MQTT over TLS, plus everything the edge runtime already handles: Modbus and RS485 energy meters and instruments, Bluetooth Low Energy sensor nodes, and IP cameras. Devices can also be virtual, which is useful for piloting before hardware arrives.

Do I need to write firmware?

No. The gateway ships as a Raspberry Pi image with the edge runtime installed. You register the device, flash it with a one-time token, and it provisions its own certificate on first boot. Everything after that is declarative configuration rather than a code change.

What happens to data that fails validation?

It is parked in quarantine rather than dropped. Every reading is checked against its sensor profile for required fields, types, array sizes and numeric ranges. Rejected payloads stay inspectable, so you can see exactly what a device sent and why it did not land.

Can I get my data out?

Yes, whenever you want. An export job produces a ZIP of Parquet files plus a JSON manifest, covering readings and annotations for whatever scope and time range you choose. Parquet drops straight into standard data tooling, so there is nothing proprietary to unpick.

Where is the data hosted?

In the EU. Platform infrastructure and model inference both run in Europe, and every organisation is isolated at the database level with row-level security rather than by application-layer filtering.

How is this different from Grafana?

Grafana visualises data it does not collect. 2kw.io provisions the devices, validates and stores what they report, runs vision models on them, alerts on the results, and pushes configuration back down. If you already run Grafana, it can read from this platform rather than be replaced by it.

What does it cost?

Pricing is quoted per deployment, because the cost drivers are device count, retention and how much media you capture. Book a short demo and we will size it against your actual fleet.

Stop building IoT plumbing from scratch.

Devices that provision themselves, vision that runs on the machine, and an assistant that answers questions about what your sensors actually did — hosted and inferred in the EU.

Book a 15-min demo Documentation
No commitment · We'll connect one of your devices on the call