Why the best systems don’t choose one, they combine both

MQTT and Firebase are often compared, but they solve different layers of an IoT system.

MQTT is designed for device communication. It handles telemetry, commands, and real-time messaging between constrained devices and brokers with very low overhead. It is built for scale, reliability, and unstable networks.

Firebase, on the other hand, is a backend for applications. It is ideal for dashboards, mobile apps, authentication, and real-time UI updates without complex infrastructure.

In real systems, the best architecture often combines both. Devices send data through MQTT to a broker, then a backend service processes and forwards relevant information to Firebase. Apps and dashboards then consume that data from Firebase in real time.

The key insight: MQTT moves data efficiently, Firebase presents it simply, and together they form a complete IoT pipeline.

Why it works for prototypes, but not for large-scale IoT systems

Firebase is often a fast and convenient choice for connecting ESP32 devices to the cloud, especially in early prototypes and proof-of-concept systems. However, its architecture introduces limitations that become clear when the system starts scaling.

Firebase Realtime Database stores data in a JSON tree structure rather than a time-series optimized format. This makes it flexible for simple applications, but less efficient when dealing with continuous sensor streams. Without careful data modeling, retrieving historical data or performing time-based analysis can become inefficient.

Another key limitation is the communication model. Firebase relies on persistent WebSocket connections for real-time updates. While this is useful for instant synchronization, it does not provide messaging features like QoS levels, message queuing, or guaranteed delivery that are typically found in IoT-focused protocols like MQTT. This makes it less reliable in unstable network conditions or distributed systems with many devices.

In practice:

• Works well for small to medium prototypes and dashboards
• Starts to struggle with large-scale deployments and high-frequency telemetry

Key takeaway:

Firebase is excellent for fast development and validation, but MQTT-based architectures are generally better suited for scalable, production-grade IoT systems where reliability and efficiency are critical.

A backend not built for IoT, but works perfectly for real-time prototypes

Firebase is not marketed as an IoT platform. It is primarily a backend for mobile and web applications. However, the Firebase Realtime Database introduces a behavior that makes it extremely useful for IoT prototyping: true real-time data synchronization without polling.

When an ESP32 writes a value to the database, all connected clients instantly receive the update. No message broker, no manual refresh, no polling loop. This creates a simple but powerful real-time architecture where sensor data flows directly to dashboards, apps, or web interfaces.

Why developers use it in IoT systems:

• Free tier is enough for small deployments
• Real-time sync using WebSockets
• Easy integration with mobile apps and web dashboards
• Built-in authentication for device-user linking
• Simple ESP32 integration using Firebase ESP Client library

For quick prototypes and small-scale systems, Firebase removes a large amount of backend complexity while still delivering real-time behavior.

Powerful features, strict rules, and why MQTT remains unmatched in real deployments

MQTT wildcards are simple, but extremely powerful when used correctly.

The + wildcard allows controlled flexibility by matching exactly one level in a topic. The # wildcard is broader, matching all remaining levels under a topic branch. This makes it extremely useful for debugging and exploration tools like MQTT Explorer, where full visibility of broker traffic is needed.

However, production systems should treat # with caution. Overusing it can increase bandwidth usage, overload subscribers, and unintentionally expose data across services. For this reason, production firmware should always subscribe only to the exact topics it requires.

Despite its simplicity, MQTT continues to dominate IoT systems because it solves real-world constraints better than most modern alternatives. Its broker-based architecture, lightweight overhead, and predictable routing model make it ideal for large-scale deployments where reliability and efficiency matter more than complexity.

How a few slashes define the scalability of your entire IoT system

In MQTT, topic design is not just naming. It is the foundation of your system architecture.

A poorly designed topic structure leads to messy routing, harder debugging, and inefficient broker performance. A well-designed one behaves like a clean database schema, predictable and scalable from day one.

Most production systems follow a clear hierarchy using / separator:

• devices/{device_id}/telemetry

• devices/{device_id}/commands

• facilities/{facility_id}/{zone}/{metric}

  This structure enables powerful filtering using wildcards. The + wildcard matches a single level, allowing subscriptions like devices/+/telemetry to collect data from all devices. The # wildcard matches all remaining levels, such as facilities/building-a/#, capturing everything under that branch.

