IoT and data platforms

IoT and data platforms receive, store and process telemetry from devices and gateways, and provide APIs for the applications built on top. Check the supported ingest protocols, the security model, data retention and what it costs as the device count grows.

Platforms in this directory

What to look for

What good looks like

  • Clear evidence on protocols, device management, security and the edge-to-cloud architecture
  • Large mixed-device estates or deployments in harsh environments
  • Documented export, API and integration options

Red flags

  • The platform messaging is generic and the protocol or device evidence is weak.
  • There is no public detail on fleet management, updates or certificate handling.
  • Data ownership and export terms are unclear.

Connecting Edge to an IoT platform

Decide what needs to leave the site

Edge runs on site: it configures devices, shows dashboards and runs local automation, and forwards data when you need it elsewhere. It also provides data exploration and calculated readings. Start by deciding which of those tasks stay local and which information an external platform needs.

A cloud service may need periodic energy totals, selected telemetry or events rather than every available reading. Agree the measurements and reporting intervals before choosing the transport or estimating storage requirements.

Use a supported flow, or build one for your platform

Edge sends data through integration flows configured for each platform. These can adapt site data to the receiving platform's interfaces and message format.

MQTT and HTTP are the transports. For the destination service, confirm its authentication method, endpoint, payload structure, topic or resource naming, limits and acknowledgement behaviour. An MQTT service can still require a particular device identity and message contract.

Check an older connector's endpoint and setup instructions against the platform's current release.

Map devices and measurements deliberately

Use stable site, device and sensor identifiers. Agree units, timestamp format, time zone and whether a reading is an instantaneous value, a cumulative total or an interval quantity.

Keep quality and availability visible. The receiving application should distinguish missing or stale data from a real zero. If a value is transformed or calculated, document that calculation and preserve a way to relate it to the original readings.

Design for interruptions

Define retry, duplicate-handling and recovery behaviour for the chosen flow. Size local storage and queued delivery for the longest outage the site must ride through: both are bounded by the installed configuration and available resources.

Test a controlled network interruption and compare the recovered data at both ends. Agree what should happen to commands and notifications while the destination is unavailable.

Keep access and operations manageable

Use the permissions and credential-handling approach supported by each endpoint. Agree how credentials are provisioned, rotated and revoked, and who monitors failed deliveries. Do not place secrets in public URLs, screenshots or support enquiries.

The Gateway and hardware range provide the site connection. A company's directory profile explains its offering.

For downstream dashboards and reports, see the reporting and BI guide.

Connecting EpiSensor to your data platform? Tell us about the site, existing equipment and the data or control workflow you want to build.

Browse by category

Buyer guides