polythings
Platform · planned

What we're building

Building blocks for connected products, each with its own API and each usable alone. Together they cover a device's life, from the factory to its last update, and its data, from the first message to the analysis years later. None of it is available yet; this is the plan.

Principles

One API

Every console action is a public, versioned API call, with an event for every change. Configuration round-trips as JSON, so it can live in Git.

Easy to start

Sign up and see live data from virtual devices in minutes, before writing code or touching hardware. A real device in a quarter of an hour.

Any use case

Primitives, not verticals. Factories, energy, buildings, fleets and consumer products are templates on the same building blocks.

Built for AI

Data that describes itself, with units and asset context, and agents that work through the same permissions as people.

How it fits together

Devices connect to the platform; their data lands in open timelake tables; jobs run next to the data. What runs on your hardware is open source.

          API · SDKs · CLI · console · embeddable portal · MCP
              │
┌─────────────┴────────────── platform ────────────────────────────┐
│ registry · twins · OTA rollouts · assets · metrics · alarms      │
│ jobs · migration · IAM · audit                                   │
└─────────┬───────────────────────┬───────────────────────┬────────┘
          │                       │                       │
    connectivity                data                 job runtime
 MQTT · HTTP · CoAP   ──▶  timelake tables  ◀──  SQL · Python · WASM
 IoT Hub / IoT Core     Iceberg, your bucket
          │
┌─────────┴──────────────── open source ───────────────────────────┐
│ device agent · embedded SDK · update format · edge gateway       │
└──────────────────────────────────────────────────────────────────┘

Devicesplanned

Identity, provisioning and a registry for every device, from microcontrollers to gateways, with twins, commands and remote configuration.

  • X.509 certificates per device, keys in a TPM or secure element, automatic rotation
  • Bring your own certificate authority; zero-touch provisioning with factory certificates or claim codes
  • Device models: the points, properties, commands and decoders of each device type
  • Twins with desired and reported state, and their full history
  • Direct and queued commands, fleet-wide configuration changes in waves

Certificate authorityplanned

A certificate for every device without a PKI team: issued at the factory, renewed automatically, revoked with the device, under our root or yours.

  • Managed, under your own root, or your existing CA: your choice, and your devices can stay chained to your root after you leave
  • A birth certificate from the factory and a short-lived operational certificate, renewed automatically so certificates never take devices offline
  • A factory station that signs devices on the production line and keeps working when the internet drops; secure elements from Microchip, NXP and Infineon
  • Every certificate in one inventory, with alarms for expiring certificates and for one certificate seen from two places
  • Certificates for gateways and OPC UA too, and usable on AWS IoT Core or Azure IoT Hub on its own

Cellular connectivityplanned

SIMs and eSIMs managed next to the devices they're in, with connectivity providers such as Teal: usage, cost, and carrier changes rolled out like updates.

  • Each device's SIM or eSIM, modem, plan and carrier in its record, synced from the provider
  • SIMs activated, suspended and ended with the device's lifecycle
  • Data use, signal, carrier and roaming per device as metrics, with alarms and cost per customer
  • When a device goes quiet, the network's view next to the device's, so you know whom to call
  • Carrier and eSIM profile changes rolled out in waves, with health gates and rollback

Over-the-air updatesplanned

Signed updates for any device: firmware on microcontrollers, A/B images on Linux, containers, files and ML models, rolled out in waves.

  • Microcontrollers through MCUboot, embedded Linux through RAUC, SWUpdate or OSTree, devices behind gateways through plugins
  • Rollouts in waves by group, site or customer, with maintenance windows and bandwidth limits
  • Health gates: a wave continues only while success rates and chosen metrics stay in bounds, otherwise it pauses or rolls back
  • Signed artifacts with TUF-style metadata; sign with your own keys
  • A software bill of materials per release, for vulnerability handling under the EU Cyber Resilience Act

Ingestionplanned

MQTT, Sparkplug B, HTTP, CoAP and LwM2M from devices, OPC UA and Modbus through an edge gateway, and streams from Kafka and other clouds.

  • Decoders declared per device model, or written in WebAssembly for anything unusual
  • Late and out-of-order data accepted, duplicates removed, rejected payloads kept with the reason
  • An edge gateway that buffers on site and runs rules while the uplink is down
  • Connectors for device clouds such as Particle: devices, events and commands in minutes, with no firmware change
  • Route data to your own Kafka, webhook or bucket as well