Good topic design directly improves scalability, maintainability, and long-term system clarity.

MQTT is a lightweight messaging protocol built for one purpose: making unreliable networks and constrained devices communicate reliably at scale. That’s why, even after decades, it’s still everywhere in real IoT systems.

Instead of devices talking directly, MQTT uses a broker-based publish–subscribe model. Devices publish messages to topics, and the broker delivers them to all subscribed clients. This removes complexity, improves scalability, and makes the system easy to manage.

What makes MQTT powerful in real deployments are its core features:

Last Will and Testament (LWT):

Automatically notifies the system if a device disconnects unexpectedly.

Retained Messages:

Instantly provides the latest known state to any new subscriber without waiting for updates.

Persistent Sessions:

Ensures offline devices receive missed messages once they reconnect, preventing data or command loss.

In short, MQTT succeeds because it is simple, efficient, and extremely reliable under real-world conditions, exactly what IoT systems need at scale.

After optimizing sleep modes and securing OTA updates, there is one remaining system-level problem that silently destroys battery life and user experience: connectivity behavior. Most ESP systems do not fail because Wi-Fi does not work. They fail because Wi-Fi is used inefficiently.

Wi-Fi reconnect is not free. On ESP32, a full scan and authentication cycle can cost hundreds of milliseconds of CPU time and several hundred milliamps of current draw. If your device wakes every minute, reconnecting from scratch every time is more expensive than the sensor reading itself.

The key optimization is state retention. Store the last connected BSSID, channel, and IP configuration in RTC memory. On wake, bypass scanning and reconnect directly using cached parameters. This reduces reconnect time dramatically and stabilizes power consumption across cycles.

Another important technique is exponential backoff for failed connections. If a network is unavailable, retrying aggressively only drains battery and increases thermal load. Instead, progressively increase the retry interval to avoid wasted wake cycles.

For advanced systems, consider hybrid connectivity strategies. BLE can be used for provisioning and fallback communication, while Wi-Fi handles bulk data transfer only when needed. This reduces radio usage significantly in intermittent reporting devices.

Finally, always align connectivity events with your sleep schedule. Waking the chip just to attempt a Wi-Fi reconnection is often worse than delaying transmission until multiple sensor samples are aggregated.

In real IoT systems, power is not saved by sleep alone. It is saved by how intelligently the device decides to talk to the network.

AWS IoT Jobs, Azure Device Update, and Blynk.Air all provide OTA management dashboards with staged rollout, version tracking, and fleet health monitoring. If you are already using these platforms, their OTA integration is often better than building your own system.

Always verify firmware signatures before applying an OTA update. An HTTPS connection protects against network interception, but not against a compromised update server. Firmware signing and secure boot are the real defense against a fully compromised update infrastructure. ESP-IDF supports RSA 3072 and ECDSA 256 for this purpose.

Partition Table for OTA, Don't Wing It

A common mistake is starting with the default partition table, then realizing later that the OTA partitions are too small for your growing firmware. Plan partition sizes before shipping. A good rule of thumb is that each OTA partition should be at least 1.5 times your current firmware size, to allow room for future features.

Quick check: In ESP-IDF, run idf.py size-components to see exactly how much flash each part of your firmware uses. Identify the large consumers early and optimize when needed.

The day you ship a product without OTA updates is the day you commit to never fixing bugs or adding features without physically retrieving every device. That's fine for a breadboard. It's a business problem at any scale. Here's how OTA works on ESP, from the simplest version to what production systems need.

How OTA Works Under the Hood

The ESP's flash is divided into partitions defined by a CSV file. For OTA, you need at least two app partitions: ota_0 and ota_1. Your current running firmware resides in one of them. During an OTA update, the new firmware writes to the other, the inactive one. When writing is complete and the SHA256 hash verifies, the bootloader checks it on reboot, and the device restarts into the new firmware.**

If the new firmware fails to boot correctly, for example if it crashes repeatedly or never calls esp_ota_mark_app_valid_cancel_rollback(), the bootloader automatically marks the update as invalid and reverts to the previous working firmware on the next power cycle. This rollback mechanism prevents bricks and is a critical production safety net.

Three OTA Methods, Pick Your Level

