This repository documents my personal Home Assistant setup for using Predbat with a Huawei inverter, Huawei battery, Nordpool electricity prices, Forecast.Solar forecasts with Open-Meteo backup and a go-eCharger EV charger.
Predbat is a Home Assistant/AppDaemon-based tool that predicts and optimizes home battery charging and discharging based on electricity prices, solar forecasts, household load and other energy data.
The goal of this setup is to:
- charge the home battery when electricity is cheap,
- discharge or export when electricity prices are high,
- use solar production more intelligently,
- prevent the EV charger from draining the home battery,
- reduce unnecessary battery cycling,
- protect the main fuse by limiting battery charging during high house load,
- and provide a documented example for other Huawei Solar users.
This is my own working setup and should be treated as an example, not a universal plug-and-play solution.
I am not an expert in programming, energy management, Huawei Solar, Predbat or Home Assistant.
This setup is based on my own testing, troubleshooting and experimentation. It works in my installation, but it has not been fully reviewed or tested across all Huawei inverter, Huawei battery, Home Assistant or Predbat setups.
Use this configuration at your own risk.
Before enabling active control:
- verify all entity IDs in Home Assistant,
- start Predbat in monitor/read-only mode,
- test all service calls manually,
- use low power limits during initial testing,
- monitor the inverter, battery and Home Assistant logs carefully.
I take no responsibility for issues, incorrect behaviour, energy cost, battery wear, service call errors or damage caused by using this setup.
Home Assistant is used as the central platform for:
- energy monitoring,
- sensor aggregation,
- automation logic,
- MQTT control,
- Lovelace dashboards,
- and Predbat/AppDaemon integration.
Predbat is used for battery planning and optimization.
Key functions used:
- charge/discharge planning,
- export planning,
- import/export price optimization,
- car charging planning,
- Manual API overrides,
- battery reserve handling,
- and plan/status sensors for dashboards.
The setup uses a Huawei inverter and a Huawei battery through the Home Assistant Huawei Solar integration.
In my setup:
- battery SOC is read from Huawei battery sensors,
- battery power is inverted for Predbat,
- max charge/discharge power is controlled through Huawei number entities,
- forcible charge/discharge services are used for active control,
stop_forcible_chargeis used as the stop command for both charge and discharge modes.
The setup uses Predbat inverter type:
inverter_type: "HU"The tested installation uses the Huawei inverter operating mode Maximise self-consumption. Other Huawei systems may require different settings depending on inverter model, firmware and integration configuration.
My battery is a Huawei LUNA battery with approximately 10 kWh nominal capacity.
I currently use:
soc_max:
- 10
reserve:
- 5
battery_min_soc:
- number.batteries_end_of_discharge_socThe normal reserve is 5%, while the absolute minimum SoC follows the Huawei end-of-discharge entity.
Nordpool electricity prices are used for import and export price optimization.
Predbat receives import and export price data through Home Assistant sensors.
Forecast.Solar is used as the primary solar forecast, with Open-Meteo configured as a backup. Predbat uses the forecast to decide when to charge, discharge, export or preserve battery energy.
A go-eCharger is used for EV charging.
Predbat decides when the car should charge through:
binary_sensor.predbat_car_charging_slotA Home Assistant automation sends MQTT commands to the go-eCharger to enable or disable charging depending on Predbat’s car charging slot.
This repository contains my current working examples for:
- Predbat
apps.yaml, - Huawei Solar service templates,
- Home Assistant automations,
- go-eCharger control,
- Predbat Manual API overrides,
- P1 meter based charging limitation,
- Lovelace dashboard cards,
- and supporting Home Assistant helpers/sensors.
The Huawei integration is controlled using Predbat service templates.
Example:
charge_start_service:
service: huawei_solar.forcible_charge_soc
device_id: YOUR_HUAWEI_DEVICE_ID
target_soc: "{target_soc}"
power: "{power}"
charge_stop_service:
service: huawei_solar.stop_forcible_charge
device_id: YOUR_HUAWEI_DEVICE_ID
discharge_start_service:
service: huawei_solar.forcible_discharge_soc
device_id: YOUR_HUAWEI_DEVICE_ID
target_soc: "{target_soc}"
power: "{power}"
discharge_stop_service:
service: huawei_solar.stop_forcible_charge
device_id: YOUR_HUAWEI_DEVICE_IDThe Huawei device_id must be included in each service block. It may be entered directly or referenced through AppDaemon secrets if secrets are configured correctly.
The current setup uses Forecast.Solar with Open-Meteo backup:
forecast_solar:
- latitude: !secret predbat_home_latitude
longitude: !secret predbat_home_longitude
kwp: 10.5
azimuth: 132
declination: 18
efficiency: 0.95
forecast_solar_open_meteo_backup: true
open_meteo_forecast:
- latitude: !secret predbat_home_latitude
longitude: !secret predbat_home_longitude
kwp: 10.5
azimuth: 132
declination: 18
open_meteo_forecast_max_age: 2.0The azimuth convention is North 0, East -90, South ±180, West +90.
In my Huawei setup, the raw Huawei battery power sensor has the opposite sign compared to what Predbat expects.
Therefore I use:
battery_power:
- sensor.batteries_charge_discharge_power
battery_power_invert:
- trueWith this configuration, Predbat shows:
positive battery_power = battery discharging
negative battery_power = battery charging
This has been verified in my installation.
The basic Huawei behaviour tested so far is:
| Predbat status | Expected behaviour |
|---|---|
| Demand | Normal operation. Battery may support the house. |
| Charging | Predbat starts Huawei forcible charge. |
| Exporting | Predbat starts Huawei forcible discharge/export. |
| Stop | Predbat calls huawei_solar.stop_forcible_charge. |
This basic control path is currently the most important part of the setup.
Predbat also supports freeze and hold-style behaviour, but I currently treat this as experimental for Huawei.
Potential Huawei mapping:
| Predbat mode | Possible Huawei action |
|---|---|
| Hold / Freeze charge | Set maximum discharging power to 0 W |
| Freeze export | Set maximum charging power to 0 W |
| Demand | Restore charge/discharge limits to normal values |
Freeze capability is currently disabled in the inverter override until the Huawei behaviour has been tested more thoroughly.
Current configuration:
inverter:
support_charge_freeze: false
support_discharge_freeze: falseRecommended starting point:
Set Charge Freeze = OFF
Set Export Freeze = OFF
Set Freeze Export during Demand = OFF
Set discharge During Charge = OFF
Once the basic setup is stable, freeze/hold behaviour can be tested carefully.
The go-eCharger is controlled from Predbat using:
binary_sensor.predbat_car_charging_slotWhen Predbat wants the car to charge, the sensor turns on. When the car should not charge, the sensor turns off.
Example MQTT automation:
alias: Predbat Car Charging Slot go-e
description: Startar eller stoppar go-eCharger beroende på Predbats laddslot.
mode: single
triggers:
- trigger: state
entity_id: binary_sensor.predbat_car_charging_slot
conditions: []
actions:
- variables:
goe_charger_id: "265216"
goe_topic: "go-eCharger/{{ goe_charger_id }}/frc/set"
- choose:
- conditions:
- condition: state
entity_id: binary_sensor.predbat_car_charging_slot
state: "on"
sequence:
- action: mqtt.publish
data:
topic: "{{ goe_topic }}"
payload: "2"
qos: 0
retain: false
- conditions:
- condition: state
entity_id: binary_sensor.predbat_car_charging_slot
state: "off"
sequence:
- action: mqtt.publish
data:
topic: "{{ goe_topic }}"
payload: "1"
qos: 0
retain: falseChange this value to match your own go-eCharger ID:
goe_charger_id: "265216"For EV charging, these Predbat settings are important in my setup:
Allow car to charge from battery = OFF
Car charging hold = ON
Car energy is reported in load data = ON
Car Charging Plan Smart = ON
Octopus Intelligent Charging = OFF
This allows Predbat to plan EV charging while trying to avoid using the home battery to charge the car.
I use P1 meter data to reduce Huawei battery charging during high house load.
This is useful when cooking, charging the car, running heating loads or when one phase approaches the main fuse limit.
My P1 sensors include:
sensor.p1_meter_current_phase_1
sensor.p1_meter_current_phase_2
sensor.p1_meter_current_phase_3
sensor.p1_meter_current
sensor.p1_meter_powerThe logic is:
Normal daytime battery charge limit: 4000 W
High house load or high phase current: reduce battery charging to 1000 W
Evening/night: remove the daytime limit
Discharge is not limited by this automation
This is handled through the Predbat Manual API, for example:
option: "inverter_limit_charge(0)=4000"and:
option: "inverter_limit_charge(0)=1000"Only the battery charge limit is changed. The discharge limit is left untouched so the home battery can still support the house.
Predbat’s Manual API is used for temporary overrides, such as limiting charge power during high load.
Example:
action: select.select_option
target:
entity_id: select.predbat_manual_api
data:
option: "inverter_limit_charge(0)=4000"To remove a specific override:
action: select.select_option
target:
entity_id: select.predbat_manual_api
data:
option: "[inverter_limit_charge(0)=4000]"Avoid using:
option: "off"unless you intentionally want to clear all Manual API overrides.
I use Lovelace cards to monitor:
- Predbat status,
- Huawei battery SOC,
- Predbat battery power,
- Huawei max charge power,
- Huawei max discharge power,
- car charging slot,
- active Manual API override,
- and the Predbat plan summary.
The Predbat plan summary is available from:
predbat.plan_htmlExample markdown card:
type: markdown
title: Predbat analysis
content: |
{{ state_attr('predbat.plan_html', 'text') }}The full HTML table can also be displayed, but it can be very large:
type: markdown
title: Predbat plan
content: |
{{ state_attr('predbat.plan_html', 'html') }}Predbat includes an optional machine-learning load predictor.
For a new installation, it can be useful to enable the ML component first without immediately using its predictions for battery planning:
battery_scaling_auto: true
load_ml_enable: true
load_ml_source: false
temperature_enable: trueWith this configuration, Predbat collects historical data, trains the model and exposes the ML forecast, but continues to use the normal load forecast for battery planning.
The ML model requires at least one day of historical data before initial training. Seven or more days are recommended for a more useful forecast.
After the model has collected enough history and the predictions appear stable and reasonable, enable the ML forecast as the planning source:
load_ml_source: truePredbat normally fetches up to 28 days of available Home Assistant history and can accumulate a longer local history in its ML database.
The watch list is configured as:
watch_list:
- '+[car_charging_soc]'
- '+[car_charging_now]'
- '{metric_octopus_import}'
- '{metric_octopus_export}'List-based configuration items use +[name]; single-value items use {name}.
Predbat database settings:
db_enable: true
db_days: 30
db_mirror_ha: true- Predbat reads Huawei SOC correctly.
- Predbat reads Huawei battery power correctly.
battery_power_invert: truegives the correct Predbat sign convention.- Huawei forcible charge works manually.
- Huawei forcible discharge works manually.
- Predbat stop services now send the correct
device_id. - Predbat can enter export mode and control Huawei discharge.
- go-eCharger can be controlled from Predbat car charging slot.
- P1 meter based charge limiting works through Manual API.
- Predbat dashboard card shows useful status and plan text.
- Long-term stability.
- Behaviour across different Huawei inverter models.
- Freeze and hold modes.
- Whether Huawei-specific documentation should be proposed upstream.
- How well the setup behaves with different battery capacities and Home Assistant entity names.
For anyone trying something similar:
- Install Predbat using the official instructions.
- Verify all Huawei Solar entities in Home Assistant.
- Start with Predbat in Monitor or Read Only mode.
- Enable
load_ml_enable: true, but initially keepload_ml_source: falseso the ML model can collect history and be evaluated without affecting battery planning. - Allow at least one day of history for initial ML training; seven or more days are recommended.
- Test the Huawei service calls manually:
forcible_charge_socforcible_discharge_socstop_forcible_charge
- Confirm the battery power sign.
- Start with low charge and discharge power limits.
- Enable active control only after the plan and service calls behave correctly.
- Enable
load_ml_source: trueonly after the ML forecast appears stable and reasonable. - Leave freeze modes disabled until basic control is stable.
- Predbat GitHub Repository
- Predbat Documentation
- Home Assistant
- Nordpool Integration
- Forecast.Solar
- Huawei Solar Home Assistant Integration
- go-eCharger
Thanks to:
- springfall2008 for creating Predbat,
- the Predbat community,
- the Home Assistant community,
- and everyone sharing examples, fixes and energy automation ideas.
This repository exists to document my own setup and hopefully help other Huawei Solar users get started with Predbat.