Best Local Platforms for Balcony Solar & Battery Storage (2026)

All nine platforms in this guide communicate with balcony solar hardware over one of the same three local protocols: Modbus TCP/RTU, MQTT, or a device's local REST API. Your choice of platform does not change which physical devices you can reach — it changes the tooling you use to read and act on that data. Understanding which protocol your specific device exposes is the upstream question before choosing a platform; the companion article No-Cloud Balcony Solar: Monitor Your System With Home Assistant covers the hardware-level protocol decision (which interface a given brand exposes, and how to verify it). This article assumes a local interface exists and focuses on which software platform to run on top of it.

Modbus RTU (RS-485 serial) and Modbus TCP (Ethernet/WiFi) are the most common read-and-write interfaces on solar inverters and battery systems. Most platforms connect to Modbus TCP natively. Modbus RTU typically requires a serial-to-USB adapter or an ESPHome bridge device (see ESPHome profile below).

MQTT is the lightweight publish/subscribe messaging protocol that most local-API balcony solar devices use for real-time status broadcast. Nearly every platform in this guide can subscribe to an MQTT topic, making it the most broadly compatible connection path when a device supports it.

The right platform depends on your use case and tolerance for complexity — not on raw protocol capability, since all platforms handle Modbus and MQTT. Decide which of the following matters most before comparing products:

Each platform is described with its type classification, a concrete solar example, and a best-fit user profile. Capability claims are marked "(verified against public documentation, July 2026)" where confirmed, or "(unverified — check adapter registry)" where the claim could not be confirmed at write time.

Home Assistant — Open-source (Apache 2.0), fully local, Python-based. Runs on a Raspberry Pi, a dedicated HA Green/Yellow device, or a VM. Has official integrations and community HACS integrations covering Modbus TCP, MQTT, REST, and brand-specific integrations for SMA, Fronius, Zendure, Growatt, and others (verify against the HA integration listing for your exact model, as support varies by product line). *Example*: A Zendure SolarFlow hub publishes live SoC and power flow via its local REST/MQTT API; a HACS community integration picks up those values and an HA automation triggers the dishwasher when PV output exceeds 400 W. *Best for*: The default choice — largest community, most integrations, active control and automation.

openHAB — Open-source (EPL 2.0), fully local, Java-based. Has an official Modbus binding (read/write, Modbus TCP and RTU, verified) and HTTP/REST binding. Configuration is largely file-based; the learning curve is steeper than Home Assistant or ioBroker. *Example*: Poll a Fronius inverter's local SolarAPI endpoint every 10 seconds and trigger a rule to shift a buffer-heater schedule to midday production peaks. *Best for*: Power users and integrators who prefer a strict, enterprise-grade automation framework, or who have existing openHAB deployments.

ioBroker — Open-source (MIT), fully local, Node.js-based. The German-language community is the strongest of any platform in this list for DACH users. Has a Modbus adapter (verified), MQTT adapter (verified), and brand-specific adapters including Fronius (fronius adapter, verified), Hoymiles via OpenDTU bridge (verified), and SMA Energy Meter (sma-em adapter — unverified, check ioBroker adapter repository for current maintenance status). VIS dashboard provides visualisation without a separate tool. *Example*: Read a Sungrow inverter via the Modbus adapter and display daily battery SoC as a bar chart in the VIS dashboard. *Best for*: DACH users already in the ioBroker ecosystem, or users who prefer German-language documentation and community forums.

Node-RED — Open-source (Apache 2.0), fully local, Node.js-based visual flow editor. Modbus TCP/RTU nodes are available via the node-red-contrib-modbus npm package (unverified — check current package maintenance status on npm). MQTT nodes are built in. HTTP request nodes support REST. Usually paired with Home Assistant or ioBroker as a data-transformation or automation companion rather than as a standalone platform. *Example*: Pull data from a Hoymiles microinverter via MQTT, compute 15-minute averages, and push the result to an InfluxDB instance for Grafana visualisation. *Best for*: Users who prefer visual flow programming or who need custom data-transformation logic between two systems.

EVCC — Open-source (MIT), German-origin (evcc.io), fully local. Purpose-built for PV-surplus EV charging and zero-feed-in control. Ships with a template library covering dozens of inverter and battery brands including Fronius, SMA, Kostal, Growatt, Huawei SUN2000, Victron, BYD, and many more (verify against evcc.io/docs/devices for your exact model and firmware). Publishes data via MQTT for integration with Home Assistant or ioBroker. *Example*: A Kostal Plenticore Plus inverter and a Volkswagen ID.4 are registered as EVCC devices; EVCC monitors PV surplus every 10 seconds and dynamically adjusts the EV charge rate to keep grid import near zero. *Best for*: EV + balcony solar users who want surplus charging without running a general automation platform; also DACH users (EVCC is German-developed with German-language documentation).

