Bugs in optimization with Battery enabled #369
Comments
|
Defaults should be zero, and then I find tuning to around 0.05 or 0.10 give useful results. |
Understood, I can setup as a workaround. However my battery does go to 100% and 0% and EMHASS reports infeasible if SOC is above or below its desired limits. |
|
OK, making progress and now running successfully on 0.11.2.. weight_battery_discharge: 0 was what was required for functionality. battery_dynamics is functioning correctly. I'll monitor closely, through tonight's Price Spike.
The new 'live logs' in HA 2024.11 is great for live monitoring of EMHASS cycles, not if they could just get that into a Lovelace card.
{
"battery_charge_efficiency": 0.95,
"battery_charge_power_max": 11000,
"battery_discharge_efficiency": 0.95,
"battery_discharge_power_max": 15000,
"battery_dynamic_max": 0.9,
"battery_dynamic_min": -0.9,
"battery_maximum_state_of_charge": 1,
"battery_minimum_state_of_charge": 0,
"battery_nominal_energy_capacity": 40500,
"battery_target_state_of_charge": 0.1,
"compute_curtailment": true,
"continual_publish": false,
"costfun": "profit",
"delta_forecast_daily": 2,
"end_timesteps_of_each_deferrable_load": [
0,
0,
0,
0,
0,
0
],
"historic_days_to_retrieve": 2,
"inverter_is_hybrid": false,
"load_cost_forecast_method": "hp_hc_periods",
"load_forecast_method": "naive",
"load_negative": false,
"load_offpeak_hours_cost": 0.09,
"load_peak_hour_periods": {
"period_hp_1": [
{
"start": "02:54"
},
{
"end": "15:24"
}
],
"period_hp_2": [
{
"start": "17:24"
},
{
"end": "20:24"
}
]
},
"load_peak_hours_cost": 0.31,
"logging_level": "INFO",
"lp_solver": "COIN_CMD",
"lp_solver_path": "/usr/bin/cbc",
"maximum_power_from_grid": 50000,
"maximum_power_to_grid": 30000,
"method_ts_round": "first",
"modules_per_string": [
29,
21
],
"nominal_power_of_deferrable_loads": [
1340,
5000,
11500,
4000,
600,
11500
],
"number_of_deferrable_loads": 6,
"operating_hours_of_each_deferrable_load": [
4,
2,
0,
0,
3,
0
],
"optimization_time_step": 30,
"photovoltaic_production_sell_price": 0.05,
"production_price_forecast_method": "constant",
"pv_inverter_model": [
"SolarEdge_Technologies_Ltd___SE7600A_US__208V_",
"SolarEdge_Technologies_Ltd___SE7600A_US__208V_"
],
"pv_module_model": [
"Advance_Power_API_M370",
"Advance_Power_API_M370"
],
"sensor_linear_interp": [
"sensor.apf_generation_entity",
"sensor.power_load_no_var_loads"
],
"sensor_power_load_no_var_loads": "sensor.power_load_no_var_loads",
"sensor_power_photovoltaics": "sensor.apf_generation_entity",
"sensor_replace_zero": [
"sensor.apf_generation_entity",
"sensor.power_load_no_var_loads"
],
"set_battery_dynamic": true,
"set_deferrable_load_single_constant": [
false,
false,
false,
false,
false,
false
],
"set_deferrable_startup_penalty": [
5,
1,
0,
1,
10,
0
],
"set_nocharge_from_grid": false,
"set_nodischarge_to_grid": false,
"set_total_pv_sell": false,
"set_use_battery": true,
"set_zero_min": true,
"start_timesteps_of_each_deferrable_load": [
0,
0,
0,
0,
0,
0
],
"strings_per_inverter": [
1,
1
],
"surface_azimuth": [
90,
270
],
"surface_tilt": [
18,
10
],
"treat_deferrable_load_as_semi_cont": [
true,
true,
false,
false,
true,
false
],
"weather_forecast_method": "scrapper",
"weight_battery_charge": 0,
"weight_battery_discharge": 0.05
} |
|
Seeing similar issues related to battery weights. I also notice the soc_init value doesn't seem to be handled correctly. Testing weight_battery_discharge: 0 and weight_battery_charge: 1 gives very interesting result, not as expected. I'll be happy to help you guys test more if needed.
|
|
@davidusb-geek . Whats your thoughts on these issues? Happy to make a PR with modified defaults on request. |
|
As added input, not being sure if related, changing costfun to self-consumption seemed to resolve all issues. However p_batt went "unstable" (alternating charging and discharging) tonight when load/price_cost_forecast went negative. So I tried added a value in both lists entries so it never goes negative, and the strange p_batt behaviour disappeared and went back to normal. |
purcell-lab
added a commit
to purcell-lab/emhass
that referenced
this issue
Nov 19, 2024
Battery weights dis/charge should be 0.0 Fixes: davidusb-geek#369
|
Hello everyone, My problem might be related to this bug. As soon as I activate the battery in the configuration, I see the status "infeasible" for day-ahead and MPC. I have been trying to change this with various parameters for weeks, but without success. Overall, the results look promising despite the "infeasible" status. Here is my current configuration. any ideas? |
|
meanwhile I figured out that the optimizer always fail if “set_nodischarge_to_grid” is true. Now I switched it off and the optimizer works as expected :) |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Thanks to @kcoffau and @purcell-lab, there seems to be possibly a few bugs in the battery optimization that either freezes the optimization or generates incorrect output. Version:
0.11.xParameter issues
According to @kcoffau:
There may also be an issue setting SOC_final to 1
Recreate
Config.json:
{ "logging_level": "INFO", "costfun": "profit", "optimization_time_step": 30, "historic_days_to_retrieve": 2, "method_ts_round": "nearest", "continual_publish": false, "data_path": "default", "set_total_pv_sell": false, "lp_solver": "default", "lp_solver_path": "empty", "set_nocharge_from_grid": false, "set_nodischarge_to_grid": false, - "set_battery_dynamic": true, + "set_battery_dynamic": false, "battery_dynamic_max": 0.9, "battery_dynamic_min": -0.9, - "weight_battery_discharge": 0.05, + "weight_battery_discharge": 1.0, - "weight_battery_charge": 1," + "weight_battery_charge": 1.0, "sensor_power_photovoltaics": "sensor.power_photovoltaics", "sensor_power_load_no_var_loads": "sensor.power_load_no_var_loads", "sensor_replace_zero": [ "sensor.power_photovoltaics" ], "sensor_linear_interp": [ "sensor.power_photovoltaics", "sensor.power_load_no_var_loads" ], "load_negative": false, "set_zero_min": true, "number_of_deferrable_loads": 2, "nominal_power_of_deferrable_loads": [ 3000.0, 750.0 ], "operating_hours_of_each_deferrable_load": [ 4, 0 ], "weather_forecast_method": "scrapper", "load_forecast_method": "naive", "delta_forecast_daily": 1, "load_cost_forecast_method": "hp_hc_periods", "start_timesteps_of_each_deferrable_load": [ 0, 0 ], "end_timesteps_of_each_deferrable_load": [ 0, 0 ], "load_peak_hour_periods": { "period_hp_1": [ { "start": "02:54" }, { "end": "15:24" } ], "period_hp_2": [ { "start": "17:24" }, { "end": "20:24" } ] }, "treat_deferrable_load_as_semi_cont": [ true, true ], "set_deferrable_load_single_constant": [ false, false ], "set_deferrable_startup_penalty": [ 0.0, 0.0 ], "load_peak_hours_cost": 0.1907, "load_offpeak_hours_cost": 0.1419, "production_price_forecast_method": "constant", "photovoltaic_production_sell_price": 0.1419, "maximum_power_from_grid": 9000, "maximum_power_to_grid": 9000, "pv_module_model": [ "CSUN_Eurasia_Energy_Systems_Industry_and_Trade_CSUN295_60M" ], "pv_inverter_model": [ "Fronius_International_GmbH__Fronius_Primo_5_0_1_208_240__240V_" ], "surface_tilt": [ 30 ], "surface_azimuth": [ 205 ], "modules_per_string": [ 16 ], "strings_per_inverter": [ 1 ], "inverter_is_hybrid": false, "compute_curtailment": false, "set_use_battery": true, - "battery_discharge_power_max": 15000, + "battery_discharge_power_max": 8000, - "battery_charge_power_max": 11000, + "battery_charge_power_max": 8000, - "battery_discharge_efficiency": 0.95, + "battery_discharge_efficiency": 0.99, - "battery_charge_efficiency": 0.95, + "battery_charge_efficiency": 0.99, - "battery_nominal_energy_capacity": 40500, + "battery_nominal_energy_capacity": 75000, - "battery_minimum_state_of_charge": 0, + "battery_minimum_state_of_charge": 0.1 - "battery_maximum_state_of_charge": 1, + "battery_maximum_state_of_charge": 0.9, - "battery_target_state_of_charge": 0.98 + "battery_target_state_of_charge": 0.1 }Red does not work, Green does.
A few notes
From my testing with day-adhead and MPC without any runtime parameters
set_battery_dynamic
From my testing from above
set_battery_dynamic: truedoes not seem cause any errors.weight_battery_discharge
Setting
weight_battery_dischargefrom1.0to0.05seems to drag out the optimization when running day-ahead. (However it does finish)Setting
weight_battery_discharge: 0.05andbattery_discharge_power_max: 15000,battery_charge_power_max: 11000&battery_nominal_energy_capacity: 40500dragged the optimization out indefinitely? :And you can start seeing errors such as:
Setting
battery_nominal_energy_capacity: 75000andbattery_discharge_power_max: 8000seems to resolve the indefinite optimization. (Although the optimization still took some time)Originally discussed on: #334
The text was updated successfully, but these errors were encountered: