Solar Assistant MQTT Configuration Guide: How I Feed LuxPower Data Into Home Assistant Without Cloud Junk

by

Solar Assistant MQTT Configuration Guide: How I Feed LuxPower Data Into Home Assistant Without Cloud Junk

Meta Description: Learn how I configure Solar Assistant MQTT for LuxPower and other DIY solar inverters, including broker settings, topic structure, Home Assistant integration, naming cleanup, and troubleshooting.

Target Keywords: Solar Assistant MQTT configuration, Solar Assistant Home Assistant integration, Solar Assistant LuxPower setup, solar inverter MQTT, LuxPower MQTT Home Assistant

Solar monitoring gets dumb fast when the only place your inverter data lives is a vendor app and a prayer.

That is exactly why I like Solar Assistant with MQTT so much. It gives me a clean local path from my inverter to Home Assistant without depending on cloud dashboards, mystery APIs, or whatever firmware mood swing the manufacturer is having this week.

I have used this approach with LuxPower-based systems, LiFePO4 batteries, and Home Assistant dashboards and automations long enough to know where it works beautifully and where it turns into an annoying little swamp. This guide is the version I wish I had the first time I wanted reliable battery, PV, load, and grid data in Home Assistant without building an entire telemetry stack from scratch.

If you are running Solar Assistant and wondering how to actually make the MQTT side useful, this is the practical setup.

Table of Contents

  1. Why I Use MQTT With Solar Assistant
  2. What You Need Before You Start
  3. My Recommended Architecture
  4. Step 1: Verify Solar Assistant Data First
  5. Step 2: Set Up an MQTT Broker
  6. Step 3: Configure MQTT in Solar Assistant
  7. Step 4: Understand the Topic Structure
  8. Step 5: Bring the Data Into Home Assistant
  9. Step 6: Clean Up Entity Names and Units
  10. Practical Automations I Actually Use
  11. Real-World Example: Battery-Aware Load Decisions
  12. Common Problems and Fixes
  13. Recommended Hardware and Final Thoughts

Why I Use MQTT With Solar Assistant

Solar Assistant is already useful on its own, but MQTT is what makes it part of a larger system instead of a pretty island.

Once the data is published to a local broker, I can:

  • show PV, battery, grid, and load data in Home Assistant
  • build automations around battery state of charge and utility rate windows
  • compare inverter data with whole-home monitoring
  • detect bad behavior like unexpected grid charging or overnight battery drain
  • keep everything local instead of waiting on vendor clouds to stop being useless

That last point matters. If I am making decisions about charge windows, backup reserve, generator support, or load shedding, I do not want stale cloud data showing up three minutes late. Local MQTT is simple, fast, and boring in the best possible way.

What You Need Before You Start

Here is the basic stack I recommend:

  • a supported inverter already working with Solar Assistant
  • Solar Assistant running on a Raspberry Pi or similar box
  • Home Assistant on your local network
  • an MQTT broker, usually Mosquitto
  • reliable Ethernet for anything that stays put

You can technically run parts of this over Wi-Fi, but I try not to. Solar data is one of those things that looks flaky when the real problem is just cheap networking.

If your inverter is a LuxPower, EG4 that speaks like a LuxPower cousin, Growatt, Deye, or another well-supported unit, Solar Assistant usually gets you to good telemetry faster than direct register spelunking.

This is the path I trust most:

Inverter -> Solar Assistant -> MQTT broker -> Home Assistant

That gives you a clean separation of jobs:

  • the inverter provides raw operating data
  • Solar Assistant handles inverter communication
  • MQTT distributes the data locally
  • Home Assistant turns the data into dashboards and automations

I prefer this over having Home Assistant talk to the inverter directly unless there is a compelling reason not to. Direct Modbus can work, but it also tends to involve more manual mapping, more register weirdness, and more vendor documentation written by raccoons.

Step 1: Verify Solar Assistant Data First

Before touching MQTT, make sure Solar Assistant itself is already stable.

I want to see sane values for:

  • battery state of charge
  • battery voltage
  • PV production
  • inverter output or load power
  • grid import/export or bypass state
  • daily generation totals

If Solar Assistant is missing data, showing zeros, or dropping the inverter connection, stop there first. Piling MQTT and Home Assistant on top of bad source data is how people end up with elaborate dashboards full of lies.

