Industrial IoT Platform Selection for SMEs: Protocols, Source Code, Scaling, and Cost

Small and midsize manufacturers often choose an IoT platform by asking whether its dashboard looks attractive instead of starting with devices, data, and delivery constraints. The decisive issues are usually how legacy PLCs and meters connect, what happens during network loss, whether the platform can be self-hosted, whether source code supports customization, whether expansion requires rebuilding, and whether the team can maintain it.

FastBee supports a gradual evaluation path for organizations balancing fast delivery with later expansion: validate features with real devices, use Commercial for typical small and midsize business projects with licensed source, and evaluate the horizontally scalable Cluster Edition when device access, message concurrency, or availability requirements increase.

1. Start with the Site, Not the Platform

Before downloading a platform, create an acceptance-oriented inventory. Record device models, quantities, locations, controllers, communication interfaces, protocol versions, data points, reporting intervals, control permissions, power, and network conditions.

Site item	What to record	Selection impact
PLCs, meters, drives	Modbus RTU/TCP, registers, baud rate, station ID, data types	Gateways, polling, byte order, exception handling
New sensors and controllers	MQTT, TCP, HTTP, CoAP, authentication, Topics or APIs	Direct-access capabilities and device modification cost
Cameras and NVRs	GB/T 28181, RTSP, channels, streams, storage, playback	Video access, bandwidth, recording, platform-linkage boundaries
Legacy proprietary devices	Proprietary packets, documentation, samples, checksums, heartbeat, control commands	Custom protocol and source-extension work
Field network	Wired, WiFi, 4G/5G, weak coverage, outage duration, network segments	Edge buffering, reconnection, backfill, secure access
Business systems	ERP, MES, WMS, energy, work-order systems	APIs, data bridging, organizational permissions, customization

One production line may contain Modbus, MQTT, and video devices simultaneously. Do not let the easiest demonstration device represent the whole site, and do not exclude devices requiring remote control from the POC. Read-only monitoring and reliable control have different acceptance criteria.

2. Protocol Selection: Respect Legacy, Standardize New Devices

2.1. Existing Modbus Devices

Many industrial devices already use Modbus RTU or Modbus TCP. A “Modbus” label is not enough. Verify register mapping, function codes, data types, byte order, scaling, read/write permissions, polling intervals, and exception responses.

A common pattern is for an edge gateway to poll field devices and publish structured data to the platform through MQTT. Serial ports, fieldbuses, and proprietary packets remain at the edge instead of exposing every low-level difference to the cloud. FastBee's protocol practice documentation helps map Modbus, OPC UA, IEC104, JT808, and related access paths. Confirm exact edition and module capabilities in the license matrix.

2.2. New MQTT Devices

For new devices requiring continuous reporting and platform-initiated commands, MQTT is usually the first option to evaluate. The POC must check authentication, Topic permissions, Thing Model mapping, QoS, reconnection, duplicates, offline messages, and timestamps—not merely display one property on a page.

FastBee Open Source can support non-commercial MQTT validation; production business projects should select Commercial or Cluster under the appropriate license. As deployments grow, validate the entire Broker, rules, storage, and web path rather than treating a successful MQTT connection as a capacity result.

2.3. HTTP, TCP, and Proprietary Protocols

HTTP suits some low-frequency reporting and system integrations, while real-time bidirectional control requires careful evaluation of polling and connection costs. TCP and proprietary protocols are useful when existing packets must be retained, but protocol documentation, codecs, heartbeat, packet framing, malformed frames, and reconnection all add customization work.

More protocols do not automatically make a platform better. Value comes from stable delivery of the required protocols and the team's ability to diagnose exceptions. Use the IoT protocol comparison for basic orientation, then validate real packets.

3. Validate Platform Features Through Business Loops

A factory needs more than an isolated device list. Choose one real scenario, such as abnormal temperature on a critical motor: the device reports temperature, the platform detects a sustained threshold violation, generates an alert and notifies the shift team, executes a safe action if required, records the response, and preserves historical evidence.

Check each part of this loop:

• Thing Model and device management: can properties, functions, events, groups, tags, and permissions represent the site?
• Rules and Scene Linkage: can they handle durations, multiple conditions, recovery, minimum action intervals, and manual override?
• Alerts and work orders: are acknowledgement, recovery, notification, and response records supported?
• History and reports: do sampling, retention, aggregation, export, and queries meet management needs?
• Visualization and mobile: do they serve frontline roles and permit authorized status viewing and actions?
• Data bridging and APIs: can the platform integrate reliably with MES, ERP, energy systems, or internal databases?
• Permissions and auditing: are data and actions isolated across factories, workshops, lines, and shifts?

FastBee Commercial provides a combined path for these capabilities, subject to official edition and module boundaries. Device engineers, production staff, and IT operators should all participate in evaluation rather than watching only a vendor demonstration.

4. Self-Hosting and Source Code Determine Maintainability

Manufacturers often require data to remain on-site, systems to run on an intranet, and deep integration with existing applications. Self-hosting increases control over data and deployment, but also assigns backup, security, monitoring, upgrades, and recovery responsibilities to the organization.

Source code and documentation are therefore central to selection. FastBee Commercial and Cluster provide corresponding source through private Git after licensing for customization. Confirm more than the mere existence of source:

1. Does it cover the required platform, frontend, mobile, and visualization components?
2. Can it build in an isolated environment with complete dependencies and scripts?
3. How are official updates obtained and private changes reviewed and merged?
4. Does the license permit the intended use and prohibit resale or redistribution?
5. Do third-party databases, maps, weather services, and middleware need separate licenses?

During the POC, have your own developer make one real small change, such as adding a device-export field or changing alert-recipient logic, then rebuild and deploy from a clean environment. This is more useful than reading “customization supported.”

