ESP32 • Solar Power • MQTT • Sensors • Electronics Path

Solar ESP32 MQTT Sensor

This project is a solar-powered outdoor sensor node built around an ESP32, a temperature and humidity sensor, a 5V USB solar panel, a DFRobot solar charger board, and a large lithium-ion battery pack inside a weather-resistant enclosure.

The goal was to build a self-contained box that could sit outside, power itself from solar, measure temperature and humidity, connect over Wi-Fi, and transmit readings by MQTT back to a local web server.

What made this project especially useful was that it was not only software. It was a physical electronics build with soldered connections, cable glands, strain relief, power routing, enclosure planning, and a real sensor-to-server data path.

See the build What the heck is an ESP32? Electronics path MQTT workflow

Project context: this is one of the projects that connects electronics, soldering, physical enclosure design, networking, Linux servers, sensors, power management, and web dashboards into one practical system.

Solar panel 5V USB solar input feeds the charge board.

Battery + charger 20,000 mAh Li-ion pack powers the enclosure.

ESP32 + sensor Reads temperature and humidity, then connects over Wi-Fi.

MQTT → local server Sensor readings are published back to a local web dashboard.

The finished box is a small outdoor IoT node: solar power in, sensor data out.

What I built

I wired together a weather-resistant enclosure that powers an ESP32 from a solar-charged battery system. The ESP32 reads temperature and humidity, connects to Wi-Fi, and publishes readings over MQTT to a local server.

Power

Solar battery system

A 5V USB solar panel charges a 20,000 mAh lithium-ion battery through a DFRobot solar charger board, giving the enclosure portable off-grid power.

Sensor

Temperature and humidity

The ESP32 reads environmental data from a temperature and humidity sensor mounted with the outdoor enclosure in mind.

Network

MQTT data path

The sensor node publishes readings over Wi-Fi to an MQTT broker, where a local web server can display, store, or graph the data.

Why this project matters

This is not just a sensor demo. It is a complete small IoT system: outdoor enclosure, power source, battery storage, microcontroller, network transport, and local server.

Measure

The temperature and humidity sensor collects environmental readings.

Transmit

The ESP32 sends the readings over Wi-Fi using MQTT.

Receive

A local MQTT broker receives the messages on the home lab network.

Display

A local web server can turn the messages into a dashboard, log, or graph.

Why this belongs on the electronics path

This project is a good electronics-path project because it is not only code. It is a physical product: a box with power input, battery storage, soldered connections, cable glands, strain relief, a microcontroller, a sensor, and a network data path.

Soldering

Physical connections matter

Unlike pure software, every connection is visible. Wires need to be stripped, soldered, insulated, routed, and checked. A bad joint or loose wire can break the whole system.

Enclosure design

The box is part of the system

The enclosure protects the electronics, but it also affects serviceability, airflow, cable entry, sensor accuracy, heat, moisture, and mounting.

Systems thinking

Everything connects

Solar power, battery charging, voltage output, ESP32 power draw, Wi-Fi signal, MQTT messages, and server logging all depend on each other.

This is why electronics projects are different from screen-only projects. I can see the physical system: where power enters, where wires connect, where the sensor sits, where the enclosure seals, and how the data leaves the box. That makes the project a practical lesson in both electronics and systems design.

Parts used

The project combines basic IoT hardware with a solar power system and a weather-resistant physical enclosure.

Part	What I used it for	Why it mattered
Weatherproof enclosure	Houses the electronics outdoors.	Protects the ESP32, wiring, charger board, and battery from casual exposure.
Cable glands	Allows wires to enter the enclosure cleanly.	Improves weather resistance and reduces messy open holes in the box.
Strain relief	Protects solder joints and board connectors.	Prevents cable movement from pulling directly on small electrical connections.
ESP32 Wi-Fi board	Reads the sensor and publishes MQTT messages.	Combines microcontroller logic with built-in Wi-Fi.
Temperature/humidity sensor	Measures environmental conditions.	Provides useful real-world data for the local dashboard.
DFRobot 5V solar charger board	Manages solar charging and battery-powered output.	Makes the enclosure practical as a solar-powered sensor node.
5V USB solar panel	Provides solar input power.	Lets the box recharge during daylight instead of relying only on manual charging.
20,000 mAh Li-ion battery	Stores energy for overnight and cloudy operation.	Gives the ESP32 a much larger runtime buffer than a small cell.