For LuxPower specifically, I like to confirm that:

  • the inverter model is detected correctly
  • battery SOC matches the inverter front panel closely
  • load and PV values update every few seconds
  • charging state changes are visible when timers or TOU settings kick in

Step 2: Set Up an MQTT Broker

If you already run Home Assistant, the easiest route is the Mosquitto broker add-on.

My basic process looks like this:

  1. Install the Mosquitto add-on in Home Assistant.
  2. Create a dedicated MQTT user.
  3. Start the broker.
  4. Add the MQTT integration in Home Assistant if it is not already configured.

I do not reuse my Home Assistant admin credentials for this. Separate credentials are cleaner and make it easier to rotate access later without breaking everything else.

Typical broker settings:

  • broker host: the IP or hostname of Home Assistant or your broker host
  • port: 1883
  • username: dedicated MQTT user
  • password: a real password, not solar123 like a maniac

If you want TLS, knock yourself out, but for most local DIY installs on a trusted LAN, plain MQTT on 1883 is fine. I care more about a reliable local network than about overcomplicating a solar closet.

Step 3: Configure MQTT in Solar Assistant

In Solar Assistant, go to the MQTT settings page and fill in:

  • broker address
  • broker port
  • username
  • password
  • topic prefix

The topic prefix matters more than people think. Use something sane and predictable. I like prefixes like:

  • solarassistant/luxpower
  • solarassistant/shop-solar
  • solar/main-system

If you leave the naming sloppy, your MQTT tree turns into archaeology.

For a single-inverter LuxPower setup, I would use something like:

broker: 192.168.4.50
port: 1883
username: mqtt_solar
password: ********
topic prefix: solarassistant/luxpower

Then save the settings and confirm Solar Assistant reports that publishing is enabled.

Step 4: Understand the Topic Structure

One reason I like Solar Assistant is that it usually publishes a sensible spread of values without much manual work. The exact topics vary a bit by inverter, firmware, and Solar Assistant version, but the structure generally includes values for:

  • battery SOC
  • battery voltage and current
  • PV power
  • grid power
  • load power
  • inverter mode or status
  • daily and lifetime energy counters

The easiest way to inspect what is actually being published is to subscribe to the tree with a client like mosquitto_sub or MQTT Explorer.

For example:

mosquitto_sub -h 192.168.4.50 -u mqtt_solar -P 'your-password' -t 'solarassistant/luxpower/#' -v

When I do this, I am looking for two things:

  1. The values exist.
  2. The values make sense.

A battery SOC that jumps from 62 to 14 to 91 is not a Home Assistant problem. That is upstream garbage and should be treated accordingly.

Step 5: Bring the Data Into Home Assistant

In many setups, Solar Assistant publishes data in a way that Home Assistant can discover automatically through MQTT discovery. When that works, great. Let the robots have one win.

If discovery does not populate everything cleanly, I still do not panic. Manual MQTT sensors are straightforward.

Here is the general idea:

  • add the MQTT integration
  • confirm new entities appear
  • if needed, create manual MQTT sensors for the specific topics you care about most

The core sensors I care about are:

  • battery SOC
  • battery power or current
  • PV production
  • inverter output power
  • grid import/export
  • daily solar generation
  • inverter operating mode

Those are enough to drive most dashboards and automations without drowning yourself in every obscure register the inverter exposes.

Step 6: Clean Up Entity Names and Units

This is the boring part, and it is worth doing anyway.

Auto-discovered entities often come in with ugly names, inconsistent units, or device labels that look like they were generated by a forklift accident. I rename things early so the rest of my setup stays readable.

I prefer names like:

  • sensor.solar_battery_soc
  • sensor.solar_battery_voltage
  • sensor.solar_pv_power
  • sensor.solar_load_power
  • sensor.solar_grid_power
  • sensor.solar_daily_generation
  • sensor.solar_inverter_mode

That naming convention pays off later when you are writing automations at 11:30 PM and trying to remember whether sensor.sa_2a_output_3 was the grid meter or the battery current.

I also verify units carefully:

  • power in watts
  • energy in kWh
  • voltage in volts
  • current in amps
  • SOC in percent

If Home Assistant gets units wrong, the Energy Dashboard can become weirdly unhelpful. A sensor labeled as power when it is really energy will make the whole thing act possessed.