Solar Assistant — Commercial (proprietary licence, one-time ~$30–40 — verify current pricing at solar-assistant.io), locally installed on a Raspberry Pi 3, 4, or 5 via a pre-configured image. Supports many inverter brands via Modbus RTU/TCP (verify the supported-devices list on the Solar Assistant website for your model). Outputs data via MQTT to a local broker; a companion Home Assistant integration is available via HACS (unverified — check HACS for current status). Solar Assistant does not send write commands to inverters — it is monitoring-only. *Example*: Connect a Growatt SPH inverter via Modbus RS-485 cable to the Raspberry Pi; Solar Assistant reads production, battery SoC, and consumption and publishes them via MQTT to Home Assistant for dashboard display and automation. *Best for*: Non-technical users who want a quick, turnkey monitoring setup and are willing to pay once rather than configure a platform from scratch.

Victron Venus OS / Cerbo GX — Open-source base (GPL), sold as vendor hardware (Victron Energy, Netherlands) in the form of the Cerbo GX or Ekrano GX, but also available as a free Raspberry Pi image (VenusOS — verify compatibility with your Pi hardware version at the Victron community forum). Has a built-in local MQTT broker; the optional VRM cloud portal is not required for local use. Reads and writes Victron-brand equipment natively over VE.Can, VE.Direct, or VE.Bus. Third-party devices connect via Modbus TCP or community-written drivers. *Example*: A Victron Cerbo GX acts as the hub for a Victron MPPT charge controller and a BYD battery module; Venus OS publishes all values via local MQTT, which an EVCC instance subscribes to for EV surplus-charging control. *Best for*: Existing Victron equipment owners; off-grid or hybrid systems where Victron is the system integrator.

Grafana + Telegraf + InfluxDB — Open-source monitoring and analytics stack (Grafana OSS, Telegraf, InfluxDB OSS). Telegraf collects data via MQTT subscriber, HTTP scrape, or other input plugins; InfluxDB stores time-series data; Grafana visualises it. No automation or control capability — this is analytics and dashboarding only. *Example*: Telegraf subscribes to the MQTT topic published by a Solar Assistant instance, writes solar yield and SoC values into InfluxDB, and Grafana displays a week-on-week production comparison dashboard. *Best for*: Users who already have data flowing from another platform and want professional historical analytics on top of it.

ESPHome (standalone) — Open-source (MIT), firmware for ESP32 and ESP8266 microcontrollers. ESPHome is not a monitoring platform — it is a bridge: you flash an inexpensive ESP32 board (~€5–15) with ESPHome firmware configured to communicate over Modbus RTU via an RS-485 transceiver, and it exposes that data to the network as MQTT messages or as a Home Assistant native API device. *Example*: A solar inverter exposes only a Modbus RS-485 port with no WiFi or Ethernet. An ESP32 with an RS-485 transceiver module, flashed with ESPHome's modbus_controller component, reads the inverter registers and publishes them to the home MQTT broker that Home Assistant, ioBroker, or EVCC then subscribes to. *Best for*: DIY users where the inverter only exposes Modbus RTU over RS-485 and a hardware WiFi bridge is needed before any software platform can connect.

Match your situation to one of these short scenarios — each maps to a platform recommendation based on verified capabilities as of July 2026.

These are the most common integration mistakes — check each before assuming your setup will work cleanly.

The platforms in this guide are software — mostly EU and community open-source — with no direct exposure to trade tariffs. The hardware they connect to is a different matter: dominant balcony-storage brands (Anker, EcoFlow, BYD, Growatt, Marstek, Zendure) are Chinese-manufactured and subject to EU–China anti-dumping measures on cells, inverters, and battery packs, as well as US Section 301 tariffs on Chinese-origin energy storage equipment. European brands (Kostal, SMA DE, Fronius AT, Victron NL) are less directly exposed to these measures.

Platform choice is trade-neutral — the software runs on any hardware once it is connected. But keep hardware pricing dynamic: tariff-affected storage prices can shift on short notice, and prices that appear competitive when you research may not hold by the time you purchase.