Build overview

The build is easiest to understand as five layers: enclosure, power, sensor, microcontroller, and server.

Enclosure layer

The weather-resistant box, glands, and strain relief turn modules into a field device.

Power layer

The 5V USB solar panel feeds the DFRobot solar charger board.

Battery layer

The 20,000 mAh Li-ion battery stores power and supplies the ESP32 system.

Network layer

The ESP32 publishes the reading to an MQTT topic on the local network.

Main idea: the enclosure is not just a box. It is a small field sensor: power comes from the sun, data leaves over Wi-Fi, and the server receives it automatically.

Power layout

The power side is what makes this project feel more like a real deployment than a breadboard demo. The ESP32 is not just plugged into a laptop. It has its own solar and battery setup.

5V USB solar panel
        │
        ▼
DFRobot 5V solar charger board
        │
        ├── 20,000 mAh Li-ion battery
        │
        ▼
5V output to ESP32 sensor system

Battery safety note: lithium batteries need proper charging, protection, strain relief, insulation, and enclosure planning. I would not leave an early prototype unattended until the wiring, charging behavior, heat, and weather protection are tested.

Sensor and ESP32 layout

The ESP32 handles the local logic. It reads the temperature/humidity sensor, formats the data, connects to Wi-Fi, and publishes a message to MQTT.

Temperature / humidity sensor
        │
        ▼
ESP32 GPIO input
        │
        ▼
Format reading as JSON
        │
        ▼
Publish to MQTT topic

Good project habit: test the sensor indoors from USB power first. Then test Wi-Fi and MQTT. Then move to battery. Then move to the solar enclosure.

MQTT workflow

MQTT is a good fit for small IoT devices because the sensor does not need to run a full web server or serve pages directly. The ESP32 only needs to connect to Wi-Fi, publish a small message, and let the local broker handle distribution.

ESP32 publishes

Sensor node

The ESP32 connects to Wi-Fi and publishes readings to a topic such as launchshell/sensors/outdoor1. The device does not need to know which dashboard, database, or script will eventually use the data.

{
  "device": "outdoor1",
  "temperature_f": 72.4,
  "humidity": 56.1,
  "battery": "ok"
}

Server subscribes

Local receiver

A local server, dashboard, or script subscribes to the topic, receives the readings, and can display, log, or graph the data. This keeps the ESP32 simple and moves the heavier work to the server.

mosquitto_sub -h 192.168.1.50 \
  -t "launchshell/sensors/outdoor1"

Networking class connection: MQTT is an application-layer protocol. In a normal Wi-Fi setup, the message still travels through the stack: ESP32 application code → MQTT → TCP → IP → Wi-Fi. MQTT gives the project a lightweight publish/subscribe pattern, while TCP underneath handles reliable transport.

Why MQTT instead of a heavier web protocol?

This project connects directly to networking class ideas. The question is not just “does the data arrive?” It is also “how much overhead does the device need, how much power does it use, how far can it communicate, and how expensive would each sensor node be?”

Protocol idea	How it applies here	Why it matters
MQTT	Small publish/subscribe messages from the ESP32 to a broker.	Good for low-power IoT sensors that only need to report readings.
TCP	Reliable transport underneath MQTT.	Provides ordering, acknowledgments, retransmission, flow control, and checksum-based error detection.
HTTP	Useful for web pages and APIs, but heavier for tiny repeated sensor updates.	Better for dashboards and user interfaces than for tiny sensor publish events.
Wi-Fi	The ESP32 uses Wi-Fi to reach the local network.	Convenient and cheap, but range and power draw matter outdoors.

The important distinction: MQTT is not replacing TCP. MQTT usually rides on top of TCP. The reason MQTT is considered lightweight is that the application-layer messages and publish/subscribe model are much smaller and simpler than having every sensor act like a web server or repeatedly perform heavier HTTP-style exchanges.

