In device connectivity projects, serial converters, edge gateways, and IoT platforms often appear in the same bill of materials, but they do not solve the same layer of the problem. The practical distinction is simple: a serial converter connects RS485 / RS232 devices to a network, an edge gateway handles field protocols, buffering, local rules, and security boundaries, and an IoT platform turns connected devices into long-term operational assets.
When teams mix these concepts, two failures are common. One team expects a serial converter to behave like a platform, so the device can connect but cannot be managed. Another team starts with a full platform before solving field protocol, wiring, and offline buffering problems, so the platform looks complete while the data path remains unstable.
The Short Answer: Which Layer Does Each Product Solve?
| Component | Primary problem | Typical capabilities | What it should not own |
|---|---|---|---|
| Serial converter | Connect serial devices to IP, ZigBee, or Wi-Fi networks | RS485 / RS232 conversion, transparent transmission, point access | Device models, alert workflows, long-term data governance |
| Edge gateway | Stabilize and normalize field data before it reaches upper systems | Multi-protocol collection, edge buffering, store-and-forward, local rules, security isolation | Full customer portals, cross-project permissions, long-term operations |
| IoT platform | Manage devices as operational assets | Device registry, permissions, alerts, work orders, reports, analytics, API integration | Field wiring, protocol drivers, every real-time control loop |
The selection rule is direct: if the question is "how does this device join the network," start with a serial converter; if the question is "how does field data reach the upper system reliably," use an edge gateway; if the question is "how do we operate these devices over time," use an IoT platform.
Serial Converter: Access, Not Operations
A serial converter is valuable because it gives network access to devices that originally communicate through RS485, RS232, or TTL serial interfaces. For meters, controllers, thermostats, sensors, legacy industrial equipment, and commercial devices, this is often the lowest-cost connectivity entry point.
For example, if a project only needs to connect a Modbus RTU controller to an upper system or gateway, a ZigBee serial port converter or Wi-Fi serial port converter may be more practical than replacing the whole device. It solves the bridge between field interfaces and network access.
But a serial converter should not be treated as an IoT platform. It can make data reachable, but it does not automatically answer operational questions: who owns the device, what does each point mean, how should exceptions become alerts, who handles them, where is history stored, and can different roles see different devices? If a project needs those capabilities, relying only on serial converters pushes complexity into upper systems, scripts, or manual processes.
Edge Gateway: Field Complexity and Link Reliability
An edge gateway sits between field devices and the platform. Its value is not that it is "a more expensive converter." Its value is that it creates a stable boundary for several field problems: protocol adaptation, data cleaning, buffering, local rules, network isolation, authentication, and remote maintenance.
When the site includes Modbus RTU, Modbus TCP, MQTT, HTTP, PLC communication, or vendor-specific protocols, an edge gateway can normalize those differences into a consistent data model or message structure. It can also cache data during network outages and forward it in order after reconnection, so the platform does not receive broken time series.
When local inference, local dashboards, video analytics, or lightweight AIoT processing are required, the edge gateway may become an edge computing box. Lightweight scenarios can evaluate the AIHub-Z3 edge computing box, while higher compute and richer peripheral scenarios can evaluate the AIHub-Z5 edge computing box.
The boundary also matters: an edge gateway is not a full platform. It is good at field links, but it should not carry long-term customer permissions, device lifecycle, work orders, reporting centers, and multi-project operations by itself. Putting all business logic into the gateway makes field nodes heavy and harder to upgrade consistently.
IoT Platform: Device Operations, Not Field Wiring
The core question for an IoT platform is not "can it receive data?" The question is "can connected devices be operated over time?" A usable platform should cover device registry, grouping, permissions, state, alerts, work orders, reports, APIs, analytics, and system integration.
If a company needs to manage multiple projects, customers, sites, and device types, a platform such as the ZedIoT IoT Platform becomes useful. It turns devices from data sources into operational objects: every device can have ownership, location, state, alert rules, maintenance history, and connections to reports, work orders, and business systems.
The platform should not replace the field access layer. In real projects, it depends on gateways, serial converters, or device SDKs to send stable data upward. If the field link is unstable, the platform can only show unstable results. Conversely, if there is only a gateway and no platform, device data rarely becomes part of a long-term operations process.
flowchart LR
A("Field devices<br/>meters / controllers / PLC / sensors") --> B("Physical access<br/>RS485 / RS232 / DI / TCP")
B --> C("Serial converter<br/>ZigBee / Wi-Fi / Ethernet")
C --> D("Edge gateway<br/>protocol adaptation / buffering / local rules")
D --> E("IoT platform<br/>registry / alerts / work orders / reports")
E --> F("Business systems<br/>ERP / MES / WMS / customer portal")
classDef device fill:#e0f2fe,stroke:#0284c7,stroke-width:2px,color:#0f172a;
classDef access fill:#ecfeff,stroke:#0891b2,stroke-width:2px,color:#0f172a;
classDef edge fill:#fef3c7,stroke:#d97706,stroke-width:2px,color:#0f172a;
classDef platform fill:#ede9fe,stroke:#7c3aed,stroke-width:2px,color:#0f172a;
classDef business fill:#dcfce7,stroke:#16a34a,stroke-width:2px,color:#0f172a;
class A device;
class B,C access;
class D edge;
class E platform;
class F business;The point of this diagram is not that every project must include all five layers. The point is that every layer owns a different problem. Selection should follow the project gap, not the product name.
Three Common Combinations
1. A Small Device Connectivity Project: Serial Converter + Upper System
If a project includes only a few serial devices and the goal is to get data into an existing upper system, a serial converter is often enough for the first step. The design work should focus on protocol, distance, power, network conditions, interference, and future platform interfaces.
The tradeoff is limited scalability. As the fleet grows, point management, exception records, remote configuration, and permission control become harder. This pattern fits pilots or single-site retrofits better than long-term multi-project operations.
2. A Multi-Protocol Site: Serial Converter + Edge Gateway + Platform
When the site includes multiple protocols, device types, or unstable networks, a stronger combination is to use serial converters for point access, an edge gateway for protocol adaptation and buffering, and a platform for device management and operations.
This costs more, but the boundary is cleaner: the field layer stabilizes the data path, and the platform layer governs operations. For industrial sites, buildings, energy systems, cold-chain deployments, and distributed commercial equipment, this layering is usually more maintainable than forcing every capability into one device.
3. Local Intelligence: Edge Computing Box + IoT Platform
If a project needs on-site vision recognition, voice interaction, local AI inference, low-latency actions, or offline operation, the edge gateway becomes an edge computing node. The platform still owns device operations, permissions, and history, while the edge node owns low-latency processing and local autonomy.
This design is easy to overbuild. Edge intelligence is worth the cost only when latency, cloud data transfer, privacy boundaries, or offline availability are real constraints. Otherwise, stabilizing device onboarding and platform governance first is usually the stronger route.
When Not to Start with a Full Platform
If the project is only proving that one device type can connect, or if device count is small, protocols are stable, and data only flows to one internal system, a full IoT platform may be too heavy. A serial converter, lightweight gateway, or direct system integration may be more reasonable.
If the field network is unstable, protocols are not mapped, and the point list keeps changing, the main budget should not go into platform screens first. The better sequence is to stabilize field access, protocol mapping, data quality, and buffering. A platform can amplify stable data, but it cannot automatically fix an unstable data source.
Conversely, if the project already includes multiple customers, sites, roles, device types, alert loops, work orders, and long-term analytics, the team should not keep stitching isolated scripts and point tools together. That is when an IoT platform brings device operations back into one boundary.
Selection Checklist
Before purchasing products or designing the architecture, answer five questions:
- Are the field devices mainly serial, Ethernet, wireless, or multi-protocol?
- During network outages, is data loss acceptable, or is buffering required?
- After device onboarding, do you need registry, permissions, alerts, work orders, and reports?
- Do you need local AI, low-latency actions, or offline operation?
- Over the next 12 to 24 months, will device count, project count, or customer count grow significantly?
If only the first question matters, start with a serial converter. If the second and fourth questions matter, use an edge gateway or edge computing box. If the third and fifth questions matter, use an IoT platform. Most real projects are not a three-way choice; they combine layers by stage.
Where the Product Pages Fit
If you are modernizing legacy device connectivity, start with the product overview and then choose the relevant layer:
- Wireless access for serial devices: review the ZigBee serial port converter or Wi-Fi serial port converter.
- Field protocol adaptation, local buffering, or lightweight AIoT: review AIHub-Z3 or AIHub-Z5.
- Multi-project device operations, alerts, work orders, permissions, and analytics: review the ZedIoT IoT Platform.
Good selection is not about putting the most expensive device into the architecture. It is about letting each layer own the problem it is good at. Serial converters solve connectivity, edge gateways solve field complexity, and IoT platforms solve long-term operations. When those boundaries are clear, a device connectivity project is much more likely to scale beyond the pilot.
Image Sources
- Banner: generated with Codex built-in
gpt-image-2as a realistic device-connectivity deployment scene, then cropped toedge-gateway-vs-iot-platform-vs-serial-converter.webp. - Inline visual: generated with Codex built-in
gpt-image-2as a realistic field-layer deployment image, saved asedge-gateway-platform-layering-field-scene.webp.