ArduinoOTA, for development

Install the library, add four lines to setup(), and your board appears in the Arduino IDE port list over the network. Upload new firmware exactly like USB over Wi-Fi. No authentication by default, so add a password at minimum. Not for production, but for rapid development iteration it is extremely convenient.

HTTP OTA, the production standard

Your device polls an HTTPS endpoint every N hours, or on command from the server. The endpoint returns either a 304 Not Modified response, meaning nothing to update, or a new firmware binary. The device downloads it to the inactive partition, verifies integrity, optionally checks signature, then reboots. ESP-IDF's esp_https_ota() handles most of this in a few lines of code.

ESP Sleep Modes: The Practical Guide to Not Killing Your Battery

In the previous post, we covered the five power states of the ESP32 family and took a deep dive into deep sleep, the go-to mode for battery-powered sensor nodes. Now we turn to light sleep, a mode that offers sub-milliampere current consumption while preserving RAM state and enabling fast wake-up.

Light Sleep: The Overlooked Middle Ground

Light sleep pauses the CPU while keeping RAM powered, typically around ~0.8 mA depending on configuration. When a wake source fires, execution resumes exactly where it stopped, no reboot, no re-initialization required. If your device needs to respond quickly to GPIO events but does not need to stay fully active all the time, light sleep is often the right choice.

The tradeoff is power. While ~0.8 mA is significantly lower than active mode, it is still much higher than deep sleep (~10 µA). At scale, this difference has a major impact on battery lifetime.

For devices that wake frequently, light sleep can be more energy-efficient overall because it avoids the repeated cost of system reboots and Wi-Fi reconnections. However, for longer sleep intervals measured in minutes or hours, deep sleep remains the clear winner.

Wake sources for light sleep include timers, GPIO interrupts, UART activity, and capacitive touch sensors. These are configured similarly to deep sleep using APIs such as esp_sleep_enable_timer_wakeup() and esp_sleep_enable_gpio_wakeup().

For a device that wakes up periodically to send data and then sleeps, which covers most of the battery IoT nodes, deep sleep is what you want. You call esp_deep_sleep_start() and the chip powers down to approximately 10 µA, keeping only the RTC oscillator ticking. Your specified wakeup source brings the chip back.

The GPIO16 trick for ESP8266: On the original ESP8266, you must wire GPIO16 to RST to wake from deep sleep via timer. The RTC fires a low pulse on GPIO16 which resets the chip. Forget this wire and your device sleeps forever.

On the ESP32, the timer wakeup is cleaner, no external wire needed. Call esp_sleep_enable_timer_wakeup(duration_in_microseconds) before esp_deep_sleep_start() and you're done.

Surviving Deep Sleep: RTC Memory

 Here's the subtle part: deep sleep kills your chip's state. All RAM is wiped. Your variables are gone. To preserve data across sleep cycles, use RTC memory, a small (16 KB) memory region powered by the RTC that survives deep sleep.

In Arduino: RTC_DATA_ATTR int bootCount = 0; that RTC_DATA_ATTR prefix stores the variable in RTC SLOW memory. Use it for boot counters, cached Wi-Fi credentials, last sensor value, or anything you need to remember between wakes.

 Cache your Wi-Fi BSSID and channel in RTC\_DATA\_ATTR variables. On subsequent wakes, pass them to WiFi.begin() explicitly to skip the channel scan. This alone cuts reconnect time from 3–5 seconds to under 1 second, a significant battery saving at scale.

ESP Sleep Modes: The Practical Guide to Not Killing Your Battery

Here's something that surprises new IoT developers: a device that runs 24/7 isn't always better than one that sleeps most of the time. For battery-powered sensors, aggressive use of sleep modes is what separates a device that lasts a week from one that lasts two years. Let's talk about how ESP sleep modes work.

The Five Modes, Explained Simply

The ESP32 family has five power states. Most tutorials only mention deep sleep, but understanding all of them lets you pick the right tool for each job.

Mode	Current	CPU Running?	Wi-Fi Active?	Wake Sources
Active (Wi-Fi TX)	~240 mA peak	Yes	Yes	—
Active (CPU only)	~20–80 mA	Yes	Off	—
Modem Sleep	~20 mA	Yes	DTIM sync only	Automatic
Light Sleep	~0.8 mA	Paused	Suspended	Timer, GPIO, UART, touch
Deep Sleep	~10 µA	Off	Off	Timer, EXT0/1, touch, ULP

