Technology Stack Components

Technology Stack Components

Overview

This section provides a detailed examination of each component in the IoT solution stack. By the end of this section, you will be able to:

• Explain the function and configuration of each technology component
• Understand how components interact and depend on each other
• Describe commercial alternatives and when to recommend them
• Answer customer questions about component selection and trade-offs

Component Map

The following diagram shows how the technology components connect and their data flow direction:

┌─────────────────────────────────────────────────────────────────────┐
│ Grafana Dashboard │
│ (Visualization & Alerting) │
└───────────────────────────┬─────────────────────────────────────────┘
 │ Queries (Flux/SQL)
┌───────────────────────────▼─────────────────────────────────────────┐
│ InfluxDB + MariaDB │
│ (Time-Series + Relational Storage) │
└───────────────────────────┬─────────────────────────────────────────┘
 │ Writes (Node-RED nodes)
┌───────────────────────────▼─────────────────────────────────────────┐
│ Node-RED │
│ (Flow Engine, Data Processing, Integration) │
└───────────────────────────┬─────────────────────────────────────────┘
 │ Subscribe (MQTT)
┌───────────────────────────▼─────────────────────────────────────────┐
│ MQTT Broker (Mosquitto / EMQX) │
│ (Message Routing) │
└───────────────────────────┬─────────────────────────────────────────┘
 │ Publish (MQTT)
┌───────────────────────────▼─────────────────────────────────────────┐
│ ESP32 │
│ (Microcontroller + Sensors/Actuators) │
└─────────────────────────────────────────────────────────────────────┘

Component 1: ESP32 Microcontroller

Role in the Stack

The ESP32 is the edge device that interfaces directly with sensors and actuators. It collects physical measurements (temperature, humidity, motion, etc.) and converts them into digital data for transmission.

Key Specifications

Specification	Detail
Processor	Xtensa LX6 dual-core (or LX7 on S3) up to 240 MHz
RAM	520 KB SRAM (up to 8 MB PSRAM on some models)
Flash	4-16 MB
WiFi	802.11 b/g/n, 2.4 GHz
Bluetooth	BLE 4.2 (Classic on original, BLE only on C3/S3)
GPIO	Varies by model: 16-34 programmable pins
ADC	12-bit, up to 18 channels
DAC	8-bit, 2 channels (not on C3/S3)
Deep Sleep	~10 µA current consumption
Operating Voltage	3.3V (5V tolerant on some pins)

Model Variants and Selection Guide

Model	Key Feature	Best For	Price Range
ESP32 DevKit (original)	Full GPIO, Bluetooth Classic	General-purpose prototyping	$5-8
ESP32-S3	AI accelerator, more PSRAM	LVGL displays, edge ML	$6-10
ESP32-C3	RISC-V core, lower cost	Simple sensors, cost-sensitive	$3-5
ESP32-CAM	Camera interface, PSRAM	Image capture, surveillance	$7-12
ESP32-XIAO (Seeed)	Ultra-compact (21x17.5mm)	Wearable, space-constrained	$4-7
ESP32-Tower (Olimex)	Industrial connectors, LiPo	Prototyping with peripherals	$12-18

What ESP32 Can and Cannot Do

When discussing capabilities with customers, use this boundary assessment:

Capabilities:

• Read up to 18 analog sensors simultaneously (with ADC multiplexing)
• Control relays, LEDs, motors (via driver ICs)
• Process JSON, perform calculations, apply logic
• Communicate via WiFi up to ~50m indoor, ~100m outdoor
• Operate on battery for weeks to months (with deep sleep optimization)
• Serve a simple web page or REST API endpoint

Limitations:

• Cannot process high-resolution video (limited to JPEG capture, not streaming)
• Limited floating-point performance (use integer math where possible)
• WiFi range constrained; no cellular/LTE without external module
• No native Ethernet; requires SPI Ethernet module (W5500, ENC28J60)
• Flash wear limit (~100,000 write cycles for SPI flash)
• No hardware crypto acceleration on original ESP32 (S3 has improved support)

Component 2: MQTT Broker (Mosquitto / EMQX)

Role in the Stack

The MQTT broker is the central message router. All devices publish data to the broker, and all backend services subscribe through it. The broker decouples senders from receivers — devices do not need to know about each other.

Mosquitto vs EMQX Comparison

Feature	Mosquitto	EMQX
License	Eclipse Public License (open source)	Apache 2.0 (open source core, enterprise edition available)
Language	C	Erlang
Max Connections (single node)	~10,000	~1,000,000
Cluster Support	Limited (bridge mode)	Native clustering (horizontal scaling)
MQTT 5.0	Supported	Supported
Rule Engine	No (requires external integration)	Built-in SQL-like rule engine
Web Dashboard	Minimal (CLI-focused)	Rich web UI
Resource Usage	~10 MB RAM	~50 MB RAM (minimum)
Configuration	Text file (mosquitto.conf)	Dashboard + config file
TLS Support	Yes	Yes
Plugin System	Yes (auth, logging)	Yes (auth hooks, extensions)

When to Recommend Each

Recommend Mosquitto when:

• Deployments under 1,000 devices
• Resource-constrained server (e.g., Raspberry Pi)
• Simple setup without cluster requirements
• Customer prefers minimal overhead

Recommend EMQX when:

• Deployments over 1,000 devices
• High-availability and clustering required
• Built-in rule engine for data preprocessing needed
• Customer wants a management dashboard

Component 3: Node-RED

Role in the Stack

