Platform · Fleet Management
A product describes a device model once: its settings, storage, API and dashboard. Every unit that connects registers itself, inherits it, and takes new firmware over the air.
The problem
What takes a minute for one prototype becomes a job nobody can keep up with when the same work repeats for every unit.
Five jobs per unit, again for every unit you ship
cold-room-sensor
Every unit inherits it the moment it connects
Products
A product profile holds everything units of one model share. Change it once and every device follows.
Properties keep what each device needs to remember: its configuration, location, firmware version or last state. Set a default once and every unit inherits it, or keep a property in sync from a device resource or an MQTT topic.
Declare where the data comes from and the product creates the bucket with the first reading. One bucket serves the whole fleet: every value is tagged with its device and group, ready to filter in dashboards and queries.
Each API resource becomes a REST endpoint on every device of the product. MQTT and HTTP devices then behave like IOTMP ones: they show up in the API explorer and on dashboards, and a call can land on a topic, a device resource or a function.
Product scripts process the fleet’s data before it is stored: decode a binary payload, convert units, drop readings you do not want or compute a derived value. Properties, buckets and resources call them from their payload template.
Design the product dashboard once. Each device opens it with its own properties and bucket data, and the controls act on its own API resources. Where a unit needs something different, its dashboard can be edited on that device alone.
Flows react to what devices do. A property update, a message on a topic or data arriving at an endpoint triggers the flow, and its actions run in order: publish to a topic, call an endpoint. The profile draws every source and target as a graph.
Auto-provisioning
Nobody creates units by hand. The first time a device connects, the product recognises it and sets it up.
Product · cold-room-sensorAuto-provisioning rule cold-room-*
The unit leaves the factory with its id and a credential, or a client certificate.
It dials the platform over IOTMP or MQTT. Nobody has created it in the console.
The auto-provisioning rule matches the id prefix and validates what the device presents.
The device joins the product with its own credential and inherits the whole profile.
Other ways into a product
The network server plugins for The Things Stack, ChirpStack and LORIOT build each id from a prefix and the device EUI, so sensors provision as their data arrives.
A flow can create devices when data arrives from a message broker, taking the id from the MQTT topic. Gateways can spawn subdevices from their own flows.
With claim, end customers add units themselves with a link, a QR code or a claim code, and configure them as they do. Customer onboarding
EVERY UNIT, ONE DEFINITION
Day to day
Change settings without a site visit and see which units need attention without opening each one.
Remote configuration
A property set on the product, an asset type or an asset group reaches every device beneath it, and the device’s table shows where each value came from. A unit that needs something different gets its own value under the same id.
Fleet view
Each device records whether it is online, its last connection and its traffic. Asset groups, nested as deep as you need, split the fleet by site or customer, and the assets map shows who is connected at a glance.
OTA updates
Build in VS Code and send the binary over each device's own connection, to one unit or a batch.
OTA · 4 devices · cold-room-sensor1.5.0
cold-room-04121.4.0 1.5.0 Updated
cold-room-04171.5.0 Same version, skipped
cold-room-04231.4.0 1.5.0 Updated
cold-room-04311.4.0 1.5.0 Uploading
A plugin in your instance
The VS Code plugin installs from the marketplace and runs inside your Thinger.io instance, with PlatformIO and the Thinger.io extension ready to build.
Many devices at once
Pick one device or a batch, then build and upload in one click. Units already on the target version are skipped, and the log records every result.
Checked on arrival
Firmware travels over the device’s own connection, compressed on ESP32, ESP8266 and Arduino Portenta, and verified with an MD5 checksum.
The boards it supports
ESP32, ESP8266, Arduino Nano 33 IoT, MKR WiFi 1010, MKR NB 1500, Nano RP2040 Connect, Portenta and Opta. The first firmware goes in by cable.
Go further
Install a ready product for known hardware, package yours, and reach Linux units in depth.
Good to know
What teams ask before moving a device from prototype to production.
A product defines the behaviour of a set of devices of the same type. Its profile holds the properties, data buckets, API resources, scripts and flows those devices share, plus one dashboard layout. Every device linked to the product inherits all of it, so a change to the profile reaches the whole fleet at once.
The product carries an auto-provisioning rule that matches incoming device identifiers, for example every id that starts with a given prefix. When a matching device connects for the first time, the platform creates it inside the product with the credential it presented. Since server 7.0, auto-provisioning can also authenticate devices with certificates. LoRaWAN devices provision through their network server plugin, which builds each id from a prefix and the device EUI.
Yes. Inherited properties cannot be edited from the device by accident, but creating a property with the same id on the device overrides the default for that unit only. The same applies to values inherited from asset types and groups, and a device’s dashboard can be edited on that device without changing the product layout.
Through the VS Code plugin from the marketplace, which runs inside your instance with PlatformIO and the Thinger.io extension preinstalled. You build the firmware and upload it to one device or to several at once over their own connection; devices that already run the target version are skipped. It supports ESP32, ESP8266 and several Arduino boards, including Portenta and Opta. The first firmware with OTA support has to be flashed by cable.
Yes. Properties and buckets can be fed from an MQTT topic as well as from an IOTMP resource, and API resources give MQTT and HTTP devices the same REST API as IOTMP ones, so they work in the API explorer and on dashboards. Flows can also create devices when data arrives from a message broker.
Every device records its connection state, last connection and traffic, and the assets map shows connected and disconnected units at a glance. For alerts, alarm rules with the absent comparator detect devices that stop sending data and notify by email or any endpoint.
Define the profile, switch on auto-provisioning and let every unit you build set itself up. The hundredth device takes the same effort as the first.