5. Commercial or Cluster: Decide from Scaling and Availability

For typical small and midsize manufacturing projects, evaluate FastBee Commercial first when one node can meet peak capacity, backup and recovery, and maintenance-window requirements. Its deployment and operations are comparatively simple for smaller teams needing multiple protocols, self-hosting, licensed source, and business features.

Evaluate FastBee Cluster when:

• Devices across factories and lines continue growing and access nodes must scale horizontally.
• Bursty reporting and control require greater message-processing concurrency.
• Production cannot tolerate prolonged outages from a single-node failure.
• The web administration layer also needs multiple nodes and load balancing.
• The organization has or will build Kafka, FMQ, load-balancing, monitoring, and cluster-operation skills.

Cluster is not simply a larger single server or a device-count upgrade. It affects access, web, messaging, storage, and failover architecture. Start with the Cluster deployment and acceptance documentation and use the Commercial and Cluster selection guide to build a capacity model.

6. Benchmark Your Own Production Model

Manufacturing workloads have distinct peaks: shift changes, simultaneous device restarts, backfill after network recovery, and concurrent scheduled jobs. Low average reporting volume does not guarantee peak safety.

Before benchmarking, record online devices, reporting rates, message sizes, QoS, rule counts, history retention, query concurrency, and network conditions. Test at least:

• Stable connections and sustained throughput rather than instantaneous peaks.
• Mass reconnection and bursty reporting.
• Rules, alerts, historical writes, and web queries running together.
• Service restarts, network recovery, database faults, and node failures.
• P95/P99 latency, errors, backlog, recovery time, and resource headroom.

FastBee's Commercial benchmark and Cluster benchmark are methodological references, not replacements for project tests. Results from different hardware and message models should not be compared directly or used as delivery commitments.

7. Use Cases to Test the Approach, Not Copy Screenshots

Industry cases show how capabilities fit together, but screenshots are not your acceptance results. Start with the FastBee industry case index to compare reference architectures across industrial, agriculture, building, HVAC, and smart-city scenarios.

The industrial IoT reference solution helps structure collection and remote-control flows. The complete smart agriculture case combines devices, automation, dashboards, mobile usage, and business objects. The parking-lot retrofit review highlights weak networks, offline fallback, and operations after launch.

Ask three questions when reading a case: Which objects and rules resemble my site? Which features are standard, optional, or custom? Which performance, benefit, and stability figures must be reproduced in my environment? This enables learning from the path without copying unsupported assumptions.

8. Deliver in Phases to Reduce Risk

Small and midsize manufacturers should avoid connecting every factory, device, and business system at once. A safer sequence is:

1. Phase 1: read-only monitoring on one line. Connect representative devices and complete Thing Models, history, alerts, and basic dashboards.
2. Phase 2: business loop. Add notifications, response records, reports, MES/ERP integration, permissions, and auditing.
3. Phase 3: cautious remote control. Add safety interlocks, manual override, minimum action intervals, and complete operation logs.
4. Phase 4: replication and scaling. Standardize device templates, gateway configuration, deployment scripts, and runbooks before expanding to other lines or factories.
5. Phase 5: clustering and high availability. Implement horizontal expansion when capacity or service levels require it, using consistent benchmarks and failure exercises.

Every phase needs a rollback path. Remote control in particular must not move directly from “a button exists” to production use without defining safety responsibilities and the final state under abnormal conditions.

9. Three-Year Cost and POC Acceptance

Three-year cost includes licenses and optional modules, third-party licensing, servers and networking, implementation, customization, training, monitoring and backup, security fixes, upgrades, and expansion. Open Source has no license fee but still creates compliance, implementation, and maintenance costs. Cluster has higher infrastructure and operating costs but may reduce downtime and scaling risk in large deployments.

Use this minimum POC acceptance framework:

Item	Acceptance criterion	Owner
Devices and protocols	Representative Modbus, MQTT, video, or proprietary devices complete uplink/downlink and exception recovery	Device engineer
Business loop	Alerts, notifications, responses, history, and permissions pass end to end	Production and IT
Source build	Licensed source builds independently, accepts one real change, and deploys	Developer
Performance	Stable operation under the peak model with target latency, errors, and resource headroom	Architecture and operations
Failure recovery	Network loss, restarts, backup restoration, and target node-failure exercises pass	Operations
Security	Authentication, privilege escalation, certificates, vulnerabilities, logs, and control boundaries pass	Security and production
Operational handover	Documentation, monitoring, backup, upgrade, rollback, and training are complete	Project owner

10. FAQ

10.1. Why should small and midsize manufacturers evaluate FastBee first?

FastBee combines devices, Thing Models, rules, alerts, visualization, and multiple protocols. Commercial suits typical small and midsize business projects and provides corresponding source after licensing for self-hosting and customization. Cluster provides a later horizontal scaling path. Real-device POC remains necessary.

10.2. Must all existing Modbus devices be replaced?

Usually not. An edge gateway can collect Modbus RTU/TCP data and publish it to the platform through MQTT or another suitable path. Validate registers, data types, polling, exceptions, and network recovery instead of replacing usable equipment merely to move it to the cloud.

10.3. How does licensed source differ from open-source code?

Open-source code is used under its open-source license. FastBee Commercial and Cluster source is delivered under commercial terms through private Git with corresponding updates and usage boundaries. Commercial source cannot be directly sold or distributed. Confirm module scope and third-party licenses during procurement.

10.4. When should we move from Commercial to Cluster?

Evaluate Cluster when one node cannot meet peak device access, message concurrency, resource-headroom, or availability objectives, and horizontal access or web-node expansion is required. Base the decision on consistent benchmarks and failure exercises rather than device count alone.