- ✓IoT application development typically involves working across multiple technical domains simultaneously, including embedded systems programming, networking, cloud backend development and sometimes mobile or web frontend development.
- ✓Platforms such as Arduino and Raspberry Pi have made IoT hardware development accessible to a much wider range of developers, providing affordable, programmable devices with extensive community support and documentation.
- ✓MQTT (Message Queuing Telemetry Transport) is one of the most widely used IoT messaging protocols, designed for lightweight, reliable message delivery over unreliable networks with minimal bandwidth and power consumption.
- ✓Cloud IoT platforms such as AWS IoT Core, Azure IoT Hub and Google Cloud IoT Core provide managed infrastructure for device registration, connectivity, data ingestion and device management at scale.
- ✓Testing IoT applications presents unique challenges because the full system includes physical hardware, real-world environmental conditions and network variability that are difficult to simulate accurately in a laboratory setting.
Listen to the full episode inside the course. Enrol to access all 80 episodes, plus assignments, tutor support and Student Finance funding.
Start learning →Alex: Welcome back to The Study Podcast. Today we're looking at the practical development of an IoT application. Sam, this is where the planning we discussed last time starts to become something real.
Sam: And it's where the multi-disciplinary nature of IoT becomes very apparent. You're working simultaneously in the physical and digital worlds: choosing hardware, writing firmware, configuring networks, building cloud backends and often designing user interfaces. It's genuinely one of the most technically demanding application domains.
Alex: Let's start at the hardware level. What does a typical IoT device consist of?
Sam: At the core there's usually a microcontroller or microprocessor that runs the software. For simple sensor devices, a low-power microcontroller like an ESP32 or an Arduino is sufficient. For more capable edge devices that need to run more sophisticated processing, you might use a Raspberry Pi or a more powerful industrial-grade embedded computer. Then there are the sensors: temperature sensors, accelerometers, GPS modules, cameras and many more. And the connectivity hardware: a WiFi chip, a cellular modem, a LoRa radio. The form factor is designed for the deployment environment, which might be anything from a circuit board in a waterproof enclosure to a custom-designed industrial device.
Alex: And the software on the device? What does that look like?
Sam: Firmware is the software that runs on the microcontroller. It initialises the hardware, reads from the sensors at appropriate intervals, handles the communication protocol and may perform some local processing before transmitting data. For microcontrollers, this is typically written in C or C++. For more capable edge devices, Python is increasingly common. The firmware needs to be reliable and power-efficient, which means careful attention to sleep modes and wake-up cycles for battery-powered devices.
Alex: How does the device communicate with the backend?
Sam: MQTT is the most widely used protocol for IoT messaging. It's a lightweight publish-subscribe protocol that works well over unreliable networks with limited bandwidth. The device publishes messages to topics on an MQTT broker, and the backend subscribes to those topics and receives the messages. Cloud IoT platforms like AWS IoT Core, Azure IoT Hub and Google Cloud IoT Core all provide managed MQTT brokers as part of their services, along with device registration, security certificates and device management capabilities.
Alex: And the backend and application layers?
Sam: The cloud backend receives the device data and processes it: storing it in a time-series database, running analytics, triggering alerts or automated responses, and providing data to user-facing applications. The application layer might be a web dashboard, a mobile app, an integration with an enterprise system or an automated control system. The choice of technologies for the backend is much like any web application: REST APIs, databases, cloud functions, notification services.
Alex: Testing IoT applications must be quite different from testing conventional software.
Sam: Very different. Unit testing the firmware logic is relatively straightforward. But integration testing the full system, including real hardware in a realistic environment with realistic network conditions, is much harder to automate. Physical prototyping and hands-on testing are essential parts of IoT development that can't be fully replaced by simulation. And testing the edge cases, what happens when the network drops out, when a sensor returns an unexpected value, when a device runs low on battery, is where a lot of the reliability comes from.
Alex: Excellent practical overview. Thanks, Sam. Next we'll look at evaluating IoT systems.