Practical Automations I Actually Use

Once the MQTT data is stable, this is where the setup gets fun.

These are the kinds of automations I actually find useful:

1. Alert when overnight charging does not happen

If I expect the inverter to grid-charge overnight during a cheap rate window and battery SOC is still low by morning, I want a heads-up. That usually means:

  • the timer window is wrong
  • the inverter ignored the mode change
  • AC charge got disabled
  • the utility went out

2. Delay discretionary loads until solar production is healthy

This is handy for things like:

  • dehumidifiers
  • shop fans
  • water heating relays
  • EV charging contactors

I would rather run those when PV is strong than pull from the battery just because the sun technically exists somewhere behind a cloud.

3. Notify on unexpected bypass or grid dependence

If the inverter flips to bypass when it should be running loads from battery and PV, that is worth investigating. Sometimes it is a settings issue. Sometimes it is a battery communication problem. Sometimes it is just the inverter being dramatic.

4. Track battery reserve discipline

If battery SOC drops below the reserve I intended to protect, I want to know. This matters even more in partial off-grid or backup-heavy setups where reserve policy is not just theoretical.

Real-World Example: Battery-Aware Load Decisions

Here is a practical way I think through automations.

Let us say I have:

  • a 48V LiFePO4 bank with about 15 kWh usable
  • overnight household usage around 6 kWh
  • a LuxPower inverter with scheduled grid charge available
  • Home Assistant watching Solar Assistant over MQTT

If battery SOC is above 85% by late morning and PV production is already covering base loads, I am comfortable allowing optional loads to run. If SOC is dragging at 54% under gloomy weather, I do not want pretend abundance just because the dashboard looks cheerful.

A simple decision model might be:

  • allow extra load if PV power is above 2500 W for 10 minutes
  • require battery SOC above 80%
  • block discretionary load if grid import is already positive

That logic is crude, but it works. It is much better than a dumb timer that assumes every day is sunny and every battery behaves the same.

Common Problems and Fixes

Solar Assistant is not publishing to MQTT

Check:

  • broker IP and port
  • username and password
  • whether the broker is reachable on the network
  • whether Solar Assistant saved the settings correctly

If the broker moved or the IP changed, Solar Assistant will not magically read your mind.

Home Assistant sees MQTT but no useful entities appear

This is usually one of three things:

  • discovery is not enabled or not supported the way you expect
  • the topics exist but need manual sensor definitions
  • the payloads or units are not mapped the way Home Assistant wants

I inspect the live topic tree first before blaming Home Assistant.

Values are stale or update too slowly

Look at the whole path:

  • inverter to Solar Assistant
  • Solar Assistant to broker
  • broker to Home Assistant

Most of the time, stale values come from flaky inverter communications or weak network links, not from MQTT itself.

Battery SOC is wrong

That is usually not an MQTT issue. It is more often:

  • bad inverter-to-battery comms
  • a battery BMS reporting badly
  • mismatched charge parameters
  • a battery that has not been fully topped and recalibrated in ages

MQTT is just the messenger. Do not shoot it because the inverter is confused.

Duplicate or ugly entities keep appearing

That can happen if you change topic prefixes, discovery payloads, or device names midstream. Clean up old entities and settle on one naming convention early. Future You will complain less.

If I were setting this up from scratch today, I would keep it simple:

  • Raspberry Pi 4 or another reliable small Linux box for Solar Assistant
  • Ethernet for Solar Assistant and Home Assistant
  • Mosquitto broker on Home Assistant or another always-on local host
  • good-quality inverter communication cable, preferably not bargain-bin junk

This stack works because each part does one job well.

Solar Assistant handles inverter communication. MQTT distributes data locally. Home Assistant turns telemetry into something useful.

That is the whole game.

For DIY solar, I strongly prefer local-first monitoring and automation. Vendor clouds are fine right up until they are slow, broken, rate-limited, or quietly abandoned. MQTT is not glamorous, but it is dependable, understandable, and easy to build around.

If you already have Solar Assistant running, adding MQTT is one of the highest-value upgrades you can make. It turns your inverter data from something you occasionally glance at into something you can actually use.

Author Bio: Bucky is a DIY solar enthusiast and network engineer who runs PanelsAndPackets.com to share real-world solar knowledge without the marketing fluff.