Storage and retrievalplanned

Time series kept as open Apache Iceberg tables with timelake, in our bucket or yours. Query by device or by asset, with SQL or the API.

  • Latest values, ranges and aggregates through the API; SQL over everything
  • Postgres wire protocol for Grafana and BI tools; Iceberg tables for DuckDB, Spark and Snowflake
  • Retention and rollups per table or per metric
  • Files such as images and vibration captures, found by device, asset and time
  • Live values and alarm changes over a subscription API

Assets and bindingsplanned

Model the machines, rooms and vehicles your devices measure. Bind devices to them over time, so history survives a sensor swap.

  • Hierarchies of any shape: site, line and machine; building, floor and room; fleet and vehicle
  • Asset models as templates for attributes, metrics, child assets and alarm rules
  • Bindings with a time interval, unit conversion and scaling, correctable after the fact
  • Sync asset hierarchies from ERP and maintenance systems, or a spreadsheet

Metricsplanned

A catalog of what every number means: unit, definition, owner and lineage, computed from measurements, formulas, rollups or jobs.

  • Measured metrics from bindings, formulas over other metrics, rollups over time or child assets
  • Versioned definitions: recompute history or apply from a date
  • Kept up to date incrementally as data arrives, including late data
  • Freshness, completeness and range checks on every metric

Alarmsplanned

Rules on metrics, defined once per asset model, with an ISA-18.2 lifecycle, flood suppression, and notifications where your team works.

  • Thresholds with hysteresis, rate of change, flatline, missing data, state changes, anomalies, and combinations
  • Raised, acknowledged, shelved and cleared, with who and why recorded
  • Grouping and flood suppression, so a site losing power is one alarm, not four hundred
  • Email, SMS, Slack, Microsoft Teams, webhooks and incident tools such as PagerDuty
  • Evaluated in the stream, or on the edge gateway when a site is offline

Analytics and serverless jobsplanned

SQL, dashboards and notebooks on the platform, and your own SQL or Python run on a schedule, on new data, or on an event.

  • A SQL workspace and dashboards built from assets and metrics
  • Jobs in SQL, Python or WebAssembly, triggered by a schedule, new data, an event or an API call
  • Incremental by time window, with one-call backfills over history
  • Each run isolated, metered and logged; outputs to tables, metrics, events or alarms

Predictive maintenanceplanned

Health scores and remaining useful life per asset, learned from its history and its maintenance records, so you fix machines before they fail.

  • Health indicators per asset model: vibration features and bearing frequencies, temperature rise, current signature, run hours
  • A health score for every asset, and remaining useful life with an uncertainty band where history allows
  • Failures and repairs from your maintenance system as labels, so models learn from what actually happened
  • Predictions as alarms with their evidence, and work orders opened in your maintenance system
  • Templates for motors, pumps, fans, compressors and gearboxes; models that run in the cloud or at the edge

AI agentsplanned

Agents read devices, assets, metrics and alarms through the same API and permissions as people, and act only with approval.

  • An MCP server over assets, metrics, devices, alarms and data
  • Questions in plain language, answered with the query and the chart
  • Anomaly detection as an alarm rule, and a summary of what changed when an alarm fires
  • Device models and decoders inferred from sample payloads, as proposals to review
  • ML models deployed to devices through the same update pipeline as firmware

Migrationplanned

Move from Azure IoT Hub, AWS IoT Core, Particle, ThingsBoard or your own platform without starting over: connect first, run both side by side, then move devices in groups.

  • Device endpoints compatible with Azure IoT Hub and AWS IoT Core, so existing firmware connects unchanged
  • Particle fleets connected through Particle's API first, then moved over with one last firmware update
  • ThingsBoard, Thinger.io, Mender and Eclipse Hono, Ditto, hawkBit and Kura, each with its own path
  • A step-by-step guide for leaving a platform you built yourself
  • Bridge mode: both platforms side by side, to compare data and alarms before moving a device
  • Importers for registries, device models, rules and history
  • A cutover plan per fleet: what moves unchanged, what needs an update first, and what it costs