Each entity value you change will dictate a different outcome, you need to look at the calculation and figure the correct one for you.
The state of charge has 2 values you can alter. 1 being state actual at end. And 1 being end of optimisation.
If you turn it to 0 then its calulating a cost benifit overlay, might include the cost of replacing the battery. ( i would assume)
Agree, thatâs why the ask.
See SOC with default value of 0.6
Now with value 0
In this case the battery isnât charging anymore at 21.00 hours. So you could say in this example, changing the value to 0 might be better?
Set the high value for maximum to 1 and test.
Im not sure why its set to 0.8 but you get a better value again
I mean the value: âThe desired battery state of charge at the end of each optimization cycleâ
Hello, me again.
Any idea why even if I define SOC init (91%) and final (50%) through the command, it takes the value(s) from config yaml (30%)? (dayahead optim with 30 min steps)
curl -i -H "Content-Type: application/json" -X POST -d '{"delta_forecast": 1, "soc_init": 0.91, "soc_final": 0.5, "load_cost_forecast":[ 0.125598, 0.125598, 0.125598, 0.125598, 0.125598, 0.125598, 0.125598, 0.125598, 0.125598, 0.125598, 0.125598, 0.125598, 0.125598, 0.125598, 0.150977, 0.150977, 0.136777, 0.136777, 0.136777, 0.136777, 0.136777, 0.136777, 0.136777, 0.136777, 0.136777, 0.136777, 0.136777, 0.136777, 0.136777, 0.136777, 0.136777, 0.136777, 0.136777, 0.136777, 0.136777, 0.136777, 0.136777, 0.136777, 0.150977, 0.150977, 0.150977, 0.150977, 0.150977, 0.150977, 0.150977, 0.150977, 0.125598, 0.125598], "prod_price_forecast":[ 0.091991, 0.091991, 0.091991, 0.091991, 0.091991, 0.091991, 0.091991, 0.091991, 0.091991, 0.091991, 0.091991, 0.091991, 0.091991, 0.091991, 0.106021, 0.106021, 0.110135, 0.110135, 0.110135, 0.110135, 0.110135, 0.110135, 0.110135, 0.110135, 0.110135, 0.110135, 0.110135, 0.110135, 0.110135, 0.110135, 0.110135, 0.110135, 0.110135, 0.110135, 0.110135, 0.110135, 0.110135, 0.110135, 0.106021, 0.106021, 0.106021, 0.106021, 0.106021, 0.106021, 0.106021, 0.106021, 0.091991, 0.091991]}' http://localhost:5000/action/dayahead-optim
2023-09-15 00:37:50,365 - web_server - INFO - EMHASS server online, serving index.html...
2023-09-15 00:38:58,817 - web_server - INFO - Setting up needed data
2023-09-15 00:38:58,892 - web_server - INFO - Retrieving weather forecast data using method = scrapper
2023-09-15 00:39:16,571 - web_server - INFO - Retrieving data from hass for load forecast using method = naive
2023-09-15 00:39:16,628 - web_server - INFO - Retrieve hass get data method initiated...
2023-09-15 00:42:17,760 - web_server - INFO - >> Performing dayahead optimization...
2023-09-15 00:42:17,779 - web_server - INFO - Performing day-ahead forecast optimization
2023-09-15 00:42:18,022 - web_server - INFO - Perform optimization for the day-ahead
2023-09-15 00:42:22,514 - web_server - INFO - Status: Optimal
2023-09-15 00:42:22,519 - web_server - INFO - Total value of the Cost function = 1.6
2023-09-15 00:42:41,788 - web_server - INFO - EMHASS server online, serving index.html...
hass_url: empty
long_lived_token: empty
costfun: self-consumption
logging_level: DEBUG
optimization_time_step: 30
historic_days_to_retrieve: 2
method_ts_round: nearest
set_total_pv_sell: false
lp_solver: COIN_CMD
lp_solver_path: /usr/bin/cbc
set_nocharge_from_grid: false
set_nodischarge_to_grid: false
set_battery_dynamic: false
battery_dynamic_max: 0.9
battery_dynamic_min: -0.9
load_forecast_method: naive
sensor_power_photovoltaics: sensor.production_pv_w
sensor_power_load_no_var_loads: sensor.consumption_w
number_of_deferrable_loads: 1
list_nominal_power_of_deferrable_loads:
- nominal_power_of_deferrable_loads: 0
list_operating_hours_of_each_deferrable_load:
- operating_hours_of_each_deferrable_load: 0
list_peak_hours_periods_start_hours:
- peak_hours_periods_start_hours: "07:00"
list_peak_hours_periods_end_hours:
- peak_hours_periods_end_hours: "23:00"
list_treat_deferrable_load_as_semi_cont:
- treat_deferrable_load_as_semi_cont: true
load_peak_hours_cost: 0.1907
load_offpeak_hours_cost: 0.1419
photovoltaic_production_sell_price: 0.065
maximum_power_from_grid: 6000
list_pv_module_model:
- pv_module_model: SunPower_SPR_E20_327
- pv_module_model: SunPower_SPR_P19_395_COM
list_pv_inverter_model:
- pv_inverter_model: SMA_America__SB3000TL_US_22__240V_
- pv_inverter_model: SMA_America__STP50_US_40__480V_
list_surface_tilt:
- surface_tilt: 17
- surface_tilt: 17
list_surface_azimuth:
- surface_azimuth: 225
- surface_azimuth: 225
list_modules_per_string:
- modules_per_string: 9
- modules_per_string: 14
list_strings_per_inverter:
- strings_per_inverter: 1
- strings_per_inverter: 1
set_use_battery: true
battery_discharge_power_max: 7100
battery_charge_power_max: 7100
battery_discharge_efficiency: 0.95
battery_charge_efficiency: 0.95
battery_nominal_energy_capacity: 27000
battery_minimum_state_of_charge: 0.1
battery_maximum_state_of_charge: 1
battery_target_state_of_charge: 0.3
I found following the basic control method of no shell command for soc, the system works proper.
Send the basic info through the shell command and then use the emhass config to change the rest.
The problem is that I have at least to send the initial SOC through the shell, as the config doesnât allow me to do that and this is key for a proper energy and battery optimization. The terminal/log doesnât return an error so the parameters are accepted. I donât understand why not used. It seems they are ignored and it goes back to default SOC_init=SOC_final=SOC_config_yaml. I donât think this is a limitation of the addon, as all the rest Iâve tried so far works as per documentation.
Did you ever have issues with these cards not working?
I used mine like this, i send the command to mine using the battery value/ 100
The entity ehmass uses is 0.1 as 100%
i have 4 batteries so i added them together and devided by 400 to receive the decimal value
shell_command:
dayahead_optim: "curl -i -H \"Content-Type: application/json\" -X POST -d '{}' http://localhost:5000/action/dayahead-optim"
publish_data: "curl -i -H \"Content-Type: application/json\" -X POST -d '{}' http://localhost:5000/action/publish-data "
rest_command:
naive_mpc_optim:
url: http://localhost:5000/action/naive-mpc-optim
method: POST
content_type: 'application/json'
payload: >-
{
"prod_price_forecast": {{
([states('sensor.home_feed_in_price')|float(0)] +
(state_attr('sensor.home_feed_in_forecast', 'forecasts')|map(attribute='per_kwh')|list))
| tojson
}},
"load_cost_forecast": {{
([states('sensor.home_general_price')|float(0)] +
state_attr('sensor.home_general_forecast', 'forecasts') |map(attribute='per_kwh')|list)
| tojson
}},
"pv_power_forecast": {{
([states('sensor.solar_total')|int(0)] +
state_attr('sensor.solcast_pv_forecast_forecast_today', 'detailedForecast')|selectattr('period_start','gt',utcnow()) | map(attribute='pv_estimate')|map('multiply',2000)|map('int')|list +
state_attr('sensor.solcast_pv_forecast_forecast_tomorrow', 'detailedForecast')|selectattr('period_start','gt',utcnow()) | map(attribute='pv_estimate')|map('multiply',2000)|map('int')|list
)| tojson
}},
"prediction_horizon": {{
min(48, (state_attr('sensor.home_feed_in_forecast', 'forecasts')|map(attribute='per_kwh')|list|length)+1)
}},
"num_def_loads": 1,
"def_total_hours": [1,],
"P_deferrable_nom": [1300,],
"treat_def_as_semi_cont": [1,],
"set_def_constant": [0,],
"soc_init": {{(states('sensor.battery_total_2')|int(0))/100 }},
"soc_final": 0.2
}
They are pretty solid for me, but you seem to be missing battery SOC.
What happens when you click on the green N/A and expand the attributes?
So you mean soc_init is available as param for naive-mpc-optim only and I misread the documentation?
Probably yes⌠but can anybody tell me, for my unerstanding, why the initial SOC is not important/should not be defined for the day-ahead optimization, even thought it seems the inital and final SOC values are set from the configuration yaml?
Thanks
The one i found in the config of the emhass using my shell command does nothing. and the results dont change.
i need to alter the shell command for result changes
I have opposite experience. If I change the SOC values in the config and I run the day ahead optim, they have an effect and initial soc = final soc = config final soc. (see screenshot below, that shows 0,3 as start and target values, according to yaml config, in contrast to my shell command).
Thatâs why I was trying to manually set the inital and final values for the dayahed optim as well (and then fine tune with the mcp at a later stage).
But the real question is why I shouldnât set the values for the day ahead optim (if thatâs the case).
You use day ahead, this feature is not supported in dat ahead. Try mpc instead.
Would anyone have an idea as to why my system would dump energy regardless of the settings while the cost is high?
it even has the value to be high in the optimisation.
Ive tried on profil cost and self consumption and all 3 settings display the same outcome.
hass_url: empty
long_lived_token: empty
costfun: self-consumption
logging_level: INFO
optimization_time_step: 30
historic_days_to_retrieve: 2
method_ts_round: first
set_total_pv_sell: false
lp_solver: COIN_CMD
lp_solver_path: /usr/bin/cbc
set_nocharge_from_grid: true
set_nodischarge_to_grid: false
set_battery_dynamic: false
battery_dynamic_max: 0.9
battery_dynamic_min: -0.9
load_forecast_method: naive
sensor_power_photovoltaics: sensor.solar_total
sensor_power_load_no_var_loads: sensor.house_consumption
number_of_deferrable_loads: 1
list_nominal_power_of_deferrable_loads:
- nominal_power_of_deferrable_loads: 1
list_operating_hours_of_each_deferrable_load:
- operating_hours_of_each_deferrable_load: 5
list_peak_hours_periods_start_hours:
- peak_hours_periods_start_hours: "10:00"
list_peak_hours_periods_end_hours:
- peak_hours_periods_end_hours: "16:00"
list_treat_deferrable_load_as_semi_cont:
- treat_deferrable_load_as_semi_cont: true
load_peak_hours_cost: 0.1907
load_offpeak_hours_cost: 0.1419
photovoltaic_production_sell_price: 0.065
maximum_power_from_grid: 12000
list_pv_module_model:
- pv_module_model: CSUN_Eurasia_Energy_Systems_Industry_and_Trade_CSUN295_60M
list_pv_inverter_model:
- pv_inverter_model: Fronius_International_GmbH__Fronius_Primo_5_0_1_208_240__240V_
list_surface_tilt:
- surface_tilt: 22
list_surface_azimuth:
- surface_azimuth: 75
list_modules_per_string:
- modules_per_string: 20
list_strings_per_inverter:
- strings_per_inverter: 1
set_use_battery: true
battery_discharge_power_max: 11600
battery_charge_power_max: 11600
battery_discharge_efficiency: 0.95
battery_charge_efficiency: 0.95
battery_nominal_energy_capacity: 38000
battery_minimum_state_of_charge: 0.2
battery_maximum_state_of_charge: 1
battery_target_state_of_charge: 0.2
The optimisation generally exports to the grid when the prices are high (sell high).
Which timeslot are you taking about 19:00?
9am its exporting to the grid, both images are showing export and it will cost for this.
i found a work around to put the storage higher then the actual but thats a very odd thing
If your pricing schedule for the rest of the day is anything like mine with very low prices for the rest of the day, it is probably trying to empty the battery as low as possible to make room so can avoid exporting solar later in the day. I might make sense at 9am to export to the grid at -3c, if the price later in the day drops to -10c. You cut off the chart so we canât see the prices later in the day.
A couple of other comments;
I donât understand what you mean by this statement?
Here is my plan for tomorrow with a long run of both negative prices and costs:
I see something odd with the solar.forecast PV forecast method (overnight PV production)
Is it just me?
emhass_dayahead_optim_solar_forecast:
url: http://localhost:5000/action/dayahead-optim
method: POST
content_type: 'application/json'
payload: '{ "solar_forecast_kwp":8, "delta_forecast": {{ delta_forecast }}, "num_def_loads": {{ num_def_loads }}, "P_deferrable_nom": {{ P_deferrable_nom }}, "def_total_hours": {{ def_total_hours }}, "treat_def_as_semi_cont": {{ treat_def_as_semi_cont }}, "set_def_constant": {{ set_def_constant }}, "load_cost_forecast": {{ load_cost_forecast }}, "prod_price_forecast": {{ prod_price_forecast }} }'