IoT Architectures Under Pressure: Flexibility (Part 4)

Democratizing IoT Development

In previous posts, we explored how IoT development doesn’t have to involve huge initial investments, ongoing expenses, or excessively costly devices. Instead, we can build an interconnected world through a more accessible and cost-effective approach.

Why democratic? Because by removing complexity, we empower anyone to design task-specific IoT devices without compromising usability or security.
This approach fosters experimentation, you can prototype using:

• Arduino + shields
• Raspberry Pi + hats
• Any development board at hand

By lowering barriers to entry, IoT innovation becomes more inclusive, allowing developers of all levels to create functional, secure, and efficient devices without massive investments.

In this post, we'll outline the general architecture, how it differs from mainstream IoT models, and the flexibility it offers. Since no single solution fits all, integration must be seamless, allowing diverse devices to operate within the same ecosystem while accommodating varied requirements.

Cinque...dieci...venti

Or, more appropriately, three, four, five, six and seven. If you are going to pick an architecture for your IoT projects, you could possibly have more layers than you can count.

I am not going to repeat here what you can find (better written) elsewhere in the literature. These are a good starting point which presents both an overview (if mostly focused around security) and some good references:

Burhan, M., Rehman, R. A., Khan, B., & Kim, B. S. (2018). IoT Elements, Layered Architectures and Security Issues: A Comprehensive Survey. Sensors (Basel, Switzerland), 18(9), 2796.

Schiller, E., Aidoo, A., Fuhrer, J., Stahl, J., Ziörjen, M., & Stiller, B. (2022, May 1). Landscape of IoT security. Computer Science Review. Elsevier Ireland Ltd.

Why am I not going to focus on this? Because, mostly, for simple IoT devices these details should not matter and it's too easy to get them wrong. Leave them to someone else and focus on the domain you know better: your core business.

A Simplified Approach to IoT

For simple IoT devices certain implementation details aren’t critical. Worrying about every technical aspect can add unnecessary complexity. Instead, delegating these challenges to a dedicated team allows developers to focus on the core functionality without getting overwhelmed.

Intent

To minimize device costs while ensuring fast and easy development. The goal is to avoid the complexity (and expense) of deploying a network-attached device.

Firmware-less is NOT:

• A replacement for any of the architectures discussed earlier. Something needs to be connected to the Cloud, manage security, updates, UIs and data collection but, ideally, it's not your water quality monitoring device!
• A default solution for every IoT project: it’s context-dependent.
• A standalone approach unless an Open Standard is adopted across vendors (or you control both the devices and the hub).

Motivation

As outlined in the first post of this series, IoT development often leads to spiraling costs and overwhelming technical burdens, even before delivering actual value to the business.

Applicability

This approach isn’t a one-size-fits-all solution, it works best when:

• The device already follows a traditional design model.
• Real-time operations are not a requirement.

I'm trying to limit the scope of these posts to Smart Homes but the very same principles apply to a variety of applications. Some devices that could easily benefit from this approach are: thermostats, robot cleaners, alarm systems, AC units, water quality monitoring, air quality monitoring, irrigation systems, structural building monitoring and smart meters.

However, the flexibility of this method allows it to be integrated into various system architectures, depending on specific needs.

Structure

As covered in previous posts, the idea is simple:

• Keep devices as minimalist as possible, avoiding unnecessary firmware complexity.
• Shift all logic to a centralized hub, pooling resources efficiently across connected devices.

An Example

This approach supports a range of heterogeneous devices, allowing integration without requiring every device to be fully firmware-less.

Imagine this potential setup:

• Firmware-less hub – A mini-computer running Linux, connected to Amazon AWS, Microsoft Azure, Google Cloud, or another provider for IoT services like updates and data collection.
• Firmware-less thermostat – Uses a temperature sensor and actuator, with all logic, UI, and smart features handled by the hub. This is the example we're going to pick, starting with the next post.
• AC unit with a tiny MCU – UI and smart features provided by the hub.
• Air quality monitoring system with a tiny MCU – Alerts and additional intelligence processed by the hub.
• Garden irrigation system – Weather forecast, presence detection, and automation managed by the hub.
• Fully automatic coffee machine with a tiny MCU – Advanced features (like brewing coffee after your morning alarm) handled by the hub.
• Alarm system with a tiny MCU – Remote monitoring and alerts managed by the hub.
• Video doorbell with a small mini-computer – Integrates with the alarm system, remote monitoring, and smart automation via the hub.

This setup demonstrates that devices don’t need to be entirely firmware-less to integrate into the ecosystem. Even devices using other IoT services can be incorporated by exposing their services, ensuring seamless communication across platforms.

What About the Hub?

Investing in a smart hub offers compelling business advantages:

• Focused Platform, Not Fragmented Devices – Instead of competing to build the "best" smart device in every category, you create a versatile, centralized system that enhances multiple devices seamlessly.
• Stable & Predictable Revenue Model – A subscription-based service keeps users' systems up-to-date while continuously delivering new features.
• Data-Driven Insights & Optimization – With user-permissioned data from diverse sensors across multiple vendors, you can:
  • Provide advanced functionalities and automation.
  • Offer valuable analytics and predictive insights.
  • Improve user experience, security, and device efficiency.

A firmware-less hub is not just about convenience: it creates a sustainable ecosystem that benefits both users and developers while establishing a scalable, revenue-generating foundation.

We are going to try to develop a basic reference implementation (which is not dedicated only to IoT applications) in C#, check the GitHub repository for more info.

What's Next?

I’ve written (more than) enough to illustrate the concept; now it’s time to bring it to life! In the next post, we’ll dive into coding a minimal (but fully functional) firmware-less smart thermostat.