Note: Current values are typical for ESP32 modules with LDO regulators. Actual consumption depends on module variant, operating voltage, and temperature. Deep sleep current on bare ESP32 chip can be as low as 5 µA; module-level consumption includes LDO quiescent current.

Relays are widely used in automation systems to control electrical loads such as motors, lamps, and industrial equipment. Two common types are mechanical relays and solid state relays (SSR). While both serve the same purpose, their working principles and performance characteristics are significantly different.

This article compares both relay types to help engineers choose the right solution for their application.

Working Principle

Mechanical Relay

A mechanical relay uses an electromagnetic coil to physically switch contacts.

Key characteristics:

• Uses moving parts
• Provides electrical isolation
• Produces clicking sound during operation

Solid State Relay (SSR)

An SSR uses semiconductor components (triac, MOSFET, or optocoupler) to switch loads without moving parts.

Key characteristics:

• No mechanical movement
• Silent operation
• Faster switching

Performance Comparison

Feature	Mechanical Relay	SSR
Switching Speed	Slow (ms)	Fast (µs)
Lifespan	Limited (wear)	Very long
Noise	Audible click	Silent
Heat Generation	Low	Higher
Power Consumption	Coil required	Low control power
Isolation	High	High (optical)

Load Handling

Mechanical Relay

• Suitable for AC and DC loads
• Handles high current surge
• Better for inductive loads

SSR

• Ideal for frequent switching
• Best for resistive loads
• Some types limited to AC only (triac-based)

Advantages and Limitations

Mechanical Relay Advantages

• Low cost
• Handles high current
• Good isolation

Mechanical Relay Limitations

• Contact wear over time
• Slower switching
• Mechanical noise

SSR Advantages

• Long lifespan
• Fast switching
• No mechanical noise

SSR Limitations

• Heat dissipation required
• Higher cost
• Leakage current (important for low-load systems)

Engineering Considerations

Choose based on application:

• Use mechanical relay for:
  • Motor control
  • High current switching
  • Low-frequency operation
• Use SSR for:
  • High-speed switching
  • Silent operation
  • Long-term reliability

Thermal management is critical when using SSR, especially in high-current applications.

Both mechanical relays and SSRs are essential components in automation systems. Mechanical relays are robust and cost-effective for general-purpose switching, while SSRs provide faster, quieter, and more reliable operation for high-frequency switching applications.

Selecting the right relay depends on load type, switching frequency, and system requirements.

#Automation#
#Relay#
#SSR#
#EmbeddedSystem#
#PowerElectronics#
#ControlSystem#

There’s often a goal in design to make something fully manufacturable—clear, predictable, and repeatable.

But in sheet metal, “perfect manufacturability” is rarely a fixed state.

Because even with well-defined processes, there are always variables:

• Material behavior differences
• Tooling conditions
• Sequence effects
• Assembly handling

So the question becomes less about eliminating variation, and more about designing in a way that remains stable under it.

Maybe manufacturability is not about perfection, but about resilience.

💬 Where do you personally draw the line between precision and robustness in your designs?

#sheet metal# #design guide#

We had a case where two batches of the same sheet metal part were produced using identical drawings and material.

On paper, they were the same.

But during assembly, slight differences were noticeable. One batch fit smoothly, while the other required minor adjustment during installation.

After investigation, there wasn’t a single root cause. Instead, it was a combination of small variations:

• Slight bend angle deviation within tolerance range
• Minor differences in coating thickness
• Tool wear between production runs

Each factor alone was acceptable. Together, they created a visible difference in assembly behavior.

It highlighted how manufacturability is often about managing variation, not eliminating it.

💬 How do you usually handle variation when everything is still technically “within tolerance”?

#sheet metal# #design guide# #tolerance#

At the beginning, a good sheet metal design meant something that was fully defined in CAD—no missing dimensions, no ambiguity, fully constrained geometry.

Over time, that definition shifted.

Now, a “good design” feels more like one that:

