Pick a depth. Each prompt opens in your AI pre-loaded with the lesson. Click a row to preview the prompt.
The instinct to 'make it smart' is usually wrong. Every wireless link you add to a device adds antennas, certifications, power draw, software complexity, security surface, and a class of failures (Wi-Fi down, captive portals, expired certs, IPv6 weirdness) that simply don't exist for a wired or standalone product. Before you commit, you must answer four questions: what data must move, in which direction, with what latency tolerance, and what happens when the link is down? If 'nothing happens' or 'the device buffers and uploads later' aren't acceptable, you have a much harder product to ship — possibly one that shouldn't be connected at all.
A decision framework for whether a feature should be online at all.
For every feature you're tempted to put 'in the cloud', answer ALL FOUR:
1. WHAT DATA MOVES?
a. Sensor telemetry (low-volume, append-only)?
b. Commands (low-volume, real-time)?
c. Media (video, audio — high bandwidth)?
d. Software updates (occasional, large)?
2. WHICH DIRECTION?
• Uplink only (device → cloud)? Easy. MQTT publish, batched HTTPS.
• Downlink only (cloud → device)? Need a persistent connection or polling.
• Bidirectional with real-time? Hard. WebSocket / MQTT subscribe.
3. WHAT LATENCY IS ACCEPTABLE?
< 50 ms — control loops, AR/VR, gaming. Use wired or local network.
< 500 ms — voice commands, dashboards. Wi-Fi / cellular fine.
< 5 s — most consumer IoT (light switch responds slowly = bad UX).
minutes-hours — telemetry, weather stations, soil monitors.
days — cattle tags, GPS trackers on shipping containers.
4. WHAT HAPPENS WHEN THE LINK IS DOWN?
a. Acceptable: device buffers locally, uploads on reconnect.
Required: local NVS/flash for the buffer; backoff and resume code.
b. Acceptable: feature degrades but device still functions.
Required: local fallback logic. Hardest path to test.
c. Not acceptable: feature simply doesn't work.
Required: you may not have an IoT problem — you have a connectivity problem.
Re-think whether the connection should exist at all.
A LIGHTBULB EXAMPLE
───────────────────
"Smart" lightbulb: turn on via app.
Latency: < 1 s. Bandwidth: tiny. Direction: downlink.
Offline: if my Wi-Fi is down, can I still flip the wall switch?
If NO, you've made the customer's house worse than dumb bulbs.
If YES, the connectivity is purely additive — ship it.