springfall2008
Huawei Inverter Grid Charge Rate
In the apps.yaml I have specified the charge/discharge rate as 3 kwh. However this is to force the plan to ensure it calculates this charging rate in the plan. My battery supports DC charging at 5 kwh and discharging at 5 kwh. Note the 3 kwh AC charging is apparently the limit allowed for Huawei batteries and cannot be exceeded. I've confirmed this in other Huawei forums, so in summary AC charging is limited to 3kwh.
The 3 kwh setting from the predbat yaml overrides and reduces the DC charging and discharging from 5kwh to 3kwh when the sun is shining or power drawn from the battery, something I want to avoid.
I would like the config to be amended so that grid charging is set at 3 kwh and the DC charging/charging is left at 5 kwh.
Note the 3 kwh AC charging is apparently the limit allowed in the UK and is set up by my installer
Not quite sure I follow what the issue with Predbat is, but on the point above about 3kWh AC charging limit, there isn't any such UK charging limit to my knowledge. I have two 2.6kWh inverters and can charge both batteries at 5.2kWh import, and if the oven, washing machine, etc is on, I've seen 12kWh being imported before now.
It may be that your DNO fuse is quite small and that's what the installer is referring to? My fuse is 100A, and if yours is substantially smaller then you can get the DNO to replace it.
But 3kWh sounds way too low. If you put the oven on and the kettle at the same time you will draw more than 3kWh from the grid so I really don't know what your installer is referring to.
There are grid export limits and if you didn't get a G99 approval then you will be limited to 3.6kWh of export, but that's not related to import.
Thanks for coming back to me.
I have a 100A fuse so it's not an issue with my electrics. The 3kwh limit is applied by Huawei. It's a 10kwh battery and has a 3kwh charge limit, it normally takes 3 hrs 45 mins to charge. I can change the battery from sunlight at 5 kWh and discharge to loads at 5 kWh. However in the yaml I need to set the 3 kWh rate to allow the plan to have sufficient time to charge the battery (3 hrs 45 mins). The issue is that the 3kwh rate setting overrides the DC charging and load discharging DOWN to 3 kwh as well.
On Thu, 5 Sept 2024, 16:54 Geoffrey Coan, @.***> wrote:
Note the 3 kwh AC charging is apparently the limit allowed in the UK and is set up by my installer
Not quite sure I follow what the issue with Predbat is, but on the point above about 3kWh AC charging limit, there isn't any such UK charging limit to my knowledge. I have two 2.6kWh inverters and can charge both batteries at 5.2kWh import, and if the oven, washing machine, etc is on, I've seen 12kWh being imported before now.
It may be that your DNO fuse is quite small and that's what the installer is referring to? My fuse is 100A, and if yours is substantially smaller then you can get the DNO to replace it.
But 3kWh sounds way too low. If you put the oven on and the kettle at the same time you will draw more than 3kWh from the grid so I really don't know what your installer is referring to.
There are grid export limits and if you didn't get a G99 approval then you will be limited to 3.6kWh of export, but that's not related to import.
— Reply to this email directly, view it on GitHub https://github.com/springfall2008/batpred/issues/1431#issuecomment-2332097912, or unsubscribe https://github.com/notifications/unsubscribe-auth/BJ43WOLIUQO67TFWZ7EZEZLZVB5CBAVCNFSM6AAAAABNWXEX6KVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMZSGA4TOOJRGI . You are receiving this because you authored the thread.Message ID: @.***>
Can you share your apps.yaml config to see if there's anything in the way you've set these limits?
------------------------------------------------------------------
Huawei Solar Config example - https://github.com/wlcrs/huawei_solar
------------------------------------------------------------------
pred_bat: module: predbat class: PredBat
Sets the prefix for all created entities in HA - only change if you want to run more than once instance
prefix: predbat
Timezone to work in
timezone: Europe/London
If you are using Predbat outside of HA then set the HA URL and Key (long lived access token here)
#ha_url: 'http://homeassistant.local:8123' #ha_key: 'xxx'
Currency, symbol for main currency second symbol for 1/100s e.g. $ c or £ p or e c
currency_symbols:
- '£'
- 'p'
Number of threads to use in plan calculation
Can be auto for automatic, 0 for off or values 1-N for a fixed number
threads: 4
Sensors, more than one can be specified and they will be summed up automatically
For two inverters the load today would normally be the master load sensor only (to cover the entire house)
If you have three phase and one inverter per phase then you would need three load sensors
For pv_today if you have multiple solar inverter inputs then you should include one entry for each inverter
load_today: - sensor.consumption_today import_today: - sensor.import_today export_today: - sensor.export_today pv_today: - sensor.solar_energy_riemann
Load forecast can be used to add to the historical load data (heat-pump)
To link to Predheat
Data must be in the format of 'last_updated' timestamp and 'energy' for incrementing kWh
#load_forecast:
- predheat.heat_energy$external
num_inverters: 1 inverter_type: "HU"
Run balance inverters every N seconds (0=disabled) - only for multi-inverter
balance_inverters_seconds: 0
If not using REST then instead set the Control here (one for each inverter)
- you can delete this section if using REST
charge_rate: - number.batteries_maximum_charging_power discharge_rate: - number.batteries_maximum_discharging_power battery_power: - sensor.batteries_charge_discharge_power pv_power: - sensor.inverter_input_power load_power: - sensor.power_meter_active_power soc_percent: - sensor.batteries_state_of_capacity #soc_kw:
- sensor.batteri_to_kw
soc_max: - 10 charge_limit: - number.batteries_end_of_charge_soc reserve: - 5 scheduled_charge_enable: - off scheduled_discharge_enable: - off charge_start_time: - "00:00:00" charge_end_time: - "06:00:00" discharge_start_time: - "07:00:00" discharge_end_time: - "23:00:00" battery_min_soc: - 5
Services to charge/discharge
charge_start_service: huawei_solar.forcible_charge_soc charge_stop_service: huawei_solar.stop_forcible_charge discharge_start_service: huawei_solar.forcible_discharge_soc discharge_stop_service: huawei_solar.stop_forcible_charge
Device_ID for the Huawei inverter device in home-assistant
device_id: 2669d9aa48778272230354f5fdde33a3
Inverter max AC limit (one per inverter). E.g for a 3.6kw inverter set to 3600
If you have a second inverter for PV only please add the two values together
inverter_limit:
- 6000.0
Set the maximum charge/discharge rate of the battery
battery_rate_max:
- 3000
Export limit is a software limit set on your inverter that prevents exporting above a given level
When enabled Predbat will model this limit
#export_limit:
- 3600
- 3600
Some inverters don't turn off when the rate is set to 0, still charge or discharge at around 200w
The value can be set here in watts to model this (doesn't change operation)
#inverter_battery_rate_min:
- 200
Workaround to limit the maximum reserve setting, some inverters won't allow 100% to be set
inverter_reserve_max : 99
Some batteries tail off their charge rate at high soc%
enter the charging curve here as a % of the max charge rate for each soc percentage.
the default is 1.0 (full power)
The example below is from GE 9.5kwh battery with latest firmware and gen1 inverter
#battery_charge_power_curve:
91 : 0.91
92 : 0.81
93 : 0.71
94 : 0.62
95 : 0.52
96 : 0.43
97 : 0.33
98 : 0.24
99 : 0.24
100 : 0.24
Inverter clock skew in minutes, e.g. 1 means it's 1 minute fast and -1 is 1 minute slow
Separate start and end options are applied to the start and end time windows, mostly as you want to start late (not early) and finish early (not late)
Separate discharge skew for discharge windows only
inverter_clock_skew_start: 0
inverter_clock_skew_end: 0
inverter_clock_skew_discharge_start: 0
inverter_clock_skew_discharge_end: 0
Clock skew adjusts the Appdaemon time
This is the time that Predbat takes actions like starting discharge/charging
Only use this for workarounds if your inverter time is correct but Predbat is somehow wrong (AppDaemon issue)
1 means add 1 minute to AppDaemon time, -1 takes it away
clock_skew: 0
Solcast cloud interface, set this or the local interface below
solcast_host: 'https://api.solcast.com.au/' solcast_api_key: nTTY1uasx2lqSqkhqP5qGXqmDPtf4S8V solcast_poll_hours: 3
Set these to match solcast sensor names if not using the cloud interface
The regular expression (re:) makes the solcast bit optional
If these don't match find your own names in Home Assistant
pv_forecast_today: re:(sensor.(solcast_|)(pv_forecast_|)forecast_today) pv_forecast_tomorrow: re:(sensor.(solcast_|)(pv_forecast_|)forecast_tomorrow) pv_forecast_d3: re:(sensor.(solcast_|)(pv_forecast_|)forecast_(day_3|d3)) pv_forecast_d4: re:(sensor.(solcast_|)(pv_forecast_|)forecast_(day_4|d4))
car_charging_energy defines an incrementing sensor which measures the charge added to your car
is used for car_charging_hold feature to filter out car charging from the previous load data
Automatically set to detect Wallbox and Zappi, if it doesn't match manually enter your sensor name
Also adjust car_charging_energy_scale if it's not in kwH to fix the units
#car_charging_energy: 're:(sensor.myenergi_zappi_[0-9a-z]+_charge_added_session|sensor.wallbox_portal_added_energy)'
Defines the number of cars modelled by the system, set to 0 for no car
num_cars: 0
car_charging_planned is set to a sensor which when positive indicates the car will charged in the upcoming low rate slots
This should not be needed if you use Intelligent Octopus slots which will take priority if enabled
The list of possible values is in car_charging_planned_response
Auto matches Zappi and Wallbox, or change it for your own
One entry per car
#car_charging_planned:
- 're:(sensor.wallbox_portal_status_description|sensor.myenergi_zappi_[0-9a-z]+_plug_status)'
car_charging_planned_response:
- 'yes'
- 'on'
- 'true'
- 'connected'
- 'ev connected'
- 'charging'
- 'paused'
- 'waiting for car demand'
- 'waiting for ev'
- 'scheduled'
- 'enabled'
- 'latched'
- 'locked'
- 'plugged in'
In some cases car planning is difficult (e.g. Ohme with Intelligent doesn't report slots)
The car charging now can be set to a sensor to indicate the car is charging and to plan
for it to charge during this 30 minute slot
#car_charging_now:
- off
Positive responses for car_charging_now
#car_charging_now_response:
- 'yes'
- 'on'
- 'true'
To make planned car charging more accurate, either using car_charging_planned or the Octopus Energy plugin,
specify your battery size in kwh, charge limit % and current car battery soc % sensors/values.
If you have Intelligent Octopus the battery size and limit will be extracted from the Octopus Energy plugin directly.
Set the car SOC% if you have it to give an accurate forecast of the cars battery levels.
One entry per car if you have multiple cars.
#car_charging_battery_size:
- 75
#car_charging_limit:
- 're:number.tsunami_charge_limit'
#car_charging_soc:
- 're:sensor.tsunami_battery'
If you have Octopus intelligent, enable the intelligent slot information to add to pricing
Will automatically disable if not found, or comment out to disable fully
When enabled it overrides the 'car_charging_planned' feature and predict the car charging based on the intelligent plan (unless octopus intelligent charging is False)
This matches either the intelligent slot from the Octopus Plugin or from the Intelligent plugin
#octopus_intelligent_slot: 're:(binary_sensor.octopus_intelligent_slot|re:binary_sensor.octopus_energy_intelligent_dispatching)' #octopus_intelligent_slot: 're:binary_sensor.octopus_energy_intelligent_dispatching' #octopus_ready_time: 're:time.octopus_energy_intelligent_ready_time' #octopus_charge_limit: 're:number.octopus_energy_intelligent_charge_limit'
Energy rates
Please set one of these three, if multiple are set then Octopus is used first, second rates_import/rates_export and latest basic metric
Set import and export entity to point to the Octopus Energy plugin
automatically matches your meter number assuming you have only one
Will be ignored if you don't have the sensor
Or manually set it to the correct sensor names e.g:
sensor.octopus_energy_electricity_xxxxxxxxxx_xxxxxxxxxxxxx_current_rate
sensor.octopus_energy_electricity_xxxxxxxxxx_xxxxxxxxxxxxx_export_current_rate
metric_octopus_import: 're:(sensor.(octopus_energy_|)electricity_[0-9a-z]+[0-9a-z]+current_rate)' metric_octopus_export: 're:(sensor.(octopus_energy|)electricity[0-9a-z]+_[0-9a-z]+_export_current_rate)'
Standing charge can be set to a sensor (e.g. Octopus) or manually entered in pounds here (e.g. 0.50 is 50p)
metric_standing_charge: 're:(sensor.(octopus_energy_|)electricity_[0-9a-z]+_[0-9a-z]+_current_standing_charge)'
Or set your actual rates across time for import and export
If start/end is missing it's assumed to be a fixed rate
Gaps are filled with zero rate
#rates_import:
- start: "00:30:00"
end: "04:30:00"
rate: 7.5
- start: "04:30:00"
end: "00:30:00"
rate: 40.0
rates_export:
- rate: 0
Import rates can be overridden with rate_import_override
Export rates can be overridden with rate_export_override
Use the same format as above, but a date can be included if it just applies for a set day (e.g. Octopus power ups)
This will override even the Octopus plugin rates if enabled
#rates_import_override:
- date: '2023-09-10'
start: '14:00:00'
end: '14:30:00'
rate: 5
For pv estimate, leave blank for central estimate, or add 10 for 10% curve (worst case) or 90 or 90% curve (best case)
If you use 10 then disable pv_metric10_weight below
pv_estimate: 10
Days previous is the number of days back to find historical load data
Recommended is 7 to capture day of the week but 1 can also be used
if you have more history you could use 7 and 14 (in a list) but the standard data in HA only lasts 10 days
days_previous: - 7
Days previous weight can be used to control the weighting of the previous load points, the values are multiplied by their
weights and then divided through by the total weight. E.g. if you used 1 and 0.5 then the first value would have 2/3rd of the weight and the second 1/3rd
Include one value for each days_previous value, each weighting on a separate line.
If any days_previous's that are not given a weighting they will assume a default weighting of 1.
days_previous_weight: - 1
Number of hours forward to forecast, best left as-is unless you have specific reason
forecast_hours: 48
Specify the devices that notifies are sent to, the default is 'notify' which goes to all
#notify_devices:
- mobile_app_iphone13pro
Battery scaling makes the battery smaller (e.g. 0.9) or bigger than its reported
If you have an 80% DoD battery that falsely reports it's kwh then set it to 0.8 to report the real figures
battery_scaling: 1.0
Can be used to scale import and export data, used for workarounds
import_export_scaling: 1.0
Export triggers:
For each trigger give a name, the minutes of export needed and the energy required in that time
Multiple triggers can be set at once so in total you could use too much energy if all run
Creates an entity called 'binary_sensor.predbat_export_trigger_' which will be turned On when the condition is valid
connect this to your automation to start whatever you want to trigger
export_triggers: - name: 'large' minutes: 60 energy: 1.0 - name: 'small' minutes: 15 energy: 0.25
If you have a sensor that gives the energy consumed by your solar diverter then add it here
this will make the predictions more accurate. It should be an incrementing sensor, it can reset at midnight or not
It's assumed to be in Kwh but scaling can be applied if need be
#iboost_energy_today: 'sensor.tasmota_energy_today' #iboost_energy_scaling: 1.0 `
Its very hard to follow the file pasted in like that as github has assumed some of the line with # are headings rather than comments.
Can you either edit the comment above and put ``` on a line before and after the apps.yaml which means it will be treated as text and be much more readable, or upload the file as an attachment to github (probably need to rename it to a .txt or .log extension first)
if it helps here is a screenshot from the Huawei software. The battery has setting for charge and discharge through to 5,000 kwh, however from AC the charge is limited to 3,000. Ideally the apps.yaml could have two entries, one for AC charge and one for DC. That way the plan would know that the AC charge will run at 3,000 kwh and the DC could charge at 5,000 and also discharge to loads at 5,000 maximum.
Any update on this ?
I have maximum power from grid of 5kw and I want to set huawei max charge of 1kw to let 4kw left to other things ....
Could someone please look into this? This would be a huge help to all Belgian users. 😉
We aim to keep our grid import as low as possible, since a higher peak in kW leads to a significantly higher annual grid fee.
Exporting is not an issue—our focus is on strictly limiting import.
That’s why I’ve set the grid import limit via the inverter to 3 kW in my configuration. Import from solar an Export to grid is allowed up to 10 kW.
In Predbat, however, we use an inverter and battery limit of 10 kW, because lowering these to 3 kW would prevent us from efficiently charging the battery during high solar production (12 kWp). With a 3 kW limit, only a small portion would go to the battery, and the rest would be exported to the grid.
The issue is that Predbat’s calculations assume a grid import capacity of 10 kW, while in reality it’s only 3 kW. This leads to inaccurate charging plans.
A solution would be to introduce a separate parameter to limit the maximum grid charging power—for example, something like max_grid_import_power, independent of the general inverter or battery limits.
Could someone please look into this? This would be a huge help to all Belgian users. 😉
We aim to keep our grid import as low as possible, since a higher peak in kW leads to a significantly higher annual grid fee.
Exporting is not an issue—our focus is on strictly limiting import.
That’s why I’ve set the grid import limit via the inverter to 3 kW in my configuration. Import from solar an Export to grid is allowed up to 10 kW.
In Predbat, however, we use an inverter and battery limit of 10 kW, because lowering these to 3 kW would prevent us from efficiently charging the battery during high solar production (12 kWp). With a 3 kW limit, only a small portion would go to the battery, and the rest would be exported to the grid.
The issue is that Predbat’s calculations assume a grid import capacity of 10 kW, while in reality it’s only 3 kW. This leads to inaccurate charging plans.
A solution would be to introduce a separate parameter to limit the maximum grid charging power—for example, something like max_grid_import_power, independent of the general inverter or battery limits.
I have the exact same problem (belgium/Huawei). Do you have an workaround?
At the moment there isn't a facility in predbat to specify different grid AC and inverter DC limits so predbat could plan and model what you are asking for.
Would be useful though @springfall2008 ?
@ward0
For now i start the charging via a script that charges the battery at 5kW (without the script it is 10kW). Predbat continuously adjusts the plan for this difference, but it is not ideal.
#charge_start_service: huawei_solar/forcible_charge_soc charge_start_service: script.batterij_laden_vanaf_grid charge_stop_service: huawei_solar/stop_forcible_charge discharge_start_service: huawei_solar/forcible_discharge_soc discharge_stop_service: huawei_solar/stop_forcible_charge
Script:
batterij_laden_vanaf_grid: alias: Batterij laden vanaf grid sequence:
- data: target_soc: 100 power: '5000' device_id: 06e8a263ce238d92c851efec9ed6e4d9 action: huawei_solar.forcible_charge_soc
Predbat continuously adjusts the plan for this difference, but it is not ideal.
A workaround (bodge) for Predbat continually updating the plan as you are using a lower charge rate ...
If you principally charge your batteries overnight on grid charge then you could write an automation that sets the inverter charge limit in predbat at sunset and then rewrites it to the correct upper value when either the battery is full or sunrise
For now i start the charging via a script that charges the battery at 5kW (without the script it is 10kW). Predbat continuously adjusts the plan for this difference, but it is not ideal.
#charge_start_service: huawei_solar/forcible_charge_soc charge_start_service: script.batterij_laden_vanaf_grid charge_stop_service: huawei_solar/stop_forcible_charge discharge_start_service: huawei_solar/forcible_discharge_soc discharge_stop_service: huawei_solar/stop_forcible_charge
Script:
batterij_laden_vanaf_grid: alias: Batterij laden vanaf grid sequence:
- data: target_soc: 100 power: '5000' device_id: 06e8a263ce238d92c851efec9ed6e4d9 action: huawei_solar.forcible_charge_soc
@xxxxminingxxxx Thank you for your time and help. I created the script, afterwards i changed the apps.yaml:
| 41288 | 2025-11-16 21:26:06.612790: Warn: Validation of apps.yaml found configuration item 'discharge_stop_service' element huawei_solar/stop_forcible_charge is not an dict |
|---|---|
| 41287 | 2025-11-16 21:26:06.612739: Warn: Validation of apps.yaml found configuration item 'discharge_start_service' element huawei_solar/forcible_discharge_soc is not an dict |
| 41286 | 2025-11-16 21:26:06.612686: Warn: Validation of apps.yaml found configuration item 'charge_stop_service' element huawei_solar/stop_forcible_charge is not an dict |
| 41285 | 2025-11-16 21:26:06.612604: Warn: Validation of apps.yaml found configuration item 'charge_start_service' element script.batterij_laden_vanaf_grid is not an dict |
@ward0 these validation errors on the charge/discharge start/stop service can be ignored
They've already been logged on #2670 and I've been trying, without success so far, to find a format that predbat likes. Its only a UI validation warning.
Setting a script shouldn't cause a warning either 😠
@ward0 these validation errors on the charge/discharge start/stop service can be ignored
They've already been logged on #2670 and I've been trying, without success so far, to find a format that predbat likes. Its only a UI validation warning.
Setting a script shouldn't cause a warning either 😠
@xxxxminingxxxx Thank you!! You fixed my problem after more than 5 hours of searching the internet...
@gcoan Thank you! Can you edit the wiki? This should be added for other Huawei users out there. Atleast I didn't find it was already there. And also the AC/DC problem, because of that we are using a script to make it work. Update huawei template for example?
But again, thanks for the help and hard work.
@xxxxminingxxxx
44299 | 2025-11-16 22:30:21.297922: Warn: Service call huawei_solar/stop_forcible_charge data {'device_id': ''} failed with response None
Do you also get this error when the planned Predbat charge needs to stop?
Do i also need a script for this?
Update:
I forgot to uncomment my device_id: xxx value.
@ward0 @xxxxminingxxxx I have updated the template Huawei apps.yaml and inverter setup instructions for this charge rate workaround
Please check you are happy with the changes: https://github.com/gcoan/batpred/commit/c13c2fd1309840c65baf2f939585fe03ee3fec4d