IoT / Foundation

Devices speak different protocols. Your product can keep moving.

Choose native connectivity, legacy protocol adaptation or a field gateway according to device capabilities, then use the same product, model and operations workflows.

THE CUSTOMER PROBLEM

Start with the connectivity management problem.

You can choose a protocol for a new product, but deployed devices often cannot be reflashed. A project must decide where adaptation belongs and verify identity, field meaning, control responses and error records—not just an MQTT connection.

MECHANISM / REASON / TRADE-OFF

See how the capability works through the interface.

01

Three entry paths, one device workflow

Use native connectivity for controllable new devices, protocol adapters for existing messages, and gateways for child devices and field collection. Connected devices use the same product, device and thing-model management.

Choice and trade-off
The protocol, network and firmware determine the integration path. Extensibility does not mean every protocol works without development.
02

Clear extension points for both directions

Go/Yaegi protocol scripts separate pre- and post-processing for uplink and downlink. Bind a script to a product or device to transform input or add processing.

Choice and trade-off
Scripts still require debugging, permission and runtime-cost reviews. They are not a strong isolation boundary for arbitrary code.
03

Verify both directions after connecting

Check uplink fields, types and events; check downlink targets, parameters, send records and replies. For gateways, also verify parent-child relationships.

Choice and trade-off
An online status alone does not prove that properties, actions, OTA or controls work.
Protocol selection and connection settingsHistorical documentation interface; capture date is unconfirmed and it does not show a device connected now.

A CONCRETE EXAMPLE / MECHANISM EXAMPLE

Connect an existing temperature sensor

A workflow example: confirm the source field meaning before mapping it to an agreed temperature property. This is not measured device data.

  1. Provide messages, units, frequency, identity and network details
  2. Choose an adaptation point and define the product model
  3. Verify telemetry, queries and error records; test downlink when supported

READY TO INTEGRATE

Confirm these points before connecting.

IoT SIM guide ↗
  • Protocol documents, sample messages, authentication and network details
  • Agreed field units, reporting interval and control capabilities
  • Start with a test device; do not treat connectivity alone as acceptance