Device Profiles
Describe a device model once: points, scaling, units. Reuse it for every identical device on every site.
Drivers read the devices. The tag model makes them comparable. Services and APIs put the data to work.

Chillers, meters, switches, sensors and tags, on the protocol they already speak.
One driver per protocol, running at the edge or on a server.
Every reading gets a name, unit, timestamp and quality in your site hierarchy.
History, alerts, rules and users, all working from tags.
Dashboards, an open REST API, and MQTT to anything else.
Describe a device model once: points, scaling, units. Reuse it for every identical device on every site.
Organise tags by site, building, floor and equipment, so a query reads like the real world.
Store tag history, query it by time range, and export it when another team needs it.
Raise alerts on thresholds, rate of change and silence, and trigger actions from rules.
Build views for operators and managers from the same tags, with roles that decide who sees what.
Read tags and history over REST, and publish live values to any MQTT broker.
Each part has its own page with the detail.
Protocol drivers that run beside the equipment.
Read More
One shape for every reading, whatever protocol sent it.
Read More
The right view for each role, and an alert only when it matters.
Read More
Your data, available to the tools you already use.
Read More
Describe a device model once, reuse it everywhere.
Read MoreA short list, so the first week is spent reading devices, not hunting for documents.
No. It reads from them and from the devices beneath them, and adds a common tag model, history and APIs. Existing control logic stays where it is.
Yes. Tags and history are available over a REST API, and live values can be published to an MQTT broker.
With drivers running on an edge gateway, collection continues at the site and data is forwarded when the connection returns.
Tell us which protocols are on site. We will scope a pilot that reads your real devices.