How to Build an ESP32 Solar Power Monitor: From Solar Panel to Live Dashboard

For systems built around portable or integrated backup power, solar generators and kits provide another way to combine energy storage and power delivery.

But if you're a developer, there's another interesting question:

What if we could treat the entire solar system as an observable software system?

Instead of simply looking at a battery percentage or inverter display, we can collect data from the system, send it to an application, store it locally, and visualize what's happening in real time.

This post walks through the architecture I'd use for a simple ESP32-based solar power monitoring system.

The goal isn't to build a commercial-grade energy meter. It's to understand how the pieces fit together and how you can turn physical energy flows into usable software data.

The Architecture

At a high level, the system looks like this:

[Solar Panels](https://offgridstores.com/collections/solar-panels)
     │
     ▼
Charge Controller
     │
     ▼
Battery
     │
     ▼
Inverter
     │
     ▼
Home / Off-Grid Loads
     │
     │
     ▼
 Energy Sensors
     │
     ▼
   ESP32
     │
     ├──── HTTP / MQTT
     │
     ▼
 Local Server
     │
     ▼
 Database
     │
     ▼
 Dashboard

The important idea is that the ESP32 isn't controlling the power system in this example.

It's acting as an observation layer.

It measures what's happening and turns those measurements into data.

What Should We Measure?

You don't need dozens of sensors to get useful information.

For a basic solar monitoring system, I'd start with:

• Voltage
• Current
• Power
• Battery state
• Solar production
• Load consumption
• Energy generated over time The interesting part is that some of these values can be calculated rather than measured directly.

For example:
Power = Voltage × Current
If a sensor reports:
Voltage = 20V
Current = 5A
then:
Power = 20 × 5
Power = 100W
That gives us a much more useful metric than voltage or current alone.

Why Use an ESP32?

The ESP32 is a convenient choice for this kind of project because it gives you:

• Wi-Fi connectivity
• GPIO
• ADC inputs
• Low-power capabilities
• A large embedded development ecosystem Enough processing capability for sensor collection and communication

More importantly, it provides a bridge between the physical energy system and the software stack.

You can think of it as:

Physical world
↓
Sensors
↓
ESP32
↓
Network
↓
Software
That's essentially an IoT architecture.

The Data Flow

Let's say our sensors are producing measurements every few seconds.

The ESP32 could produce a data object like:

{
  "voltage": 20.1,
  "current": 8.4,
  "power": 168.84,
  "battery": 74,
  "timestamp": 1756900000
}

The ESP32 can then send this information to a local server.

For example:

ESP32
│
│ HTTP POST
▼
/api/solar-data
│
▼
Database
│
▼
Dashboard

Now the energy system has an API.

That's where things start getting interesting.
A Simple ESP32 Data Model

You don't need a complicated schema initially.

Something as simple as:

struct SolarReading {
    float voltage;
    float current;
    float power;
    float batteryLevel;
};

Then your firmware can update the values whenever new sensor measurements arrive.

Conceptually:

reading.voltage = measureVoltage();
reading.current = measureCurrent();

reading.power =
    reading.voltage *
    reading.current;

The ESP32 now has a structured representation of what's happening physically.

Sending the Data

You could send the measurements to your backend using HTTP.

For example, the request body might look like:

{
  "voltage": 20.1,
  "current": 8.4,
  "power": 168.84
}

A simple endpoint could be:
POST /api/solar/readings
The server receives the measurement and stores it.

You could also use MQTT if you want a more event-driven IoT architecture.

For example:
solar/panel/voltage
solar/panel/current
solar/panel/power
solar/battery/state
solar/load/power

This makes it possible for different applications to subscribe to individual measurements.

Why MQTT Can Be Interesting

With HTTP, the ESP32 might periodically say:
"Here is my latest reading."

With MQTT, the device can publish events to topics.

For example:
solar/panel/power
could publish:
125
148
173
181
160
A dashboard can subscribe to that topic without the ESP32 needing to know anything about the dashboard.

That gives you a nice separation:

Sensor
  ↓
ESP32
  ↓
MQTT Broker
  ↓
 ┌───────────────┐
 │               │
 ▼               ▼
Database      Dashboard

This is much closer to how I'd design a scalable IoT system.

Store More Than Just the Current Value

A dashboard showing:
Solar Power: 183W
is useful.

But a graph showing:
Solar Power over the last 24 hours
is much more useful.

That's because energy systems are highly dependent on time.

You might see something like:

Power
  │
800W               /\
  │              /    \
600W            /      \
  │           /          \
400W        /              \
  │       /                  \
200W ___/                      \___
  │
  └────────────────────────────────── Time
       Morning   Noon     Evening

Now you can start asking more interesting questions.

• When does solar production peak?
• How much energy was generated today?
• How quickly does production fall under cloud cover?
• How much power is being consumed?
• When does the battery start charging?
• How much energy is being wasted?

This is where monitoring becomes more than a simple display.

Power vs. Energy

There's another important distinction here.

Power is measured in watts.

Energy is measured in watt-hours.

Suppose your solar system produces:
500W
for:
2 hours
Then the approximate energy produced is:
500W × 2h = 1,000Wh
or:
1kWh
If we're collecting power measurements continuously, we can estimate energy over time.

Conceptually:
Energy ≈ Σ(Power × Time)
In software, that means we can accumulate the readings.

For example:

energy_wh += power_w * interval_hours

Now the system can answer:

"How much solar energy did I generate today?"

instead of simply:

"How much power am I generating right now?"

Building the Dashboard

The dashboard doesn't need to be complicated.

I'd start with four values:

┌─────────────────────────────────────┐
│         SOLAR POWER MONITOR         │
├───────────────┬─────────────────────┤
│ Solar Power   │ Battery             │
│    684 W      │    78%              │
├───────────────┼─────────────────────┤
│ Solar Today   │ Load                │
│   4.82 kWh    │    312 W            │
└───────────────┴─────────────────────┘

Then add graphs.

Graph 1: Solar production

Solar Power
    │
    │             /\
    │           /    \
    │         /        \
    │_______/            \_______
    └─────────────────────────────

Graph 2: Battery level.

Battery %
100 ┤
 80 ┤                 ─────
 60 ┤            ─────
 40 ┤       ─────
 20 ┤──────
    └─────────────────────────────

Graph 3: Household load

This lets you compare energy coming in against energy going out.

The Really Useful Part: Alerts

Once you have the data, you can add rules.

For example:

IF battery< 20%
THEN send alert

Or:
IF solar_power > 500W
AND battery > 80%
THEN notify user

You could also detect unusual behavior:
IF solar_voltage is normal
AND solar_current suddenly drops
THEN flag possible shading / connection issue

Now we're moving from monitoring toward automation.

Treat the System Like a Production System

This is where I think the project becomes especially interesting for developers.

An off-grid energy system has many of the same concerns as a software system.

Observability

You can't troubleshoot what you can't see.

Sensors provide observability into the physical system.

Failure detection

A sudden change in voltage or current might indicate a problem.

Logging

Historical measurements let you investigate what happened.

Alerts

The system can notify you when something crosses a threshold.

Graceful degradation

If the network disappears, the ESP32 shouldn't necessarily stop collecting data.

It could buffer measurements locally and upload them when connectivity returns.

What Happens When Wi-Fi Goes Down?

This is an important edge case.

A naive implementation might do this:

No Wi-Fi
   ↓
Can't send data
   ↓
Data lost

A better design is:

No Wi-Fi
   ↓
Store readings locally
   ↓
Continue monitoring
   ↓
Wi-Fi returns
   ↓
Upload buffered readings

That's a simple example of designing for intermittent connectivity.

And it's especially relevant to off-grid systems, where network availability shouldn't be treated as guaranteed.

Local-First Is Worth Considering

You don't necessarily need to send your home's energy data to a cloud service.

A local architecture could look like:

ESP32
  ↓
MQTT
  ↓
Local Server
  ↓
Database
  ↓
Dashboard

Everything stays inside your network.

That can provide:

• Lower latency
• Operation without internet access
• Local data ownership
• Greater control over the software stack

For an off-grid installation, this can be particularly attractive because the monitoring system doesn't have to depend on an external service just to show you your own energy data.

What I'd Build Next

Once the basic monitoring system works, there are several directions to take it.

1. Energy forecasting

Use historical data to estimate expected solar production.

Historical production
        +
Weather data
        ↓
Expected solar output

2. Smart load management

Automatically prioritize loads based on available energy.

Battery > 70%
     ↓
Allow non-essential loads

Then:

Battery < 30%
     ↓
Disable non-essential loads

3. Solar production anomaly detection

Compare current output against expected output.

Expected: 650W
Actual:   280W

        ↓

Investigate

Potential causes could include shading, weather, wiring, or hardware issues.

4. Historical analytics

Once you've collected enough data, you can answer questions such as:

• Which days produced the most energy?
• How much energy does the home consume?
• How much solar energy is actually being used?
• What percentage is stored?
• What percentage is consumed immediately?.

Hardware Is Only Half the Project

This is probably the biggest takeaway.

A solar installation gives you the physical infrastructure:

Panel → Battery → Inverter → Load

But adding sensors and software gives you:

Panel → Battery → Inverter → Load
             │
             ▼
          Sensors
             │
             ▼
           ESP32
             │
             ▼
        Data Pipeline
             │
             ▼
          Dashboard

Now the system is observable.

And once it's observable, you can start building automation, analytics, alerts, forecasting, and optimization on top of it.

Final Thoughts

Building a solar monitor is an interesting IoT project because it connects two worlds that developers don't always think about together:

software and physical energy systems.

The basic architecture isn't particularly complicated:

Sensors
   ↓
ESP32
   ↓
MQTT / HTTP
   ↓
Database
   ↓
Dashboard

But once you have reliable data, the possibilities expand quickly.

You can turn raw voltage and current measurements into power, integrate power over time to estimate energy, visualize historical behavior, detect abnormal conditions, and eventually use the data to make decisions about how energy should be used.

The next step isn't necessarily buying a bigger solar system.

It might be making the system smarter.