Error checking and reliability

A sensor project still needs reliability, but it does not need the same kind of heavy application behavior as a full website. MQTT gives the ESP32 a simple way to report data, and TCP underneath handles much of the transport reliability.

TCP layer

Reliable transport

TCP handles ordered delivery, acknowledgments, retransmission of missing data, flow control, and checksum-based error detection. That means MQTT messages are not just thrown blindly onto the network.

MQTT layer

Delivery options

MQTT can use different Quality of Service levels. For a simple temperature sensor, basic delivery may be enough. For more important messages, MQTT can request stronger delivery confirmation.

Application layer

Good enough data

Temperature and humidity readings are repeated over time. If one reading is missed, the next reading usually replaces it. That is different from sending a file, payment, login, or command where every message may be critical.

Design choice: for this kind of sensor, it is usually acceptable to prioritize low power, low cost, and simple repeated updates over heavy protocol overhead. If a packet is lost, the next reading can correct the dashboard a few minutes later.

Example MQTT topic design

A clean topic structure makes the project easier to expand later if I add more sensors.

Topic	Purpose	Example payload
`launchshell/sensors/outdoor1/state`	Main sensor readings.	`{"temp_f":72.4,"humidity":56.1}`
`launchshell/sensors/outdoor1/status`	Device status or heartbeat.	`{"wifi":-62,"uptime":3600}`
`launchshell/sensors/outdoor1/power`	Battery or power state if monitored.	`{"battery":"ok","solar":"charging"}`

Local server idea

The local server can stay simple. It only needs to receive or subscribe to MQTT data, save readings, and display the latest values.

MQTT broker

A broker such as Mosquitto receives messages from the ESP32.

Subscriber script

A Python script listens for readings and writes them to a file or database.

Storage

Readings can be saved to JSON, SQLite, CSV, or another lightweight format.

Web dashboard

A local web page displays latest temperature, humidity, and sensor status.

ESP32 sensor
    │
    ▼
MQTT broker on local network
    │
    ▼
Python subscriber or web app
    │
    ▼
Local dashboard / log / graph

Example Mosquitto test commands

Before trusting the full system, I would test the MQTT path from the terminal.

Listen for sensor data

mosquitto_sub -h localhost \
  -t "launchshell/sensors/outdoor1/#" \
  -v

Publish

Send a fake reading

mosquitto_pub -h localhost \
  -t "launchshell/sensors/outdoor1/state" \
  -m '{"temp_f":72.4,"humidity":56.1}'

Want to see MQTT in action? Capture the sensor traffic with Wireshark and watch the publish/subscribe flow on the network. This is a good way to connect the physical ESP32 build to real packet analysis, TCP/IP, and application-layer protocols. Wireshark guide.

Testing rule: test the broker with fake messages first. Then connect the ESP32. That separates server problems from sensor firmware problems.

Distance, power, and unit cost

Building a physical IoT device forces tradeoffs that do not show up in a normal coding project. Range, battery life, enclosure cost, board cost, solar input, and server design all affect whether the project is practical.

Distance

Wi-Fi range affects reliability

The farther the box is from the access point, the harder the ESP32 has to work to stay connected. Weak signal can cause reconnects, failed publishes, higher latency, and higher power use.

Power

Every reconnect costs energy

Wi-Fi is convenient, but it is not free from a battery perspective. Waking the ESP32, connecting to Wi-Fi, publishing MQTT, and going back to sleep is usually better than leaving Wi-Fi active all the time.

Cost

Unit cost matters

One sensor box is a project. Five or ten sensor boxes become a system. The cost of each ESP32, sensor, charger board, solar panel, battery, enclosure, glands, connectors, and mounting hardware starts to matter.

Protocol tradeoff: if the sensor needed longer range than Wi-Fi, I would start comparing other options such as LoRa, cellular, or wired Ethernet. Each option changes distance, power draw, cost, complexity, and where the server or gateway needs to live.

What made the enclosure challenging

The hardest part of an outdoor sensor is not only the code. It is turning loose parts into a reliable physical system. The enclosure needs to protect the electronics while still allowing power, sensor readings, and maintenance access.

