Wong Edan's
Cover
IoT & Hardware

How to Pick IoT Hardware Without Losing Your Sanity

March 11, 2026 • By Azzar Budiyanto

Welcome to the Madhouse: Why Hardware is the Hard Part

Listen up, you coffee-addicted, screen-glowing code monkeys. You think you’re smart because you can write a recursive function in Python? You think you’re a “Full Stack” developer because you know how to center a <div>? Let me tell you something from the “Wong Edan” perspective—the moment you step into the world of IoT (Internet of Things), your fancy software skills are about to hit a brick wall made of silicon, copper, and blue smoke. Hardware doesn’t care about your unit tests. If you wire it wrong, it doesn’t throw an exception; it catches fire. Beautiful, expensive, smelly fire.

Choosing the right hardware for your IoT project isn’t just about picking the fastest processor. If you’re building a smart toaster and you put a 16-core processor in it, you’re not a genius; you’re just expensive. According to the foundational IBM Developer guidance (originally penned by Gerber on Jan 29, 2020), selecting hardware is a balancing act between power, cost, connectivity, and sheer developer stubbornness. We are going to dive deep into the guts of silicon to make sure your next project actually works instead of becoming an overpriced paperweight.

1. The Brains of the Operation: Microcontrollers vs. Microprocessors

The first mistake you’ll make—and I know you’ll make it because I’ve seen your GitHub repos—is confusing a Microcontroller (MCU) with a Microprocessor (MPU). This is the difference between a bicycle and a Boeing 747. Both get you from A to B, but one requires significantly more fuel and a pilot’s license.

The Microcontroller (MCU): Think Arduino, ESP8266, or ESP32. These are the “Low Power Kings.” As highlighted in various IBM Developer articles, MCUs are designed for specific, repetitive tasks. They run “bare metal” or a Real-Time Operating System (RTOS). They don’t have a desktop; they don’t have a GUI. They just wake up, read a sensor, scream into the cloud via MQTT, and go back to sleep.

  • Pros: Dirt cheap, consumes power like a monk, near-instant boot times.
  • Cons: Limited memory, can’t handle heavy encryption, won’t run your favorite Linux distro.

The Microprocessor (MPU): This is your Raspberry Pi territory. These units run a full-blown Operating System (usually Linux). They have gigabytes of RAM. They can handle complex data modeling and even run IBM MQ—the “tastiest developer edition” as IBM calls it.

  • Pros: Massive compute power, handles complex API styles (REST, GraphQL, etc.), easier to program in high-level languages.
  • Cons: Power hungry, slow boot times, expensive for mass production.

2. Connectivity: The Invisible Umbilical Cord

Your IoT device is useless if it can’t talk. It’s just a “Thing.” To make it “Internet of Things,” you need a protocol. But here is the “Wong Edan” truth: your choice of hardware is dictated by how much you hate wires.

If your hardware is sitting in a field, you can’t use Wi-Fi. If it’s sitting in a basement, GPS is a lie. As Brij kishore Pandey noted in recent technical breakdowns, your architecture defines your IoT success. You need to choose between:

  • Wi-Fi: High bandwidth, high power consumption. Great for things plugged into a wall.
  • Bluetooth Low Energy (BLE): Great for short-range communication with a phone.
  • LoRaWAN/NB-IoT: The “Wong Edan” favorite for long-distance, low-power sensing. You can send a packet across a city with the energy of a flea’s heartbeat.
  • Cellular (LTE/5G): Use this if you have a corporate budget and don’t mind paying Telnyx or another provider for data.

Remember, the more radios you put on your board, the more complex your power management becomes. Every antenna is a potential point of failure and a drain on your battery.

3. Power Management: Why Your Battery is Crying

In the IBM Developer guide, power is one of the “big four” factors (alongside cost, form factor, and connectivity). If you are building a device that runs on a 2032 coin cell battery, you cannot use a Raspberry Pi. You just can’t. Stop trying. It’s embarrassing.

When selecting hardware, look for the “Deep Sleep” current. A “Wong Edan” pro knows that an ESP32 might pull 200mA when Wi-Fi is screaming, but it can drop to 10µA in deep sleep. That’s the difference between your project lasting three days or three years.


