Can one IoT platform support several hardware vendors and incompatible protocols?
Yes, but not through a mythical universal protocol layer. Each vendor must provide an integration device, versioned protocol, and accountable support owner. The platform gives each vendor or model an independent adapter that maps raw fields to stable business meaning while retaining source, units, quality, and capability differences. A closed or semantically incompatible device should be explicitly degraded, separately maintained, or removed.
The difficult part is often not MQTT versus HTTP. The same field can mean different things and the same command can have different safety prerequisites. One vendor's “online” may mean a heartbeat within a minute; another may mean an active session. One battery estimate may come from coulomb counting and another from voltage. A visually unified table can still produce invalid decisions.
| Integration route | Best fit | Advantage | Long-term risk |
|---|---|---|---|
| Platform directly connects every vendor | Few vendors with open cloud protocols | Clear path and no gateway | Adapter growth and limited access to field buses |
| Edge gateway normalizes | Modbus/CAN/serial/OPC UA, weak network, local autonomy | Local collection, buffering, conversion | Another managed device, certificate, and version |
| Vendor cloud API | Existing devices locked to vendor cloud | Fast onboarding without device change | Latency, quota, outage, control, and export dependence |
| Procurement specification | Large new fleet and buyer leverage | Standard identity, fields, OTA, tests at source | Legacy remains and compliance needs acceptance |
Field control may require edge autonomy and device interlocks. Consumer devices may expose only vendor cloud. New large fleets can place protocol, certificate, OTA, log, and exit requirements in procurement. A platform can combine routes if business services depend only on a stable capability model.
When separating device, connectivity, and platform responsibilities, also compare What hardware information is required before starting an IoT software project? and How should a battery management platform be developed?; the linked guidance adds context that should be considered in the same decision.
Normalize meaning without erasing limitations
Every canonical property defines physical meaning, unit, precision, range, sampling/reporting interval, missing value, quality code, and time source. Mapping records vendor, model, protocol/firmware version, and effective date. Retain raw messages or a traceable digest for reprocessing. Unsupported remote restart is capability=false, not a button that silently fails.
Commands define prerequisite state, parameter range, timeout, idempotency, device acknowledgement, and final result. Message delivery is not execution. Upgrade, unlock, start, and stop follow model-specific interlocks, approval, and rollback. MQTT devices can use the OASIS MQTT 5.0 specification; industrial OPC UA integrations can use the OPC Foundation specifications. Standards reduce ambiguity but do not eliminate vendor extensions or implementation tests.
Wavesteam creates an onboarding package per supplier: owner, sample, protocol/version, mappings, credentials, errors, command matrix, network, update plan, test record, and support horizon. Contract tests and simulators precede real devices; real acceptance covers boundaries, disconnection, duplicate/out-of-order messages, reboot, firmware change, and abnormal values. Adapters release independently so a change for one vendor cannot break another silently.
Metrics remain per vendor/model: activation, data completeness, mapping correctness, consistent online state, P95 delay, command acknowledgement, backfill, and update outcome. Unified dashboards mark whether measures are actually comparable. Wavesteam's public energy-swap case shows a multi-device platform direction but does not disclose enough vendor/protocol detail to pre-prove a new integration. Feasibility ultimately depends on vendor openness and support.