Building Embedded IoT Systems with ESP32, ESP-IDF, Arduino, and MQTT

My web and IoT work grew side by side: Laravel and WordPress projects on one desk, microcontroller-based electronics on the other. That combination changed how I see connected devices. Firmware is not the small program you add after the “real” product exists. It decides whether the hardware behaves like one system, how it fails, how much power it wastes, and whether the next feature is a contained change or a new pile of exceptions.

That is why I write the programs myself. In the embedded systems and IoT work I do today, that can mean C on an ESP32 with ESP-IDF, an Arduino-based prototype, or very small ATtiny and PIC controllers on custom boards. The language and chip change; the point does not. If I cannot explain what every node does when its input is strange, I do not yet understand the device well enough.

Embedded design tempts people to solve every node with the most capable board on the shelf. I go the other way: start with the job, then choose the smallest controller that can do it without lying about timing, memory, power, or pins. A sensor node that only reports a state does not need the same silicon as a connected controller. Using less chip is not cheapness for its own sake; it is how a kit stays affordable, power-friendly, and understandable.

Arduino is useful in that ladder because it gets a physical idea in front of you quickly. But a prototype is evidence, not automatically the final architecture. When a device needs richer connectivity, stronger structure, or tighter control, the ESP32 and ESP-IDF earn their larger footprint. The craft is knowing which rung the product is actually on instead of treating every problem as either a demo or a miniature Linux computer.

The Norasys smart-home kit is the clearest example of that approach. It is a complete package for home security and automation, built from scratch apart from the standard communication protocols: devices, boards, and firmware. Most nodes stay deliberately small: nRF24L01 radios carry wireless traffic, ATtiny13A or PIC microcontrollers run sensors and actuators, and MQTT ties the system together at the messaging layer.

The important part is not the component list. It is that the nodes share rules. Because I wrote the firmware instead of assembling unrelated modules, messages, failure behaviour, and future extensions can stay coherent across the kit. That coherence also connects the hardware to the public Norasys business rather than leaving it as a box of clever parts: solar, backup power, and smart-home work are one customer problem, so the engineering should read that way too.

The Darmanjo NPWT devices sit at the other end of the same spectrum. They are portable negative-pressure wound-therapy units built around the ESP32, pressure sensors, and custom electronic boards. My part is engineering only: sensing and controlling pressure reliably, designing boards around the real constraints, and writing firmware in C with ESP-IDF.

Medical-adjacent hardware makes vague behaviour expensive. A sensor can read unexpectedly; power can behave badly; the outside world does not care about your happy path. Small, well-understood firmware and careful board design are how the device stays predictable under those conditions. This is the same instinct I described for agent systems in Rust: put the variable thing inside a deterministic frame, except here the variable thing is not a model. It is physics.

A connected device spends its life in the bad minute: a message does not arrive, a radio link gets noisy, a sensor reports nonsense, or power drops at exactly the wrong time. Good firmware therefore spends as much attention on boundaries as on features. What is a valid reading? What should a node do when it cannot reach the rest of the system? Which state is safe to keep, which state must be rebuilt, and what should never happen twice just because a message repeated?

MQTT helps because it gives the system an explicit messaging layer instead of every device improvising its own conversation. But a protocol is not a design. The design is the set of decisions above it: message meaning, node responsibility, defaults, and recovery. That same separation appears in the software side of Darmanjo, whose platform I built with the SvelteKit stack. Whether the client is a browser or a board, unclear boundaries eventually send the bill to operations.

Maintainability follows from the same separation. Board-specific facts — pins, sensors, radio behaviour, and controller limits — should stay near the hardware that owns them. The rules above them should speak in product terms: this node reports, that controller decides, this actuator changes state. When a board revision arrives or a home needs another capability, that structure tells you which layer should change and which promises must stay intact. Firmware that mixes every concern into one loop may pass today’s test, but it makes tomorrow’s hardware change a behavioural rewrite.

My order of questions is stable. What does this node sense or control? How much power and money can each unit spend? Does it need direct connectivity, or should a smaller radio node report into a larger system? What happens when communication disappears? Only then do I choose between a tiny controller, an Arduino-shaped prototype path, or ESP32 with ESP-IDF. Starting from the chip catalogue produces impressive prototypes and expensive products.

If you need a connected device designed as a system — board, firmware, messaging, and the software around it — that end-to-end view is the work I do under embedded systems & IoT. The public examples are the Norasys kit and the NPWT hardware; the wider story starts on my résumé.