Node-RED is the automation and integration engine. It receives MQTT data, processes it, stores it, and triggers actions. It is the component where most business logic lives.

Key Capabilities

• Flow-based programming: Visual wiring of nodes eliminates boilerplate code
• 1,000+ community nodes: Extend functionality via npm packages
• Built-in editor: Browser-based IDE with debug console and node inspector
• Context storage: Retain state across messages (flow, global, file-based)
• HTTP endpoints: Can act as a web server or REST API
• Function node: Write custom JavaScript for complex logic
• Subflows: Encapsulate reusable logic into single nodes

Typical Memory Usage

Deployment Scale	RAM Usage	Notes
Demo / single project	50-100 MB	Minimal flows, few nodes
Small production (10-50 devices)	100-300 MB	Multiple flows, database nodes
Medium production (50-500 devices)	300-500 MB	Complex flows, HTTP endpoints
Large (500+ devices, heavy processing)	500 MB - 2 GB	Consider horizontal scaling

Component 4: InfluxDB (Time-Series Database)

Role in the Stack

InfluxDB stores sensor data as time-series points. Each point has a measurement name, tags (indexed metadata), and fields (numeric values). This structure is optimized for IoT workloads.

Data Model Example

measurement: "environment"
tags: location="factory_zone1", sensor_id="esp32_01"
fields: temperature=26.5, humidity=62.3
timestamp: 2026-05-17T10:30:00Z

Key Features

• Continuous queries: Automatically downsample and aggregate data
• Retention policies: Auto-delete data older than configurable duration
• Flux query language: Powerful data transformation and analysis
• HTTP API: Write and query data via REST endpoints
• Bulk import: Backfill historical data from CSV or other sources

Storage Estimation

Sampling Interval	Devices	Points/Day	Storage/Day
10 seconds	10	86,400	~5 MB
1 minute	50	72,000	~4 MB
5 minutes	100	28,800	~1.5 MB
1 hour	500	12,000	~0.7 MB

InfluxDB Versions

Version	Status	Recommendation
InfluxDB 1.x	Stable, long-term	Best for small/medium deployments. SQL-like query language.
InfluxDB 2.x / OSS	Current, active	Flux language, new UI, but higher resource usage.
InfluxDB Cloud	Managed service	For customers who want zero maintenance.

Component 5: Grafana

Role in the Stack

Grafana is the visualization layer that turns stored data into actionable dashboards. It connects to InfluxDB (and MariaDB) and provides real-time graphical display.

Key Features for Pre-Sales

• Dashboard templates: Export and reuse across customer demonstrations
• Alerting engine: Email, Telegram, Slack, Webhook notifications
• Annotations: Mark events (e.g., “device offline”, “threshold breached”)
• Variables: Create interactive dashboards where customers choose time range, device, location
• Panels: Time series, bar chart, gauge, table, heatmap, stat, and more

Dashboard Design Principles for Customer Demos

1. Start with key metrics: Temperature, humidity, power consumption — the numbers customers care about most
2. Use color coding: Green (normal), yellow (warning), red (alert) for instant comprehension
3. Include time range selector: Let customers switch between 1h, 24h, 7d, 30d views
4. Add threshold lines: Show acceptable ranges directly on charts
5. Keep it clean: Avoid information overload — 3-5 panels per dashboard is ideal for demos

Component 6: Docker & Docker Compose

Role in the Stack

Docker containers package each service (Mosquitto, Node-RED, InfluxDB, Grafana) into isolated, portable units. Docker Compose orchestrates them as a single stack.

Why Containerize?

• Reproducibility: Same environment on any machine (Windows, Mac, Linux)
• Isolation: Each service runs independently; one failure doesn’t cascade
• Simplified updates: Replace a container without affecting others
• Demo portability: Package and deploy the entire stack on a customer’s server
• Resource efficiency: Containers share the host OS kernel (vs. VMs)

Docker Compose Stack Overview

A typical docker-compose.yml for this stack includes:

Service	Image	Ports	Volume
Mosquitto	eclipse-mosquitto:2	1883, 8883	Config, data, log
Node-RED	nodered/node-red:4	1880	User data
InfluxDB	influxdb:2	8086	Data storage
Grafana	grafana/grafana:11	3000	Dashboards, config

Technology Decision Summary Table

When customers ask about alternatives, this reference table is useful during consultations:

Component	Chosen Solution	Primary Alternative	Key Differentiator
Microcontroller	ESP32	Arduino Due, STM32	Built-in WiFi + BLE, cost
Communication	MQTT	HTTP, CoAP, Zigbee	Lightweight, pub-sub, QoS
Broker	Mosquitto/EMQX	VerneMQ, HiveMQ CE	Open-source, MQTT 5.0
Automation	Node-RED	Home Assistant, n8n	Visual flow, IoT-focused
Time-Series DB	InfluxDB	TimescaleDB, Prometheus	Write performance, retention
Visualization	Grafana	Kibana, Chronograf	Multi-source, alerting
Containerization	Docker	Podman, Kubernetes	Industry standard, simple

Summary

Each component in the technology stack serves a specific purpose, and understanding their roles enables effective customer conversations:

• ESP32 handles sensor data collection and device control at the edge
• MQTT broker provides reliable message routing between devices and servers
• Node-RED processes data, applies business logic, and integrates systems
• InfluxDB stores time-series data with high write throughput
• Grafana visualizes data in real-time dashboards with alerting
• Docker makes the entire stack portable, scalable, and easy to deploy