Solar Inverter and Battery Logger Over RS485 for Homes and Small Offices

The problem solar owners have with their inverter data

Rooftop solar with a hybrid inverter and batteries is now common in homes, clinics, schools and small offices, especially where grid outages are frequent. The owner paid a lot for the system and wants to know whether it is working. The inverter knows everything (panel output, battery state, grid status) but it hides that behind a small screen, a vendor Wi-Fi dongle and a cloud app that is slow, stops working when the vendor changes its servers, and shows numbers without meaning. Owners do not know whether their batteries are being run too deep and will die early, whether dust on the panels is costing them output, or how many hours the grid was actually off last month. Installers who maintain dozens of sites have no single view across brands.

What already exists and the gap

• Solar Assistant runs on a Raspberry Pi, reads many inverter brands locally and is well regarded; it is a paid, closed product focused on hobbyist dashboards.
• Vendor cloud apps such as those shipped with Growatt, Deye or Solis dongles give basic charts, depend on the vendor cloud and only cover their own brand.
• Open source ESPHome configurations on GitHub read specific inverters over RS485 into Home Assistant, which suits enthusiasts who already run Home Assistant.

The gap is a low-cost, local-first logger that supports several brands through data files, keeps working offline, and explains what the numbers mean for an ordinary owner or a small installer business.

What you build

• Logger hardware: an ESP32 with an RS485 transceiver wired to the inverter's communication port.
• Firmware: a Modbus RTU client that reads a register map, scales values, buffers them locally and publishes over MQTT.
• Backend: MQTT ingestion, time-series storage and a rules engine for alerts.
• Dashboard: daily and monthly views, outage timeline, battery health and plain-language advice.

Roles: the owner, who sees one site, and the installer, who sees many sites and gets fault alerts.

The technically interesting part

Inverters do not share a protocol. Each brand, and sometimes each firmware version, has its own register addresses, scaling factors, signed and unsigned formats and quirks such as values split across two registers. The interesting engineering is a data-driven design: firmware that knows only how to read registers, and register maps that describe everything else. You will also deal with a shared bus where the vendor dongle may also be polling, timeouts, CRC errors and partial reads. Show evaluators how adding a second brand needed only a new map file, and show error rates on the bus over weeks.

How to evaluate it

• Agreement with the inverter's own display and vendor app for PV power, battery state of charge and daily yield, as mean absolute error.
• Bus reliability: percentage of successful polls over three weeks, and recovery time after an unplugged cable.
• Outage detection: compare detected grid outages against a manual log or the utility's schedule for a week.
• A short usability test with five owners: can they answer "is my system healthy?" from the dashboard in under a minute?

Suggested plan

1. Month 1: get documentation for two inverter models, build an RS485 test setup, read raw registers.
2. Month 2: register map format, parser and scaling, with unit tests against captured frames.
3. Month 3: buffering, MQTT and time-series storage.
4. Month 4: dashboard, outage timeline and monthly report.
5. Month 5: rules engine and alerts.
6. Month 6 to 7: field deployments, accuracy comparison and report.

Path to a product

The first customer is a small solar installer who maintains many residential and clinic systems and wants to spot faults before the customer calls. Sell loggers at a small margin and charge the installer a monthly fee per site for the multi-site dashboard. Direct sale to owners is a second channel. The register map library becomes an asset: every supported brand widens the market.

Scope warning

Do not write settings to the inverter in the core project; reading is safe, writing can damage equipment and void warranties. Do not try to support every brand; two done well is the goal. Do not build a battery chemistry model beyond simple cycle and depth-of-discharge tracking.

Learn what you need on Sefism

• Programming roadmap : bit manipulation, byte order and data structures you need to decode registers.
• System design roadmap : ingestion, storage and alerting design for many sites.
• Beej's Guide to Network Programming : the mental model for framing, timeouts and retries on any link.
• Wireshark User Guide : inspecting MQTT and network traffic when data goes missing.
• PostgreSQL Documentation : storing readings and building monthly aggregates.

Get help with this idea

The register map design is the part worth getting feedback on early. If you want a second opinion on scope, hardware choices or how to set up the evaluation before you commit, bring your plan and your bill of materials and we will pressure-test it together. New here? Create a free account first.

• Discuss this idea with a mentor
• Send a query to Tauseef
• Book a 1:1 session