Cable glands

Clean cable entry

The enclosure uses proper cable glands so wires can enter the box without leaving open holes. That makes the build cleaner, safer, and more weather resistant.

Strain relief

Protect the solder joints

Strain relief matters because outdoor cables get pulled, moved, bumped, and bent. The goal is to keep mechanical force off the solder joints and small board connectors.

Weather sealing

Outdoor is different

A weather-resistant box still needs careful sealing, cable routing, condensation awareness, and sensor placement so the readings stay useful.

Physical build

Why the wiring matters

With a physical enclosure, the wiring is part of the design. The wires cannot just work electrically; they also need to be routed cleanly, protected from strain, kept away from sharp edges, and arranged so the box can still be opened and serviced.

Product thinking

It starts to feel like a real device

Once the electronics are mounted inside a weatherproof box with proper cable entry and stress relief, the project stops feeling like a breadboard demo and starts feeling like a small field-deployable product.

Firmware shape

The ESP32 firmware can stay simple. It should connect, read, publish, and sleep.

Start ESP32
    │
    ├── Connect to Wi-Fi
    ├── Connect to MQTT broker
    ├── Read temperature and humidity
    ├── Publish JSON payload
    ├── Optional: publish battery/status data
    └── Sleep before next reading

Best upgrade: use deep sleep and publish less often. A sensor that wakes every few minutes will usually last much longer than one that keeps Wi-Fi active constantly.

Simple project file plan

If I turned this into a clean repo, I would split the hardware, firmware, and server notes.

solar-esp32-mqtt-sensor/
├── README.md
├── firmware/
│   └── esp32_mqtt_sensor.ino
├── server/
│   ├── mqtt_subscriber.py
│   └── dashboard_notes.md
├── docs/
│   ├── wiring-notes.md
│   ├── power-notes.md
│   └── enclosure-notes.md
└── photos/
    └── build-photos-go-here.txt

What I learned

This project taught more than just sensor wiring. It connected hardware and software into one working system.

Electronics

Power design matters

A solar project needs more planning than a USB-powered breadboard. Charging, battery size, voltage output, soldering, wiring, strain relief, and enclosure layout all matter.

Networking

MQTT is clean for IoT

MQTT makes the sensor node simple. The ESP32 publishes readings, TCP handles reliable transport, and the server handles storage, dashboards, or automation.

Systems

Real projects cross layers

The finished system includes weatherproofing, solar input, battery storage, firmware, Wi-Fi, MQTT, TCP/IP, and a local server.

Future improvements

This project is a strong base for more advanced outdoor monitoring.

Hardware upgrades

Make the node more reliable

Add a vent or sensor shield for better humidity and temperature readings.
Add a voltage divider or fuel gauge to monitor battery level.
Add a physical power switch for maintenance.
Mount the solar panel at a better sun angle.
Document final wiring, glands, strain relief, and enclosure photos.

Software upgrades

Make the data more useful

Add deep sleep between readings.
Publish battery status and Wi-Fi RSSI.
Store readings in SQLite or InfluxDB.
Add a local web dashboard with graphs.
Add alerts for high humidity, freezing temperatures, or low battery.

Related LaunchShell paths

This project sits at the intersection of electronics, networking, Linux, and web apps. It is a good example of how a physical build can become a complete technical system.

Electronics path

Soldering and enclosure work

Learn how to move from loose modules on a bench to a mounted enclosure with soldered connections, proper glands, strain relief, and serviceable wiring.

Networking path

MQTT and TCP/IP

Connect networking class concepts to a real device: Wi-Fi, IP addressing, MQTT topics, TCP reliability, local brokers, and server-side subscribers.

Linux/server path

Local dashboard

A Raspberry Pi or Linux machine can run the MQTT broker, subscriber script, database, and local dashboard that receives the sensor data.

Final idea

This project is a complete outdoor IoT loop. A solar panel and battery power the enclosure, the ESP32 reads temperature and humidity, MQTT carries the data over Wi-Fi, and a local server receives it for display or logging. It is a practical example of how electronics projects become real networked systems.