ha-solarman pulls data out of Solarman inverters and loggers into Home Assistant

What the integration actually connects to

Solarman Stick Logger is described as a Solarman Stick Logger integration for Home Assistant, and the important part of the name is the last two words. A Solarman logger is a small device that sits between your solar inverter and the internet, and the logger speaks a vendor-specific variant of Modbus to the inverter.

That variant is the whole problem this project solves. The README says the integration is built on asynchronous pysolarmanv5 and supports Modbus TCP, and it names three ways to reach it: an ESP bridge, a Waveshare RS485 to Ethernet adapter, and an Ethernet logger from Solarman PV. All three are effectively the same thing, an Ethernet device that forwards Modbus TCP to the inverter's RS485 port, and the supported device list in the topics shows the breadth of the vendor coverage: AFORE, Deye, Kstar, Microtek, Pylontech, Sofar, Sol-ARK, Solax, Solis, Sunsynk and ZCS.

So the integration is a Home Assistant front end over pysolarmanv5, which is the library that knows the register layouts for each of those brands. The Home Assistant component handles discovery, the config flow, the polling schedule and turning registers into entities.

The primary language is Python, the licence is MIT, the default branch is main, and the last push was on 2026-05-03. The recent releases are v26.01.31 from 2026-01-31, v26.01.02 from 2026-01-03 and v25.12.20 from 2025-12-20, and the version numbering follows a date-based scheme.

The repository is a Home Assistant custom component rather than a library, and the top-level entries show it: custom_components/ holds the integration itself, hacs.json declares it to the Community Store, and there is a tools/ directory, presumably for the scripts that generate or check the device data.

The README also credits Stephan Joubert's Home Assistant Solarman integration as the inspiration, which is the normal courtesy in this ecosystem where one integration grows out of another.

Installing through HACS, and the manual fallback

There are two installation routes and the first is by far the easiest.

The Home Assistant Community Store, HACS, route is the one the README leads with. You open your Home Assistant instance, open a repository inside the Home Assistant Community Store, go to the Solarman repository, check that it is the right one using the displayed frontpage, and click DOWNLOAD. The badge in the README is labelled HACS Supported and links to the custom-components directory of the HACS repository.

The manual route is one line. You copy the contents of custom_components/ to /homeassistant/custom_components/, which is the standard path where Home Assistant looks for integrations you have installed yourself.

The reason to know the manual route is that it is what you need when you are running Home Assistant in a way where the Community Store is awkward, such as a container with a mounted configuration directory, or when you are pinning a specific version because a newer one broke something. Both routes end with the same directory in the same place, which is worth knowing because it means the difference between the two is only how the files arrive.

Configuration then follows the standard Home Assistant flow. You go to Settings, Devices and services, Integrations, click ADD INTEGRATION, search for and select Solarman, enter the appropriate details, which should be autodiscovered under most circumstances, and click SUBMIT.

That autodiscovery is the part worth understanding. The README only says the details should be autodiscovered under most circumstances without explaining how, so treat it as the common case working out of the box and the details you enter as the exceptions, such as a logger on a different subnet or behind a firewall.

The badge at the top of the configuration section links straight to the Home Assistant configuration flow start page for the solarman domain, which is the same route the UI takes, so the documentation and the interface cannot drift apart.

The wiki is where the documentation lives, not the README

The README is short, and that is a structural fact rather than an omission. The content is organised into wiki pages, and the signpost section at the top lists them.

There is a page on Automations, one on Custom Sensors, one on Dashboards and one on Documentation. Then two that tell you what the integration produces rather than how to install it: a Naming Scheme page and a Supported Devices page.

The Supported Devices page is the one to check first, because the topic list of inverter and logger brands is a summary rather than the full table. The brands named in the topics are AFORE, Deye, Kstar, Microtek, Pylontech, Sofar, Sol-ARK, Solax, Solis, Sunsynk and ZCS, and the wiki page is where the model-by-model detail would be.

The Naming Scheme page is the one that saves the most time after installation. A Home Assistant integration that polls a dozen registers creates entities with names derived from those registers, and the naming convention determines what your sensors are called in dashboards, in automations and in the energy dashboard. If the integration names entities by register address you get unreadable names, and if it names them by a scheme you have to learn, and either way the naming page is the reference.

The Custom Sensors page is what turns the integration from a data feed into something useful. A stock integration exposes the registers the vendor documents. A custom sensors page suggests the integration can expose derived values, the ones a vendor's app shows but does not put on the Modbus map.

The project also links a community forum thread on the Home Assistant community site, a Discussions page for Q&A and development planning, and a Milestones page for what is planned next. The issues are reserved for bug reporting, which is the usual split in the custom component ecosystem where a chatty issue tracker is a support burden.