• Can tolerate small real-world variation
• Assembles without force or adjustment
• Doesn’t depend on perfect execution in every step
• Leaves controlled freedom where needed

The CAD model didn’t become simpler, but the expectations behind it changed.

It became less about controlling every detail, and more about ensuring the design still works when reality introduces variation.

💬 Has your definition of a “good design” changed over time as well?

#sheet metal# #design guide# #enclosure#

Across different sheet metal projects, there’s a pattern that becomes noticeable over time.

Designs that are easy to manufacture usually don’t try to control everything equally.

Instead, they tend to:

• Focus precision only on functional interfaces
• Allow flexibility in non-critical geometry
• Reduce dependency on exact bend positioning
• Avoid unnecessary feature density

Interestingly, these designs don’t look “less engineered.” They just distribute precision more intentionally.

On the other hand, designs that try to enforce uniform precision everywhere often require more adjustments during production.

💬 Have you noticed this difference between “fully controlled” designs and “selectively controlled” ones?

#sheet metal# #design guide#

The design itself was straightforward—a small sheet metal enclosure with multiple bends, standard material, and no unusual features.

On CAD review, everything checked out. Dimensions were consistent, tolerances were defined, and the geometry looked clean.

But during the first production run, small issues started showing up.

Some bends didn’t return exactly as expected, which slightly shifted alignment at the assembly stage. Nothing was completely out of tolerance, but the accumulated effect made the fit feel less smooth than intended.

What stood out most was that there wasn’t a single “error” to fix. It was more about how several small variations interacted together.

After reviewing it again, the focus shifted away from individual dimensions and more toward how the part behaves as a system.

💬 Has anyone experienced a design that passed review but behaved differently once manufactured?

#sheet metal# #design guide# #enclosure#

Current Transformer (CT) sensors are widely used for measuring AC current in industrial and embedded systems. They provide electrical isolation and allow high current measurement without direct electrical contact with the conductor.

This guide explains how to properly use CT sensors with microcontrollers for accurate current measurement.

How CT Sensors Work

A CT sensor operates based on electromagnetic induction. When AC current flows through the primary conductor, it induces a proportional current in the secondary coil.

Key points:

• Output is current (not voltage)
• Requires burden resistor to convert to voltage
• Only works with AC signals

Basic Connection to Microcontroller

A CT sensor cannot be connected directly to an ADC input. The output must be conditioned.

Required components:

• Burden resistor
• RC low-pass filter (optional)
• Voltage divider / biasing (for ADC protection)

Basic flow:

CT Sensor → Burden Resistor → Filter → ADC Input

Burden Resistor Selection

The burden resistor converts CT output current into measurable voltage.

Formula:

Where:

Selection considerations:

• Output voltage must stay within ADC range (0–3.3V / 5V)
• Too large → saturation
• Too small → low resolution

Proper selection is critical for measurement accuracy.

Signal Conditioning and Offset

Because CT output is AC (positive & negative), ADC input must be adjusted.

Common approach:

• Add DC offset (bias) to shift signal into positive range
• Use capacitor filtering to stabilize waveform

This ensures safe and stable ADC readings.

RMS Calculation Implementation

After signal acquisition:

1. Sample ADC values continuously
2. Convert to voltage/current
3. Apply RMS calculation
4. Display or log results

To improve accuracy:

• Use multiple sampling cycles
• Apply filtering
• Calibrate scaling factor

Common Mistakes

Avoid these common issues:

• ❌ No burden resistor (dangerous for CT)
• ❌ Direct connection to ADC
• ❌ Incorrect resistor value
• ❌ Ignoring signal offset
• ❌ Low sampling rate

These mistakes can cause inaccurate readings or hardware damage.

Practical Applications

CT sensors are commonly used in:

• Energy monitoring systems
• Industrial load measurement
• Smart meters
• Motor current monitoring
• Data logging systems

Conclusion

CT sensors provide a safe and effective method for measuring AC current in embedded systems. With proper signal conditioning, correct burden resistor selection, and accurate RMS calculation, reliable current measurement can be achieved for both industrial and IoT applications.

#Sensors#
#CTSensor#
#CurrentMeasurement#
#EmbeddedSystem#
#AnalogSignal#
#TestAndMeasurement#