Inverter
Modbus Home Assistant Guide: How I Pull Local Solar Data Without Cloud
APIs

Meta Description: Learn how I connect a solar
inverter to Home Assistant over Modbus for fast local monitoring,
cleaner dashboards, and better automations. Includes RS485, Modbus TCP,
entity design, troubleshooting, and real-world setup advice.

Target Keywords: inverter Modbus Home Assistant,
solar inverter Home Assistant integration, inverter RS485 to USB Home
Assistant, Home Assistant energy dashboard solar battery, solar charging
automation Home Assistant

---

If you care about your solar system enough to put it in Home
Assistant, you probably already know the vendor app is not the whole
story.

Most inverter apps are good at giving you a rough daily graph and
making bold promises about “smart energy.” They are usually not good at
local control, fast updates, sane history, or feeding automation logic
that needs to be right. I do not want my battery-charging decisions
hanging off a cloud API and a company that might redesign its portal
next week because somebody in marketing got bored.

That is why I like Modbus with Home Assistant.

I have spent enough time around hybrid inverters, LuxPower gear,
LiFePO4 batteries, and Home Assistant dashboards to know that local
telemetry wins. It is faster, more predictable, and a lot easier to
trust once you get the register map sorted out. The annoying part is
that Modbus setup looks more intimidating than it really is, mostly
because inverter documentation is often written like it was translated
through three dimensions of suffering.

This guide is how I approach inverter Modbus Home
Assistant setups in the real world. It is not meant to be a
vendor-specific copy-paste manual for every inverter on earth. It is the
practical framework I use to get stable local data into Home Assistant
without building a haunted science project.

Table of Contents

1. Why I prefer
   Modbus over cloud integrations
2. What Modbus
   actually is in plain English
3. The two common
   paths: RS485 and Modbus TCP
4. What hardware I use
5. The core data points I
   care about
6. How I
   design a clean Home Assistant entity model
7. Basic Modbus setup
   in Home Assistant
8. A
   practical example using common inverter values
9. How I feed the Energy
   dashboard
10. Automations
    that become useful once Modbus works
11. Common
    problems and how I troubleshoot them
12. When I would use
    Solar Assistant instead
13. My final advice

---

Why I prefer Modbus
over cloud integrations

The biggest reason is simple: local data is more
trustworthy.

When I poll an inverter locally over Modbus, I know:

• where the data is coming from
• how often it updates
• which values are raw and which ones I derived
• whether an automation is acting on fresh information

With cloud integrations, I usually get at least one of these
problems:

• slow update intervals
• missing battery or load values
• broken entities after an API change
• internet dependency for a system that is supposed to help during
  outages

For a decorative dashboard, cloud data is fine.

For automations like “only charge from grid during this window if the
battery is below 35%” or “turn on a resistive dump load when excess
solar stays above 2 kW for ten minutes,” I want tighter control than
that.

What Modbus actually
is in plain English

Modbus is a simple industrial protocol for reading and sometimes
writing values from equipment.

In the solar world, that usually means the inverter exposes a bunch
of registers for things like:

• PV voltage
• PV power
• battery voltage
• battery current
• battery state of charge
• grid import/export power
• inverter mode
• daily energy totals
• fault codes

Home Assistant can poll those registers directly if you tell it:

• how to reach the inverter
• which register addresses to read
• what data type each register uses
• how to scale the raw number into a human value

That is the entire game. The hard part is not the concept. The hard
part is cleaning up bad documentation and turning raw values into
entities that make sense six months later.

The two common paths:
RS485 and Modbus TCP

Most DIY solar setups land on one of these.

RS485

This is the most common path on hybrid inverters.

You usually have:

• an inverter communication port
• a USB-to-RS485 adapter
• Home Assistant or another host connected locally

Why I like it:

• cheap
• direct
• common across lots of inverter brands
• good enough for local polling

What I watch out for:

• wrong adapter chipset
• A/B polarity reversed
• incorrect baud rate, parity, stop bits, or slave ID
• ugly vendor ports and cables

Modbus TCP

This is cleaner when the inverter or gateway exposes Modbus over
Ethernet.

Why I like it:

• easier cabling
• simpler host placement
• no USB serial weirdness
• straightforward polling from a VM or container

What I watch out for:

• undocumented port changes
• too many devices polling the same gateway
• Wi-Fi flakiness if somebody got cute with infrastructure

If I have a choice between a flaky cloud dongle and a solid local
Modbus TCP interface, I will take the local interface every time.

What hardware I use

I try very hard not to get clever here.

For RS485 setups, my preferred stack is:

• the inverter’s documented RS485 or BMS/COMMS port
• a known-good USB-to-RS485 adapter
• short, tidy cable runs
• Home Assistant on stable hardware, preferably
  Ethernet-connected

For Modbus TCP setups:

• wired Ethernet
• static DHCP reservation or fixed addressing
• a stable local network segment

This is not where I save money. A junk serial adapter can waste an
entire afternoon and teach you new words you did not need.

The core data points I care
about

I do not try to pull every register the inverter exposes. That way
lies clutter.

These are the values I care about first:

• battery SOC
• battery voltage
• battery charge/discharge current
• PV power
• load power
• grid power
• inverter operating mode
• daily solar generation
• daily load consumption if available
• fault or warning code

That set is enough to answer the questions that matter:

• Are the batteries charging?
• Is the inverter in bypass, battery, or line mode?
• Is PV actually covering the load?
• Are my time-of-use rules doing what I think they are doing?
• Is the system behaving differently than yesterday?

Everything else is optional until those answers are solid.

How I design a
clean Home Assistant entity model

This part matters more than people think.

A raw Modbus setup can quickly turn into fifty ugly sensors with
names like holding_13201 and units that make no sense. That
is how you build a dashboard nobody wants to maintain.

I standardize names early. I want entities that read like
English:

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

Then I derive anything extra with template sensors if needed.

For example, if the inverter gives me voltage and current but not
battery power, I create:

battery power = battery voltage x battery current

If the sign convention is backwards, I fix it once in Home Assistant
and never think about it again.

That is my general rule with energy telemetry: normalize the
weirdness at the edge. Do not spread it through every dashboard
and automation.

Basic Modbus setup in Home
Assistant

Home Assistant’s Modbus integration is flexible enough for most
inverter work. At a high level, I do this:

1. Identify whether I am talking RTU over serial or TCP over
   Ethernet.
2. Confirm the serial settings or IP/port from the inverter
   documentation.
3. Start with a tiny sensor set instead of importing the entire
   register map.
4. Verify the raw numbers make sense.
5. Add scaling, units, state classes, and device classes.
6. Only then build Energy dashboard entities and automations.

For serial, the structure usually includes:

• port device path
• baud rate
• parity
• stop bits
• byte size
• slave address

For TCP, it is usually:

• host
• port, often 502
• slave address or unit ID if required

The register details vary by inverter, but most setups boil down to
reading holding registers or input registers and applying the right
scale factor.

A practical
example using common inverter values

Let me show the kind of logic I use. These are example values, not
universal register addresses.

Say an inverter exposes:

• battery voltage in register 100
• battery current in register 101
• PV power in register 110
• load power in register 111
• grid power in register 112
• SOC in register 120

And say the raw values behave like this:

• battery voltage 534 means 53.4V
• battery current -185 means -18.5A
• PV power 2430 means 2430W
• SOC 82 means 82%

From that, I can build a useful picture quickly.

Example snapshot

• battery voltage: 53.4V
• battery current: -18.5A
• PV power: 2430W
• load power: 1680W
• grid power: -420W
• SOC: 82%

Battery power is:

53.4 x 18.5 = 987.9W

Depending on sign convention, that probably means the battery is
charging or discharging by about 988W. I verify which
direction is correct against live system behavior, then fix the template
once.

That single snapshot already tells me a lot:

• PV is covering the load
• there is extra solar available
• the battery is likely charging
• some power may be flowing to or from the grid depending on sign
  convention

That is enough to drive meaningful decisions. I do not need a vendor
app to animate a fake sun icon for me.

How I feed the Energy
dashboard

Once the core entities are stable, I wire them into Home Assistant’s
Energy dashboard.

This usually means making sure the relevant sensors are:

• in the right units
• marked with the correct device class
• marked with the correct state class
• totalized correctly when needed

The Energy dashboard is picky for good reason. Instantaneous power
sensors in watts are not the same thing as energy counters in kWh.

If my inverter only gives live power and not cumulative daily or
lifetime energy, I create integration sensors to accumulate:

• solar production
• battery charge/discharge energy
• grid import
• grid export
• load consumption

This is where I slow down and test carefully. Bad sign handling can
make the Energy dashboard lie with a straight face.

Automations
that become useful once Modbus works

This is where the setup starts paying rent.

Here are the kinds of automations I actually think are worth
doing.

Battery-protective load
shedding

If battery SOC falls below a threshold overnight, I can shed
discretionary loads before the inverter does something rude.

Example logic:

• if sensor.solar_battery_soc < 30
• and grid is unavailable or I am trying to avoid import
• turn off nonessential loads

Excess-solar load shifting

If PV power exceeds house load by a useful margin for a sustained
period, I can turn on a water heater, dehumidifier, or EV charging
relay.

Example:

• if PV power - load power > 1500W for 10 minutes
• and battery SOC is above 85%
• enable a discretionary load

Time-of-use charge
automation

If utility rates are cheap overnight, I can use Home Assistant to
verify the inverter actually charged when it was supposed to.

That matters because schedules configured in inverter menus sometimes
fail for dumb reasons:

• wrong clock
• wrong mode
• wrong charge source setting
• firmware weirdness

With Modbus entities in Home Assistant, I can alert when:

• charging did not start during the low-rate window
• charging continued past the stop time
• battery SOC did not reach the target by morning

Fault alerting

If the inverter throws a fault register or changes unexpectedly into
bypass/line mode, I want a notification. Quiet failures are the annoying
ones.

Common problems and
how I troubleshoot them

Most Modbus problems are boring, which is good news.

No data at all

I check:

• correct serial port or IP
• correct slave ID
• correct baud/parity/stop bits
• cable pinout
• RS485 polarity
• whether another tool already has the serial device open

Values are nonsense

I check:

• wrong register type
• wrong register offset
• wrong signed vs unsigned interpretation
• wrong word order
• missing scale factor

If I see 5340V for a 48V battery bank, I do
not assume I discovered a breakthrough in physics. I assume scaling is
wrong.

Values update, but too slowly

I check:

• scan interval set too high
• too many registers being polled
• poor network or serial quality
• a gateway that cannot handle aggressive polling

I usually prefer a smaller set of reliable sensors over a giant set
of sluggish ones.

Home Assistant restarts
break the setup

I check:

• stable USB device naming
• whether the adapter path changes after reboot
• whether the inverter needs a startup delay

On serial gear, persistent device paths are your friend. Chasing
/dev/ttyUSB-whatever roulette is a dumb hobby.

When I would use Solar
Assistant instead

I like Modbus, but I am not doctrinaire about it.

I would use Solar Assistant instead when:

• the inverter register map is terrible
• the vendor’s Modbus documentation is incomplete
• I want faster time to value
• I need a bridge for a supported inverter that is otherwise
  annoying
• I want MQTT data with less manual sensor definition

For a lot of DIY builders, Solar Assistant is the shortest
path to good local solar telemetry. I still like understanding
the Modbus layer underneath, because it helps when you need to
troubleshoot, validate readings, or go fully custom later.

My final advice

If you want a solid solar inverter Home Assistant
integration, start small and make the numbers tell the truth
before you chase pretty dashboards.

My order of operations is always:

1. get one or two registers reading correctly
2. validate them against reality
3. add the core battery/PV/grid/load sensors
4. normalize naming and units
5. feed the Energy dashboard
6. only then build automations

That sequence saves a lot of pain.

Home Assistant plus Modbus is not hard because the protocol is
advanced. It is hard because inverter vendors love inconsistent
documentation, weird sign conventions, and menus that look like they
were designed on purpose to make you second-guess yourself.

Once it is working, though, it is excellent. You get local
visibility, reliable automation inputs, and a solar dashboard that
reflects what the system is actually doing instead of what some cloud
portal felt like showing you.

That is worth the setup time.

---

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