The signpost also points at a changes section, and the README marks it important, telling users to read about important changes and new features. For an integration that talks to a device over a wire protocol, behaviour changes between versions are exactly where an upgrade goes wrong, so that instruction is the one to follow before updating.

Why an inverter logger needs its own integration at all

The reason this project exists is a piece of hardware that most people forget about.

A grid-tied solar inverter does not normally talk to the network. It has a serial port, usually RS485, wired to a small logger box, and that logger is what holds the network connection. The logger speaks a Modbus-like protocol to the inverter and exposes the data over the network, either on a local port or through the vendor's cloud service.

That arrangement creates three problems for a Home Assistant user, and the integration addresses all three.

The first is the protocol. Modbus is a register-oriented protocol where you read numeric registers, and each vendor maps its own meaning onto those register numbers. A generic Modbus integration can read the registers but has no idea what register 30001 means on a Deye inverter, and the layout differs by model and sometimes by firmware version. pysolarmanv5 is the layer that holds those mappings, and the device list in the repository topics reflects how much per-model work that is: eleven brands named, each with its own register semantics.

The second is the network path. The logger is on the local network, reachable over TCP, and the transports the README names are all ways of putting Modbus TCP in front of the inverter's serial port: an ESP-based bridge, a Waveshare RS485 to Ethernet adapter, or the vendor's own Ethernet logger. Talking to it directly over TCP is faster and works without the vendor's cloud, which is what a Home Assistant integration wants, because Home Assistant polls on its own schedule and does not want a round trip through somebody else's data centre to get a current power reading.

The third is the polling discipline. An inverter exposes far more registers than any dashboard needs, and polling all of them on a short interval wastes the logger's serial bandwidth and, on some models, triggers a warning or a restart. A purpose-built integration polls a curated set of registers at a sensible rate and exposes named entities.

None of this is exotic, and all of it is per-model fiddly. That combination, a well-specified protocol with an annoying amount of vendor variation, is the exact shape of work that suits a community integration better than a commercial product, and it explains the shape of this repository.

What the repository tells you about maintenance and community practice

The badge row and the repository layout describe a project that runs on community practice rather than a company schedule, and the details are useful for anyone deciding whether to depend on it.

There is a HACS Supported badge, which means the integration is listed in the official custom-components directory of the Home Assistant Community Store, and that listing carries expectations: the repository has to be installable through the standard mechanism, which is why the custom_components/ directory layout is fixed and why hacs.json exists at the root to declare the integration's metadata.

There is a Community Forum badge pointing at a thread on the Home Assistant community site, a Discussions badge, and a Wiki badge. That is the standard trio for a custom component that has outgrown a single issue thread.

The README states the division of labour explicitly. Discussions are for Q&A, development planning and feature requests, and issues are for bug reporting. And there is a Milestones page for what is planned next, which is the mechanism that stops feature requests from becoming an undifferentiated backlog.

The release history shows a date-based version scheme, v26.01.31, v26.01.02 and v25.12.20, with the last push on 2026-05-03. Date-based versions are common in this ecosystem and are convenient for an integration that releases when a device or a Home Assistant release forces it, but they are not semver and they do not tell you about breaking changes on their own. That is precisely why the README points you at the changes section of the wiki, and why a reader planning an upgrade should read it.

The tools/ directory at the root of the repository is the part with the least documentation and probably the most interest to a maintainer. In an integration that covers eleven inverter brands, most of the real work is in the register tables, and a tool that helps extract or check them is likely how the device coverage was extended in the first place. The README does not document it, so anyone looking to contribute to device support has to read the code.

The project credits Stephan Joubert's Home Assistant Solarman integration as the inspiration, and the wiki pages for Automations, Dashboards and Custom Sensors suggest that the maintainer expects users to build things on top of the entities rather than only consume them.

Editorial conclusion

Adopt ha-solarman if you have a Solarman-connected inverter or logger and want its production data in Home Assistant, because it handles the Modbus TCP conversation and the vendor-specific register layouts that would otherwise take a weekend to reverse-engineer. Do not adopt it expecting to control the device, because the README describes reading data and building sensors rather than issuing commands to the inverter. Verify first that your exact logger or inverter model appears in the Supported Devices wiki page, that your logger exposes Modbus TCP rather than only a serial or cloud connection, since the transports named are ESP-based bridges, a Waveshare RS485 to Ethernet adapter and an Ethernet logger, and that you check the changes wiki section before upgrading, because the README flags crucial changes and new features there.

Frequently asked questions

Official sources

1. davidrapan/ha-solarman on GitHub
2. Issues
3. License: MIT
4. README
5. Releases