By the end of this section, you will be able to:
Before diving into this section, you should be familiar with:
Think of IoT platforms like app stores + operating systems for smart devices.
Just like your phone needs iOS or Android to run apps, your IoT devices need platforms to connect, communicate, and be managed. Platforms give you pre-built tools—authentication, device management, data storage—that would take months to build from scratch.
Three types of platforms you’ll encounter:
| Platform Type | What It Does | Example |
|---|---|---|
| Cloud Platform | Connect devices to internet, store data | AWS IoT, Azure IoT Hub |
| Edge Platform | Process data locally before sending to cloud | Home Assistant, EdgeX |
| Development Framework | Tools for building IoT applications | Node-RED, Arduino IDE |
Start simple: For hobbyists, Node-RED and Home Assistant are friendly entry points. For production, consider AWS IoT Core or Azure IoT Hub.
“Hardware without software platforms is like a phone without an app store!” said Max the Microcontroller. “IoT platforms handle all the plumbing – connecting devices, storing data, managing updates, and keeping everything secure. You just focus on building your application.”
Sammy the Sensor asked about options. “There are three main types,” Max explained. “Cloud platforms like AWS IoT Core and Azure IoT Hub run in the cloud and handle millions of devices. Application frameworks like Node-RED and Home Assistant make it easy to build IoT apps with visual tools. And edge platforms like EdgeX process data locally before sending it to the cloud.”
Lila the LED shared a tip. “For beginners, start with Node-RED. You drag and drop blocks to connect sensors, process data, and trigger actions – no heavy coding required. For a smart home, Home Assistant integrates with over 2,000 device types right out of the box.” Bella the Battery added the production perspective. “When you are ready to scale up to thousands or millions of devices, cloud platforms provide the infrastructure. But choose carefully – switching platforms later is expensive. Look for ones that support standard protocols like MQTT so you are not locked in.”
This section covers the complete IoT software platform landscape across four focused chapters:
Major cloud providers offer managed IoT services for device connectivity, data processing, and analytics:
Higher-level tools for rapid IoT application development:
Local processing for reduced latency and offline operation:
Fleet management, open-source alternatives, and selection criteria:
Compare cloud platform costs vs self-hosted MQTT for your IoT deployment:
Key Insight: Below ~36 million messages/month, cloud platforms are often cheaper due to free tiers. Above 100 million messages/month, self-hosted can save $1,000+/month, but requires DevOps expertise for setup, security, monitoring, and maintenance.
| Scale | Recommended Approach |
|---|---|
| < 100 devices | Open-source (Home Assistant, ThingsBoard) or cloud free tiers |
| 100-10,000 | Managed cloud platforms (AWS IoT, Azure IoT) |
| > 10,000 | Enterprise cloud or custom infrastructure |
RTOS provides a structured foundation for complex IoT firmware, enabling reliable multi-tasking with predictable timing and resource management.
Modern IoT software platforms span edge to cloud, with appropriate frameworks for each tier’s resource constraints and capabilities.
Platform Layer Dependencies:
┌─────────────────────────────────────┐
│ Application Layer │
│ (Node-RED, Home Assistant) │
└──────────────┬──────────────────────┘
│
┌──────────────▼──────────────────────┐
│ Edge Computing Layer │
│ (Greengrass, IoT Edge, EdgeX) │
└──────────────┬──────────────────────┘
│
┌──────────────▼──────────────────────┐
│ Cloud Platform Layer │
│ (AWS IoT, Azure IoT Hub, MQTT) │
└──────────────┬──────────────────────┘
│
┌──────────────▼──────────────────────┐
│ Device Layer │
│ (Firmware, RTOS, protocols) │
└─────────────────────────────────────┘Related Concepts:
Common Misconceptions:
Sending raw sensor readings at maximum frequency consumes unnecessary bandwidth and storage, and can cause broker backpressure that drops messages from other devices. Apply edge-side dead-band filtering and send only meaningful updates; reserve full-rate data for local debug sessions.
Publishing all sensor types to one flat topic prevents selective subscriptions, makes stream processing complex, and inhibits per-sensor access control. Use a structured topic hierarchy (e.g. iot/{deviceId}/{sensorType}) that enables selective consumption and per-topic ACL policies.
When multiple clients update the device shadow simultaneously without conflict resolution, the device receives contradictory desired-state updates and enters an oscillating state. Implement optimistic locking with version numbers on shadow updates and define a clear precedence order for conflicting state sources.
Cloud Platforms:
Edge & Local Processing:
Development Tools:
Device Management:
Project 1: Platform Cost Calculator
Difficulty: Beginner Time: 1 hour Equipment: Spreadsheet software (Excel, Google Sheets)
What You’ll Build: A cost comparison calculator for different IoT platforms.
Steps:
devices × messages/day × 30What to Observe:
Extension Challenge: Add labor costs - DevOps time for self-hosted vs. zero for managed cloud
Project 2: MQTT Platform Migration
Difficulty: Intermediate Time: 3 hours Equipment: Raspberry Pi or ESP32, MQTT broker (Mosquitto), ThingsBoard
What You’ll Build: An abstraction layer that allows switching MQTT backends without changing device firmware.
Steps:
What to Observe:
Extension Challenge: Implement dual-publish mode - send to both primary and backup broker simultaneously
Project 3: Edge vs Cloud Latency Test
Difficulty: Intermediate Time: 2 hours Equipment: ESP32, local MQTT broker, cloud MQTT service, LED
What You’ll Build: A button-to-LED latency measurement comparing local vs cloud processing.
Setup:
Steps:
What to Observe:
What to Learn: When is edge processing essential vs. nice-to-have?
Development:
Hardware Platforms:
Architecture:
Protocols:
Scenario: A company built their smart home product on a proprietary IoT platform (fictional “CloudConnect”) in 2020. In 2023, CloudConnect raised prices from $0.10/device/month to $2.00/device/month. With 10,000 deployed devices, monthly costs jumped from $1,000 to $20,000 — unsustainable for a $39 product. The team decides to migrate to self-hosted Mosquitto MQTT + ThingsBoard.
Step 1: Analyze the Existing Architecture
Current (CloudConnect proprietary):
// Device firmware (locked to CloudConnect)
#include <CloudConnect.h>
CloudConnect cloud("device-id-12345");
void loop() {
float temp = readSensor();
cloud.send("temperature", temp); // Proprietary API
cloud.loop(); // Proprietary event handling
}Backend:
Problems:
Step 2: Design the Open-Source Replacement
New architecture (Mosquitto MQTT + ThingsBoard):
Device firmware (rewritten for MQTT):
#include <WiFi.h>
#include <PubSubClient.h> // Standard MQTT library
WiFiClient espClient;
PubSubClient mqtt(espClient);
void setup() {
WiFi.begin(SSID, PASSWORD);
mqtt.setServer(MQTT_BROKER, 1883);
mqtt.connect("device-12345", MQTT_USER, MQTT_PASS);
}
void loop() {
float temp = readSensor();
// Publish to standard MQTT topic
String payload = "{\"temperature\":" + String(temp) + "}";
mqtt.publish("v1/devices/me/telemetry", payload.c_str());
mqtt.loop();
}Backend:
Step 3: Execute the Migration
Phase 1: Add OTA update to existing firmware (if possible) - Push OTA update with new MQTT firmware to all devices - If no OTA: Devices must be physically updated (mail USB programmer to customers)
Phase 2: Data export and migration
Phase 3: Mobile app rewrite
Step 4: Cost Analysis
Old (CloudConnect):
New (Mosquitto + ThingsBoard self-hosted):
Migration costs (one-time): - Firmware rewrite: 80 hours × $100/hr = $8,000 - Backend setup and testing: 40 hours × $100/hr = $4,000 - Data export scripts: 20 hours × $100/hr = $2,000 - Mobile app update: 60 hours × $100/hr = $6,000 - Total migration cost: $20,000
Payback period: $20,000 / ($20,000 - $55) = 1 month
After 1 month, the company saves $19,945/month forever.
Step 5: Lessons Learned
What went wrong initially:
What they should have done from day 1:
The abstraction pattern (prevents future lock-in):
// backend.h (abstraction interface)
class IoTBackend {
virtual void connect() = 0;
virtual void sendData(const char* key, float value) = 0;
};
// mqtt_backend.cpp (MQTT implementation)
class MQTTBackend : public IoTBackend {
void connect() { mqtt.connect(...); }
void sendData(const char* key, float value) {
mqtt.publish(topic, json);
}
};
// main.cpp (use abstraction)
IoTBackend* backend = new MQTTBackend();
backend->connect();
backend->sendData("temperature", temp);
// Switching backends later: just change the implementation, not the application codeKey takeaway: The convenience of a proprietary platform (CloudConnect) becomes a trap when: (1) vendor raises prices, (2) vendor shuts down, or (3) vendor changes terms. Always use standard protocols (MQTT, HTTP) with abstraction layers to maintain the ability to migrate.
| Factor | Cloud Platform (AWS IoT, Azure) | Self-Hosted (Mosquitto, ThingsBoard) |
|---|---|---|
| Setup time | 1-2 days (managed service) | 1-2 weeks (install, configure, secure) |
| Operational burden | None (vendor manages) | High (updates, backups, monitoring) |
| Scalability | Automatic (millions of devices) | Manual (add servers as needed) |
| Cost at 100 devices | $10-50/month | $10-20/month (small VPS) |
| Cost at 10,000 devices | $1,000-5,000/month | $100-500/month (larger VPS + bandwidth) |
| Cost at 1M devices | $50,000-200,000/month | $5,000-20,000/month (cluster + engineering) |
| Vendor lock-in risk | High (proprietary APIs) | None (open-source, portable) |
| Data ownership | Vendor holds data | You own data completely |
| Expertise required | Low (managed service) | High (DevOps, security, databases) |
| Uptime SLA | 99.9%+ guaranteed | You manage (no SLA) |
Use cloud platform when:
Use self-hosted open-source when:
Hybrid approach (common for mature products): 1. Year 1: Cloud platform (rapid development, validate product-market fit) 2. Year 2: Hybrid (keep cloud, add self-hosted for cost savings on high-volume data paths) 3. Year 3+: Primarily self-hosted (cloud as backup/disaster recovery)
Example progression:
The Problem: A developer builds an IoT product using AWS IoT Core free tier (250,000 messages/month free). During prototyping with 10 test devices, they never exceed the free tier. The product launches, and within 2 weeks, they have 500 paying customers. Month-end arrives, and AWS bills them $8,500.
What went wrong:
Free tier limits (AWS IoT Core example): - 250,000 messages/month (inbound/outbound combined) - After free tier: $1.00 per million messages
Actual usage:
Cost calculation:
Hidden costs missed:
Actual monthly AWS bill: $21.35 + $3.20 + $27.00 + $0.97 + $2.99 + $4.32 + $27.00 + $2.50 + $0.50 = $89.83
Still not $8,500. What really happened?
The killer: The developer didn’t realize they were sending one message per second (not per minute) due to a bug in retry logic. The actual message rate was: - 500 devices × 60 seconds × 60 minutes × 24 hours × 30 days = 1.296 billion messages/month
Corrected cost: 1,296 million messages = 1,296 × $1.00 = $1,296 (just for IoT Core) Plus all the other services scaling proportionally: $8,500 total bill
The fix (cost controls for production):
const int MIN_SEND_INTERVAL = 60000; // 1 minute minimum
unsigned long lastSend = 0;
void loop() {
if (millis() - lastSend >= MIN_SEND_INTERVAL) {
sendToCloud(data);
lastSend = millis();
}
}Lesson: Free tier is for prototyping, not production. Always calculate production costs based on actual device count and message frequency before launching.
| If you want to… | Read this |
|---|---|
| Learn about data visualisation for connected devices | Data Visualisation Dashboards |
| Understand security for cloud-connected prototypes | Privacy and Compliance |
| Explore full-stack IoT architecture patterns | Application Domains Overview |