Battery SmartFlow AI
PalmManiac/battery-smartflow-ai · v5.2.6
Battery SmartFlow AI is an intelligent, Home Assistant-based Home Energy Management System for forecast-driven, PV-optimized, and price-optimized battery storage control.
In Apple Home through HomeKit Bridge
What HomeKit Bridge makes of each kind of entity this integration creates, read from its source code. A device only gets the ones that apply to it.
| Entity | Shows up as | Note |
|---|---|---|
sensor | Sensor (temperature, humidity, air quality…) | |
select | Mode picker (as switches) |
What people report
Zendure batteries (Hyper 2000, SolarFlow Hub 2000, SolarFlow 800 Pro, SF2400AC) are controlled via ZenSDK, local MQTT or cloud MQTT, with Shelly meters for grid power. Legacy Zendure models needed extra work on cloud control and log-spam fixes.
- Works5
- Partly works2
- Requested1
| Device | In Home Assistant | In Apple Home | What they said | Source |
|---|---|---|---|---|
| Shelly 3EM (Gen1) | Works Local | Local /status API grid metering with optional Basic authSaved copySummary - Add a separate grid-metering mode for the classic Shelly 3EM (Gen1), using its local /status API and signed three-phase total power. - Support optional Gen1 Basic authentication while warning users that the HTTP connection is unencrypted. - Add translated setup fields and update German/English user guides. - Add parser and local-request tests without changing the existing Pro 3EM Gen2 adapter. ## Validation - Shelly 3EM Gen1 tests: 6 passed. - Shelly Pro 3EM tests: 6 passed. - Translation tests: 11 passed. - Python compilation and JSON validation passed. - HA-dependent config-flow … Excerpt saved from GitHub on 2026-10-23. | PR #616 · 2026-09 | |
| Shelly Pro 3EM | Works Local | Direct local HTTP-RPC grid metering added; Modbus TCP also selectableSaved copySummary - Add an optional direct local HTTP-RPC grid source for the Shelly Pro 3EM Gen2, independent of the Home Assistant Shelly integration, aioshelly, and Shelly Cloud. - Read signed total power (positive import, negative export), including phase-sum fallback, with local SHA-256 Digest authentication support. - Expose the local reading to BSFAI control and the dashboard while leaving the regulation cadence unchanged. - Keep existing entity registry compatibility and add translations in DE/EN/FR/NL. ## Validation - Shelly RPC/authentication tests, translation coverage, dashboard contract, … Excerpt saved from GitHub on 2026-10-23. | PR #609 · 2026-09 | |
| Zendure Hyper 2000 | Works | Cloud MQTT control via deviceAutomation; local MQTT read path added; control freshness window adjustedSaved copySummary - Route Hyper 2000 and HUB 2000 Cloud MQTT commands through the model-appropriate deviceAutomation payload. - Keep ZenSDK property writes unchanged and validate the invocation payload before publishing. - Add protocol, command-matrix, and readback tests. ## Validation - Targeted suite: 88 passed, 64 subtests passed. - Broader suite (excluding unavailable dependency-bound modules): 1,018 passed; one existing sensor-attribute-budget assertion still expects 60 diagnostics while the current source exposes 61. - Hardware verification is still needed for an actual Hyper Cloud command. - No … Excerpt saved from GitHub on 2026-10-23. | PR #738 · 2026-10 | |
| Zendure SF2400AC | Works | Model-specific Smart Mode standby profile in 5.2.0-rc02Saved copySummary - Keep Smart Mode 1 for active charging and discharging commands, and select the zero-power standby value from the exact Zendure model profile. - Use Smart Mode 0 for SF2400AC only when off-grid power is confirmed at zero. Keep Smart Mode 1 when off-grid power is active or unknown; other supported property-controlled models use Smart Mode 1 in standby. - Add Cloud MQTT and ZenSDK coverage and prepare the 5.2.0-rc02 version and release notes. - The model distinction reflects field reports, not an official Zendure compatibility specification. ## Validation - Targeted pytest: 51 passed, … Excerpt saved from GitHub on 2026-10-23. | PR #788 · 2026-10 | |
| Zendure SolarFlow Hub 2000 | Works Local | Local MQTT command adapter and cloud MQTT routing addedSaved copyImplementation is available in PR #425 as part of the combined #337–#339 Dev24 block. The PR adds the allowlisted Hyper 2000 and SolarFlow Hub 2000 Local MQTT command adapter, exact function/invoke routing, readback verification, diagnostics, and fail-closed behavior for unsupported Hub AC-input commands. Live INPUT/OUTPUT/stop and reconnect validation still requires a real, already broker-provisioned Legacy device, so this issue intentionally remains open. Excerpt saved from GitHub on 2026-10-23. | Issue #339 · 2026-08 | |
| Zendure (EU cloud accounts) | Partly works Cloud | Cloud MQTT produced thousands of log errors in 5.x; fixed Oct 2026Saved copy… (der Zähler wächst stetig an): Dieser Fehler stammt von einer benutzerdefinierten Integration Logger: custom_components.battery_smartflow_ai.hardware.zendure.cloud_mqtt Quelle: custom_components/battery_smartflow_ai/hardware/zendure/cloud_mqtt.py:480 Integration: Battery SmartFlow AI (Dokumentation, Probleme) Erstmals aufgetreten: 20:46:27 (18 Vorkommnisse) Zuletzt protokolliert: 20:49:20 Zendure Cloud MQTT disconnected; waiting for broker reconnect: Unspecified error, , - Dieser Fehler stammt von einer benutzerdefinierten Integration Logger: … Excerpt saved from GitHub on 2026-10-23. | Issue #669 · 2026-10 | |
| Zendure SolarFlow 800 Pro | Partly works Local | ZenSDK local works; firmware and Wi-Fi diagnostic entities showed Unavailable, since fixedSaved copyIssue: Diagnostic entities permanently "Unavailable" on ZenSDK (Firmware / Wi-Fi status on the main unit) ## Description On a SolarFlow 800 Pro 2 connected via direct Zendure / ZenSDK (local), several diagnostic entities of the main device are permanently shown as `Unavailable`, even though the device and the integration work correctly otherwise: - Firmware (main unit) → `Unavailable` - Wi-Fi status → `Unavailable` These entities are created unconditionally for every main system (see `sensor.py` `add_discovered_native_entities()`), regardless of whether the selected transport actually … Excerpt saved from GitHub on 2026-10-23. | Issue #654 · 2026-10 | |
| Shelly Pro 3EM (Local Network Messaging) | Requested Local | LNM push input requested; owner plans optional experimental support after V5.2Saved copyFeature Request: Add Shelly Pro 3EM Local Network Messaging (LNM) support ## Summary Add support for Shelly Pro 3EM Local Network Messaging (LNM) as a grid-power input in Battery SmartFlow AI (BSFAI). The current implementation reads the Shelly Pro 3EM using local HTTP RPC polling: [code] This works, but LNM would allow the Shelly to push its measurements to BSFAI over the local network using UDP multicast. ## Current behavior In the current `5.2.0-dev02` implementation, the Shelly Pro 3EM grid power is obtained through local HTTP: [code] The Shelly is polled periodically by BSFAI. For a … Excerpt saved from GitHub on 2026-10-23. | Issue #700 · 2026-10 |
Gathered from GitHub issues, pull requests, discussions and docs, and from r/homeassistant. These are individual reports, so check the linked thread and the date before you buy.
How it connects
Local polling
Talks to the device on your network, asking it for updates every so often.
Details
| Installs (analytics) | 100 (0.01%) |
|---|---|
| GitHub stars | 70 |
| Latest version | 5.2.6 (2026-10-23) |
| Set up in the UI | Yes |
| Maintainers | @PalmManiac |
| License | MIT |
In ReReHome
Whatever HomeKit Bridge shares reaches Apple Home as normal HomeKit accessories behind your Home Assistant bridge, so ReReHome shows and controls them like any other.
Bridges get their own settings page listing the accessories behind them.