// Example: Putting an ESP32 into Deep Sleep (The "Don't Waste Juice" Mode)
#include <esp_sleep.h>

void setup() {
Serial.begin(115200);
// Do your work here...
Serial.println("I'm tired. Going to sleep for 10 minutes.");

// Set sleep timer for 600 seconds (600,000,000 microseconds)
esp_sleep_enable_timer_wakeup(600 * 1000000);
esp_deep_sleep_start();
}

void loop() {
// This code will NEVER run.
}

4. The Raspberry Pi and IBM MQ: A Match Made in Developer Heaven

Let’s talk about the “tastiest” part of the IBM ecosystem: IBM MQ on Raspberry Pi. Released around Sep 15, 2020, this was a game-changer for IoT developers. Why? Because it brought enterprise-grade messaging to a $35 computer.

If your project involves mission-critical data—like monitoring the temperature of a vaccine fridge or a nuclear reactor—you can’t just send a raw UDP packet and hope for the best. You need guaranteed delivery. IBM MQ provides that “once and only once” delivery guarantee. When you choose hardware like the Raspberry Pi, you gain the ability to run these heavy-duty messaging brokers at the “edge.” This allows you to process data locally before sending it to the cloud, saving bandwidth and reducing latency.

5. Sensory Input and the I/O Nightmare

You want to sense the world? You need I/O (Input/Output). But not all pins are created equal. Some are digital, some are analog, and some are just there to confuse you.

  • GPIO (General Purpose Input Output): The bread and butter. High or Low. On or Off. 1 or 0.
  • ADC (Analog to Digital Converter): Crucial for sensors that give a voltage (like a light sensor). Note: The Raspberry Pi doesn’t have a built-in ADC. You’ll need an external chip like the MCP3008. If you didn’t know that, you’re exactly why this article exists.
  • I2C and SPI: These are bus protocols. If you want to connect a screen or a high-end accelerometer, your hardware needs to support these efficiently.

6. Data Modeling and Storage: The Cloud vs. The Edge

Here’s where we get into the “Big Data” side of things. As discussed in recent debates regarding DynamoDB vs. RDBMS, how you model your data depends on your hardware’s capability. If you are using an MCU, you probably won’t be doing complex SQL queries on the device. You’ll be shoving raw data into a NoSQL-style database in the cloud.

However, if you’re using IBM’s Machine Learning principles, you might want to perform “Inferencing” on the device itself. Machine Learning isn’t just for massive server farms anymore. A trained model—applying patterns learned from training data—can be deployed to edge hardware to make real-time decisions. This requires hardware with a decent DSP (Digital Signal Processor) or a dedicated AI accelerator (like the Coral TPU or certain ARM features).

7. Security and Device Management

You’re building an IoT project? Congratulations, you’ve just built a potential botnet entry point. Security is not an afterthought; it’s a career-defining skill, as IBM’s career development tracks suggest. When choosing hardware, you must ask:

  • Does it have a Hardware Security Module (HSM)?
  • Does it support Secure Boot?
  • Can it handle TLS 1.3 encryption without melting?

Device management is the other side of the coin. As mentioned in the article “Streamlining the development of your IoT applications,” you need to be able to push updates (OTA – Over the Air) to your devices. If your hardware choice doesn’t support easy OTA updates, you’ll be driving 500 miles to plug in a USB cable every time you find a bug in your code. And believe me, with your coding skills, there will be bugs.

Wong Edan’s Verdict

“Hardware is the soul, software is the ghost. If the soul is weak, the ghost has nowhere to haunt.”

So, what should you pick? If you are a beginner or a developer looking to build a robust gateway, get a Raspberry Pi. It’s the “tastiest” option for a reason—it supports IBM MQ, it has a massive community, and it won’t break your heart when you need to install a library.

If you are building a fleet of 10,000 sensors to monitor soil moisture in a cornfield, get an ESP32 or a specialized ARM Cortex-M based board. They are cheap, power-efficient, and can be easily managed if you follow IBM’s device management best practices.

Don’t be the person who chooses hardware based on the color of the PCB. Read the datasheets. Check the power curves. And for the love of all that is holy, make sure your ground wires are connected. Now go build something that doesn’t explode. Or do—just make sure you record it for the “Wong Edan” archives.