The best engineers learn as much from failures as from successes. This hub documents common IoT project failures, their root causes, and how to avoid them.
The Setup: 500 Wi-Fi-connected inventory tags tracking pallets in a distribution warehouse.
What Went Wrong:
Expected: 99.9% uptime
Actual: 65% average connectivity
Peak hours: 30% packet loss
Result: Inventory accuracy dropped to 70%
Root Cause Analysis:
Factor
Issue
Impact
Channel Congestion
All devices on same channel
Collision rate exceeded 40%
AP Capacity
500 devices on 10 APs
50 devices/AP exceeded capacity
2.4GHz Interference
Forklifts had 2.4GHz video cameras
Constant interference
Roaming
Tags moved between APs frequently
5-second reconnection delays
Lessons Learned:
TipWi-Fi IoT Design Rules
Capacity: Plan for max 30 IoT devices per AP (not 50+)
Channels: Use 5GHz where possible, non-overlapping channels
Interference Survey: Conduct RF survey BEFORE deployment
Protocol Choice: Consider BLE mesh or Thread for moving assets
Roaming: Use 802.11r/k/v for fast roaming if available
Better Architecture:
ORIGINAL (Failed):
[500 Tags] --Wi-Fi--> [10 APs] --> [Server]
IMPROVED (Successful):
[500 BLE Tags] --> [50 BLE Gateways] --Ethernet--> [Server]
|
No interference
No roaming issues
$40 per gateway
The Setup: Consumer security cameras with “easy setup” shipped with default password admin:admin.
What Went Wrong:
Day 1: Cameras connected to internet
Day 3: Shodan indexed open ports
Day 7: Botnet scanning began
Day 14: 100,000 cameras compromised
Day 30: Used in DDoS attack (Mirai variant)
Root Cause Analysis:
Vulnerability
Impact
Default credentials
Trivial authentication bypass
No forced password change
Users never changed defaults
UPnP enabled
Automatic port forwarding exposed devices
No firmware signing
Malware persisted across reboots
Telnet enabled
Easy remote access for attackers
Lessons Learned:
TipIoT Security Minimums
Unique per-device credentials - printed on device, never defaults
Force password change on first use
Disable UPnP by default - require explicit enable
Signed firmware only - prevent malicious updates
Disable unnecessary services - no telnet, minimal ports
Figure 22.1: Architecture evolution from single-point-of-failure design to horizontally scalable architecture with load balancing, multiple brokers, message queue, and database sharding.
{fig-alt=“Comparison of failed single-broker architecture versus redesigned scalable architecture showing load balancer distributing to multiple brokers, message queue for decoupling, and database shards for horizontal scaling”}
Lessons Learned:
TipScalability Design Principles
Design for 10x current scale - growth surprises everyone
Horizontal scaling - add nodes, not bigger nodes
Stateless services - no server affinity
Shard data - no single database bottleneck
Queue everything - decouple producers from consumers