No rush and take care of your partner first.
Cheers
Thank you very much, i worked everything out on a seperate dashboard for the moment.
just waiting for the esp modules and lcd screens to put this next to the machines 
After the upgrade to version 0.11 and ignoring the bugs regarding the cost function and duplicate battery entires in config, the addon is planning the loads even though I have all the values in def_total_hours set to zero during the mpc optimization call. I didnāt change the data in mpc optim call, I only upgraded the addon and the config. I even tried to reinstall addon but it didnāt help. I have to rollback to 0.10.6.
My bad, parameter names for data in the optim call also changed. I modified them and it works. But I found one more bug - selected logging_level in config is also returning to default level āINFOā.
For my own part, I go back to the previous version after an attempt to update. My setup works too well so Iāll wait until the bugs are gone. so a tip before you upgrade take a backup of the app so you can go back.
2 Likes
Sorry for being a bit lazy, but as you already went through it, can you recap which parameter names you had to update?
Thanks
1 Like
Thanks @110hs and @prezervos, for the bug shutouts.
The battery duplication bug and costfun / logging_level saving bug have been fixed here: GitHub - GeoDerp/emhass at merge-bug-fix
2 Likes
You can find them here: EMHASS & EMHASS-Add-on differences ā emhass 0.11.0 documentation
For example def_total_hours ā operating_hours_of_each_deferrable_load
delta_forecast ā delta_forecast_daily. Available runtime parameters are described also here: GitHub - GeoDerp/emhass at merge-bug-fix
3 Likes
Thanks,
It is good practice to provide backwards compatibility when changing parameters. These breaking changes are going to catch a lot of people outā¦ Without an automatic migration path.
In theory, both the new and legacy runtime parameters should be supported in this version of EMHASS. If they arenāt, itās quite possible there is a bug somewhere. Please let me know if you find any.
Hi everyone,
I have been looking at emhass over the weekend and found it very promising for optimising my energy consumption at home. There is a bit of a learning curve to get everything sorted, but think Iām getting there. The main problem I am trying to solve is to use the home battery as efficiently as possible with PV production and the hourly pricing on electricity. I donāt care about deferrable loads, at least not at this point.
However, there are a few things I canāt seem to get my head around.
-
I am running MPC optimisation hourly with the horison set to the number our hours for which I have hourly price data available, which ranges from 35 hours down to 11 depending on the time of day. So the horison gets shorter and shorter until new prices are published. But as I understand it, the horison can not be longer than 24 hours, so that is what I truncate the data vectors to if they are longer than that.
-
For each hour I update the forecast for the PV production and actual SoC from the battery.
-
However, the
soc_initparameter which I use to inform the MPC of the current SoC of the battery seem to be (mostly) ignored? -
There is some mentioning in the documentation that the MPC could be used together with day-head optimization, but what would be the point of that? Why not just run the MPC hourly with current data and best available forecasts on electricity prices (to/from grid), PV production and actual SoC of the battery?
Is there any kind soul out there who can help me understand this?
Below is a excerpt from an optimisation round with the MPC:
2024-10-28 11:01:00,420 - web_server - INFO - Passed runtime parameters: {'load_cost_forecast': [0.97, 1.0, 1.07, 1.22, 1.26, 1.32, 1.36, 1.28, 1.26, 1.22, 1.19, 1.0], 'prod_price_forecast': [0.7, 0.72, 0.78, 0.89, 0.93, 0.98, 1.01, 0.95, 0.93, 0.89, 0.87, 0.72], 'pv_power_forecast': [503, 372, 263, 110, 12, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 29, 211, 608, 860, 905], 'battery_target_state_of_charge': 0.6801, 'soc_init': 0.6801, 'soc_final': 1, 'prediction_horizon': 12}
2024-10-28 11:01:00,420 - web_server - INFO - >> Setting input data dict
2024-10-28 11:01:00,420 - web_server - INFO - Setting up needed data
2024-10-28 11:01:00,424 - web_server - INFO - Retrieve hass get data method initiated...
2024-10-28 11:01:06,225 - web_server - INFO - Retrieving weather forecast data using method = list
2024-10-28 11:01:06,226 - web_server - INFO - Retrieving data from hass for load forecast using method = naive
2024-10-28 11:01:06,226 - web_server - INFO - Retrieve hass get data method initiated...
2024-10-28 11:01:21,103 - web_server - INFO - >> Performing naive MPC optimization...
2024-10-28 11:01:21,103 - web_server - INFO - Performing naive MPC optimization
2024-10-28 11:01:21,112 - web_server - INFO - Perform an iteration of a naive MPC controller
2024-10-28 11:01:21,151 - web_server - WARNING - Solver default unknown, using default
Welcome to the CBC MILP Solver
Version: 2.10.3
Build Date: Dec 15 2019
command line - /usr/local/lib/python3.11/dist-packages/pulp/solverdir/cbc/linux/64/cbc /tmp/ca4cdd488e8d4df292a28918ee778020-pulp.mps -max -timeMode elapsed -branch -printingOptions all -solution /tmp/ca4cdd488e8d4df292a28918ee778020-pulp.sol (default strategy 1)
At line 2 NAME MODEL
At line 3 ROWS
At line 138 COLUMNS
At line 821 RHS
At line 955 BOUNDS
At line 1088 ENDATA
Problem MODEL has 133 rows, 108 columns and 550 elements
Coin0008I MODEL read with 0 errors
Option for timeMode changed from cpu to elapsed
Continuous objective value is -15.1514 - 0.00 seconds
Cgl0002I 12 variables fixed
Cgl0003I 0 fixed, 0 tightened bounds, 14 strengthened rows, 0 substitutions
Cgl0003I 0 fixed, 0 tightened bounds, 1 strengthened rows, 0 substitutions
Cgl0004I processed model has 82 rows, 72 columns (24 integer (24 of which binary)) and 433 elements
Cbc0038I Initial state - 11 integers unsatisfied sum - 0.854544
Cbc0038I Pass 1: suminf. 0.85454 (11) obj. 15.1514 iterations 9
Cbc0038I Solution found of 15.1514
Cbc0038I Relaxing continuous gives 15.1514
Cbc0038I Before mini branch and bound, 13 integers at bound fixed and 35 continuous
Cbc0038I Mini branch and bound did not improve solution (0.01 seconds)
Cbc0038I After 0.01 seconds - Feasibility pump exiting with objective of 15.1514 - took 0.00 seconds
Cbc0012I Integer solution of 15.151406 found by feasibility pump after 0 iterations and 0 nodes (0.01 seconds)
Cbc0001I Search completed - best objective 15.15140570665693, took 0 iterations and 0 nodes (0.01 seconds)
Cbc0035I Maximum depth 0, 0 variables fixed on reduced cost
Cuts at root node changed objective from 15.1514 to 15.1514
Probing was tried 0 times and created 0 cuts of which 0 were active after adding rounds of cuts (0.000 seconds)
Gomory was tried 0 times and created 0 cuts of which 0 were active after adding rounds of cuts (0.000 seconds)
Knapsack was tried 0 times and created 0 cuts of which 0 were active after adding rounds of cuts (0.000 seconds)
Clique was tried 0 times and created 0 cuts of which 0 were active after adding rounds of cuts (0.000 seconds)
MixedIntegerRounding2 was tried 0 times and created 0 cuts of which 0 were active after adding rounds of cuts (0.000 seconds)
FlowCover was tried 0 times and created 0 cuts of which 0 were active after adding rounds of cuts (0.000 seconds)
TwoMirCuts was tried 0 times and created 0 cuts of which 0 were active after adding rounds of cuts (0.000 seconds)
ZeroHalf was tried 0 times and created 0 cuts of which 0 were active after adding rounds of cuts (0.000 seconds)
Result - Optimal solution found
Objective value: -15.15140571
Enumerated nodes: 0
Total iterations: 0
Time (CPU seconds): 0.01
Time (Wallclock seconds): 0.01
Option for printingOptions changed from normal to all
Total time (CPU seconds): 0.01 (Wallclock seconds): 0.01
2024-10-28 11:01:21,171 - web_server - INFO - Status: Optimal
2024-10-28 11:01:21,171 - web_server - INFO - Total value of the Cost function = -15.15
2024-10-28 11:01:21,378 - web_server - INFO - Passed runtime parameters: {'publish_prefix': 'emhass_'}
2024-10-28 11:01:21,378 - web_server - INFO - >> Setting input data dict
2024-10-28 11:01:21,378 - web_server - INFO - Setting up needed data
2024-10-28 11:01:21,380 - web_server - INFO - >> Publishing data...
2024-10-28 11:01:21,380 - web_server - INFO - Publishing data to HASS instance
2024-10-28 11:01:21,380 - web_server - WARNING - no saved entity json files in path:/app/data/entities
2024-10-28 11:01:21,380 - web_server - WARNING - falling back to opt_res_latest
2024-10-28 11:01:21,442 - web_server - INFO - Successfully posted to sensor.emhass_p_pv_forecast = 372.0
2024-10-28 11:01:21,507 - web_server - INFO - Successfully posted to sensor.emhass_p_load_forecast = 556.31
2024-10-28 11:01:21,599 - web_server - INFO - Successfully posted to sensor.emhass_p_deferrable0 = 0.0
2024-10-28 11:01:21,660 - web_server - INFO - Successfully posted to sensor.emhass_p_batt_forecast = 0.0
2024-10-28 11:01:21,721 - web_server - INFO - Successfully posted to sensor.emhass_soc_batt_forecast = 100.0
2024-10-28 11:01:21,791 - web_server - INFO - Successfully posted to sensor.emhass_p_grid_forecast = 184.31
2024-10-28 11:01:21,844 - web_server - INFO - Successfully posted to sensor.emhass_total_cost_fun_value = -15.15
2024-10-28 11:01:21,896 - web_server - INFO - Successfully posted to sensor.emhass_optim_status = Optimal
2024-10-28 11:01:21,948 - web_server - INFO - Successfully posted to sensor.emhass_unit_load_cost = 1.0
2024-10-28 11:01:22,013 - web_server - INFO - Successfully posted to sensor.emhass_unit_prod_price = 0.72
As can be seen, soc_init is set to 0.6801, but the optimisation returns soc_batt_forecast = 100.0. Could it be that the publish function actually only gives me the next hour (not current)? So what I get in the hass sensor is actually for 12 UTC, not 11 UTC when the optimisation was ran? If so, wow do I get the numbers for the current hour?
I am running the latest version (0.11.0) in a Docker container.
Yes the values in āforecastā variable are future values.
The current value of your SOC is 68.01% and the forecasted value for the following hour will be 100%, altough it is strange that the forecasted charging power is 0!
Probably related to that warningn message: WARNING - no saved entity json files in path:/app/data/entities
What does the graph or the table in the webui says?
For me using MPC together with a day-ahead optimization would be the ideal case. That is why youāll find that mentioned in the documentation.
The reasoning is the SOC variable that for me is a long term state in a daily optimization. So launch the day-ahead to obtain the best possible path or trajectory of the SOC for the next 24h.
Then MPC is designed to follow that optimal path as close as possible while dealing with fast short-term variabilities of forecasts, costs, etc., in a sliding window. The MPC is launched at a higher rate than just once a day as the day-ahead optimization.
Iām not using MPC myself at home but that is how I designed it and that is how Iāve used it before with success on other applications.
But that does not forbids to use it differently. I see a lot of people using it alone without the day-ahead optimization part and they seems to get good expected results. But then, as I see it, the long-term optimization notion is lost.
Thanks for your answer! The graph in the webui indeed shows values for current hour as well, which makes it all look sensible.
Also the value for forecasted charging power concerns the next hour.
Wouldnāt it make sense to publish the numbers for the current hour as current state of the sensors? And have the following hours in the attribute dictionary? ā¦ took a moment to look into the code, and found idx_closest. I have timestamp rounding set to nearest, and since I run this the first minute in the hour, that should not be the problem. Which leads me to think it might be a time zone conversion issue? Could that be the cause that future numbers are published as current state?
Ok, thanks. Thing is, I canāt say when the optimal time to reach maximum SoC will occur. It might well occur beyond the initial optimisation window, and that will not be known until the next day-ahead prices are published.
So my idea is to have final_soc set to 100% but always at least 11 hours in the future, and try to optimise that continuously. It is not unlikely this is a very bad idea, I havenāt tried it yet
But, just to understand what you are saying, could the day-ahead optimisation and the MPC optimisation, with the same input and horison, come to different results?
If you set the MPC horizon to 24h and set SOC init/final as you would in a day-ahead optimization then the results should be exactly the same
1 Like
Those can be left empty without any issue, that would just mean that you are not treating the eventual NaN values of your provided sensors.
What do you mean by āworks partiallyā?
1 Like
Question from a newcomer : How do I configure āemhassā to control a water heater? This should work for half an hour 4 times a day. And not like I get it now 2 hours in a row and then not for the rest of the day?
Charging my home battery at the cheapest rate is now working perfectly.
Maybe you can model 4 different deferrables and limit the range of hours they are allowed to operate in, with different ranges throughout the day.
Or maybe the thermal model is a better fit, but thatās above my pay grade.
2 Likes
I made the update to 0.11.1.
Since then, defferable loads are scheduled while def_total_hours = 0
This is my config.json
{
"battery_charge_efficiency": 0.95,
"battery_charge_power_max": 1000,
"battery_discharge_efficiency": 0.95,
"battery_discharge_power_max": 1000,
"battery_dynamic_max": 0.9,
"battery_dynamic_min": -0.9,
"battery_maximum_state_of_charge": 0.9,
"battery_minimum_state_of_charge": 0.3,
"battery_nominal_energy_capacity": 5000,
"battery_target_state_of_charge": 0.6,
"compute_curtailment": false,
"continual_publish": false,
"costfun": "profit",
"delta_forecast_daily": 1,
"end_timesteps_of_each_deferrable_load": [
0,
0,
0,
0,
0
],
"historic_days_to_retrieve": 100,
"inverter_is_hybrid": false,
"load_cost_forecast_method": "hp_hc_periods",
"load_forecast_method": "mlforecaster",
"load_negative": false,
"load_offpeak_hours_cost": 0.164497535,
"load_peak_hour_periods": {
"period_hp_1": [
{
"start": "08:00"
},
{
"end": "09:00"
}
],
"period_hp_2": [
{
"start": "09:00"
},
{
"end": "10:00"
}
],
"period_hp_3": [
{
"start": "11:00"
},
{
"end": "12:00"
}
],
"period_hp_4": [
{
"start": "13:00"
},
{
"end": "14:00"
}
],
"period_hp_5": [
{
"start": "15:00"
},
{
"end": "16:00"
}
]
},
"load_peak_hours_cost": 0.164497535,
"logging_level": "DEBUG",
"lp_solver": "COIN_CMD",
"lp_solver_path": "/usr/bin/cbc",
"maximum_power_from_grid": 14000,
"maximum_power_to_grid": 9000,
"method_ts_round": "first",
"modules_per_string": [
16
],
"nominal_power_of_deferrable_loads": [
2000,
2000,
1700,
900,
2000
],
"number_of_deferrable_loads": 5,
"operating_hours_of_each_deferrable_load": [
2,
2,
2.5,
1,
0
],
"optimization_time_step": 30,
"photovoltaic_production_sell_price": 0,
"production_price_forecast_method": "constant",
"pv_inverter_model": [
"SolarEdge_Technologies_Ltd___SE3000__240V_",
"Chint_Solar_Zhejiang__CHPI4KTL_US__240V_"
],
"pv_module_model": [
"CSUN_Eurasia_Energy_Systems_Industry_and_Trade_CSUN295_60M"
],
"sensor_linear_interp": [
"sensor.emhass_huidige_opbrengst",
"sensor.huidig_verbruik_zonder_wp"
],
"sensor_power_load_no_var_loads": "sensor.huidig_verbruik_zonder_wp",
"sensor_power_photovoltaics": "sensor.emhass_huidige_opbrengst",
"sensor_replace_zero": [
"sensor.emhass_huidige_opbrengst"
],
"set_battery_dynamic": false,
"set_deferrable_load_single_constant": [
true,
true,
true,
false,
false
],
"set_deferrable_startup_penalty": [
0,
0,
0,
0,
0
],
"set_nocharge_from_grid": false,
"set_nodischarge_to_grid": true,
"set_total_pv_sell": false,
"set_use_battery": false,
"set_zero_min": true,
"start_timesteps_of_each_deferrable_load": [
0,
0,
0,
0,
0
],
"strings_per_inverter": [
1
],
"surface_azimuth": [
205
],
"surface_tilt": [
30
],
"treat_deferrable_load_as_semi_cont": [
true,
true,
true,
true,
true
],
"weather_forecast_method": "scrapper",
"weight_battery_charge": 1,
"weight_battery_discharge": 1
}
logs
2024-10-29 21:40:00,246 - web_server - INFO - Passed runtime parameters: {'prod_price_forecast': [-0.11, -0.11, -0.11, -0.11, -0.11, -0.11, -0.11, -0.11, -0.11, -0.11, -0.11, -0.11, -0.11, -0.11, -0.11, -0.11, -0.11, -0.11, -0.11, -0.11, -0.11, -0.11, -0.11, -0.11, -0.11, -0.11, -0.11, -0.11, -0.11, -0.11, -0.11, -0.11, -0.11, -0.11, -0.11, -0.11], 'load_cost_forecast': [0.164497535, 0.164497535, 0.164497535, 0.164497535, 0.164497535, 0.164497535, 0.164497535, 0.164497535, 0.164497535, 0.164497535, 0.164497535, 0.164497535, 0.164497535, 0.164497535, 0.164497535, 0.164497535, 0.164497535, 0.164497535, 0.174497535, 0.174497535, 0.174497535, 0.174497535, 0.174497535, 0.174497535, 0.164497535, 0.164497535, 0.164497535, 0.164497535, 0.164497535, 0.164497535, 0.164497535, 0.164497535, 0.164497535, 0.164497535, 0.164497535, 0.164497535], 'pv_power_forecast': [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 50, 158, 475, 611, 869, 1155, 1400, 1503, 1441, 1402, 1380, 1234, 1021, 884, 784, 623], 'load_power_forecast': [627, 873, 753, 840, 869, 805, 694, 638, 614, 629, 669, 674, 654, 594, 537, 515, 503, 511, 549, 538, 609, 657, 741, 710, 751, 649, 734, 735, 695, 905, 844, 606, 588, 599, 468, 404], 'prediction_horizon': 36, 'alpha': 1, 'beta': 0, 'num_def_loads': 5, 'p_deferrable_nom': [2000, 2000, 1700, 900, 2000], 'def_total_hours': [0.0, 0.0, 0.0, 0.5, 0.0], 'set_def_constant': [True, True, True, True, True], 'def_start_timestep': [0, 0, 0, 0, 0], 'def_end_timestep': [0, 0, 0, 48, 0], 'def_current_state': [False, False, False, False, False]}
2024-10-29 21:40:00,246 - web_server - INFO - >> Setting input data dict
2024-10-29 21:40:00,246 - web_server - INFO - Setting up needed data
2024-10-29 21:40:00,249 - web_server - INFO - Retrieve hass get data method initiated...
2024-10-29 21:40:01,249 - web_server - INFO - Retrieving weather forecast data using method = list
2024-10-29 21:40:01,252 - web_server - INFO - >> Performing naive MPC optimization...
2024-10-29 21:40:01,252 - web_server - INFO - Performing naive MPC optimization
2024-10-29 21:40:01,263 - web_server - INFO - Perform an iteration of a naive MPC controller
2024-10-29 21:40:01,338 - web_server - DEBUG - Deferrable load 0: Proposed optimization window: 0 --> 0
2024-10-29 21:40:01,338 - web_server - DEBUG - Deferrable load 0: Validated optimization window: 0 --> 0
2024-10-29 21:40:01,341 - web_server - DEBUG - Deferrable load 1: Proposed optimization window: 0 --> 0
2024-10-29 21:40:01,341 - web_server - DEBUG - Deferrable load 1: Validated optimization window: 0 --> 0
2024-10-29 21:40:01,344 - web_server - DEBUG - Deferrable load 2: Proposed optimization window: 0 --> 0
2024-10-29 21:40:01,344 - web_server - DEBUG - Deferrable load 2: Validated optimization window: 0 --> 0
2024-10-29 21:40:01,347 - web_server - DEBUG - Deferrable load 3: Proposed optimization window: 0 --> 48
2024-10-29 21:40:01,347 - web_server - DEBUG - Deferrable load 3: Validated optimization window: 0 --> 36
2024-10-29 21:40:01,349 - web_server - DEBUG - Deferrable load 4: Proposed optimization window: 0 --> 0
2024-10-29 21:40:01,349 - web_server - DEBUG - Deferrable load 4: Validated optimization window: 0 --> 0
2024-10-29 21:40:02,046 - web_server - INFO - Status: Optimal
2024-10-29 21:40:02,046 - web_server - INFO - Total value of the Cost function = -2.90
2024-10-29 21:40:42,007 - web_server - INFO - Passed runtime parameters: {'custom_deferrable_forecast_id': [{'entity_id': 'sensor.emhass_wasmachien', 'unit_of_measurement': 'W', 'friendly_name': 'Emhass wasmachien'}, {'entity_id': 'sensor.emhass_droogkast', 'unit_of_measurement': 'W', 'friendly_name': 'Emhass droogkast'}, {'entity_id': 'sensor.emhass_afwasmachien', 'unit_of_measurement': 'W', 'friendly_name': 'Emhass afwasmachien'}, {'entity_id': 'sensor.emhass_warmtepompboiler', 'unit_of_measurement': 'W', 'friendly_name': 'Emhass warmtepompboiler'}, {'entity_id': 'sensor.emhass_warmtepomp', 'unit_of_measurement': 'W', 'friendly_name': 'Emhass warmtepomp'}], 'custom_pv_forecast_id': {'entity_id': 'sensor.emhass_pv_forecast', 'unit_of_measurement': 'W', 'friendly_name': 'Emhass pv forecast'}, 'custom_load_forecast_id': {'entity_id': 'sensor.emhass_load_forecast', 'unit_of_measurement': 'W', 'friendly_name': 'Emhass load forecast'}, 'custom_grid_forecast_id': {'entity_id': 'sensor.emhass_grid_forecast', 'unit_of_measurement': 'W', 'friendly_name': 'Emhass grid forecast'}, 'custom_unit_load_cost_id': {'entity_id': 'sensor.emhass_load_cost', 'unit_of_measurement': 'ā¬/kWh', 'friendly_name': 'Emhass load cost'}, 'custom_unit_prod_price_id': {'entity_id': 'sensor.emhass_prod_price', 'unit_of_measurement': 'ā¬/kWh', 'friendly_name': 'Emhass production price'}, 'custom_pv_curtailment_id': {'entity_id': 'sensor.emhass_curtailment', 'unit_of_measurement': 'W', 'friendly_name': 'Emhass curtailment'}}
2024-10-29 21:40:42,008 - web_server - INFO - >> Setting input data dict
2024-10-29 21:40:42,008 - web_server - INFO - Setting up needed data
2024-10-29 21:40:42,013 - web_server - INFO - >> Publishing data...
2024-10-29 21:40:42,013 - web_server - INFO - Publishing data to HASS instance
2024-10-29 21:40:42,042 - web_server - INFO - Successfully posted to sensor.emhass_pv_forecast = 0
2024-10-29 21:40:42,061 - web_server - INFO - Successfully posted to sensor.emhass_load_forecast = 627
2024-10-29 21:40:42,080 - web_server - INFO - Successfully posted to sensor.emhass_wasmachien = 0.0
2024-10-29 21:40:42,097 - web_server - INFO - Successfully posted to sensor.emhass_droogkast = 0.0
2024-10-29 21:40:42,104 - web_server - INFO - Successfully posted to sensor.emhass_afwasmachien = 0.0
2024-10-29 21:40:42,112 - web_server - INFO - Successfully posted to sensor.emhass_warmtepompboiler = 0.0
2024-10-29 21:40:42,119 - web_server - INFO - Successfully posted to sensor.emhass_warmtepomp = 0.0
2024-10-29 21:40:42,125 - web_server - INFO - Successfully posted to sensor.emhass_grid_forecast = 627.0
2024-10-29 21:40:42,134 - web_server - INFO - Successfully posted to sensor.total_cost_fun_value = -2.9
2024-10-29 21:40:42,139 - web_server - INFO - Successfully posted to sensor.optim_status = Optimal
2024-10-29 21:40:42,145 - web_server - INFO - Successfully posted to sensor.emhass_load_cost = 0.1645
2024-10-29 21:40:42,152 - web_server - INFO - Successfully posted to sensor.emhass_prod_price = -0.11
2024-10-29 21:40:44,003 - web_server - INFO - EMHASS server online, serving index.html...
2024-10-29 21:40:48,254 - web_server - INFO - serving configuration.html...
2024-10-29 21:40:48,319 - web_server - DEBUG - Obtaining current saved parameters as config
2024-10-29 21:40:48,320 - web_server - INFO - Obtaining parameters from config.json:
2024-10-29 21:40:48,328 - web_server - DEBUG - Converting param to config
2024-10-29 21:40:50,297 - web_server - DEBUG - Obtaining current saved parameters as config
2024-10-29 21:40:50,298 - web_server - INFO - Obtaining parameters from config.json:
2024-10-29 21:40:50,300 - web_server - DEBUG - Converting param to config
index P_PV P_Load P_deferrable0 P_deferrable1 P_deferrable2 P_deferrable3 P_deferrable4 P_grid_pos P_grid_neg P_grid unit_load_cost unit_prod_price cost_profit cost_fun_profit
2024-10-29 21:30:00+01:00 0 627 0 0 0 0 0 627 0 627 0.164 -0.11 -0.052 -0.052
2024-10-29 22:00:00+01:00 0 873 0 0 0 0 0 873 0 873 0.164 -0.11 -0.072 -0.072
2024-10-29 22:30:00+01:00 0 753 0 0 0 0 0 753 0 753 0.164 -0.11 -0.062 -0.062
2024-10-29 23:00:00+01:00 0 840 0 0 0 0 0 840 0 840 0.164 -0.11 -0.069 -0.069
2024-10-29 23:30:00+01:00 0 869 0 0 0 0 0 869 0 869 0.164 -0.11 -0.071 -0.071
2024-10-30 00:00:00+01:00 0 805 0 0 0 0 0 805 0 805 0.164 -0.11 -0.066 -0.066
2024-10-30 00:30:00+01:00 0 694 0 0 0 0 0 694 0 694 0.164 -0.11 -0.057 -0.057
2024-10-30 01:00:00+01:00 0 638 0 0 0 0 0 638 0 638 0.164 -0.11 -0.052 -0.052
2024-10-30 01:30:00+01:00 0 614 0 0 0 0 0 614 0 614 0.164 -0.11 -0.051 -0.051
2024-10-30 02:00:00+01:00 0 629 0 0 0 0 0 629 0 629 0.164 -0.11 -0.052 -0.052
2024-10-30 02:30:00+01:00 0 669 0 0 0 0 0 669 0 669 0.164 -0.11 -0.055 -0.055
2024-10-30 03:00:00+01:00 0 674 0 0 0 0 0 674 0 674 0.164 -0.11 -0.055 -0.055
2024-10-30 03:30:00+01:00 0 654 0 0 0 0 0 654 0 654 0.164 -0.11 -0.054 -0.054
2024-10-30 04:00:00+01:00 0 594 0 0 0 0 0 594 0 594 0.164 -0.11 -0.049 -0.049
2024-10-30 04:30:00+01:00 0 537 0 0 0 0 0 537 0 537 0.164 -0.11 -0.044 -0.044
2024-10-30 05:00:00+01:00 0 515 0 0 0 0 0 515 0 515 0.164 -0.11 -0.042 -0.042
2024-10-30 05:30:00+01:00 0 503 0 0 0 0 0 503 0 503 0.164 -0.11 -0.041 -0.041
2024-10-30 06:00:00+01:00 0 511 0 0 0 0 0 511 0 511 0.164 -0.11 -0.042 -0.042
2024-10-30 06:30:00+01:00 0 549 0 0 0 0 0 549 0 549 0.174 -0.11 -0.048 -0.048
2024-10-30 07:00:00+01:00 0 538 0 0 0 0 0 538 0 538 0.174 -0.11 -0.047 -0.047
2024-10-30 07:30:00+01:00 50 609 0 0 0 0 0 559 0 559 0.174 -0.11 -0.049 -0.049
2024-10-30 08:00:00+01:00 158 657 0 0 0 0 0 499 0 499 0.174 -0.11 -0.044 -0.044
2024-10-30 08:30:00+01:00 475 741 0 0 0 0 0 266 0 266 0.174 -0.11 -0.023 -0.023
2024-10-30 09:00:00+01:00 611 710 0 0 0 0 0 99 0 99 0.174 -0.11 -0.009 -0.009
2024-10-30 09:30:00+01:00 869 751 0 0 0 900 0 782 0 782 0.164 -0.11 -0.064 -0.064
2024-10-30 10:00:00+01:00 1155 649 0 0 1700 900 0 2094 0 2094 0.164 -0.11 -0.172 -0.172
2024-10-30 10:30:00+01:00 1400 734 0 0 1700 0 0 1034 0 1034 0.164 -0.11 -0.085 -0.085
2024-10-30 11:00:00+01:00 1503 735 0 0 1700 0 0 932 0 932 0.164 -0.11 -0.077 -0.077
2024-10-30 11:30:00+01:00 1441 695 2000 0 1700 0 0 2954 0 2954 0.164 -0.11 -0.243 -0.243
2024-10-30 12:00:00+01:00 1402 905 2000 0 1700 0 0 3203 0 3203 0.164 -0.11 -0.263 -0.263
2024-10-30 12:30:00+01:00 1380 844 2000 0 0 0 0 1464 0 1464 0.164 -0.11 -0.120 -0.120
2024-10-30 13:00:00+01:00 1234 606 2000 0 0 0 0 1372 0 1372 0.164 -0.11 -0.113 -0.113
2024-10-30 13:30:00+01:00 1021 588 0 2000 0 0 0 1567 0 1567 0.164 -0.11 -0.129 -0.129
2024-10-30 14:00:00+01:00 884 599 0 2000 0 0 0 1715 0 1715 0.164 -0.11 -0.141 -0.141
2024-10-30 14:30:00+01:00 784 468 0 2000 0 0 0 1684 0 1684 0.164 -0.11 -0.139 -0.139
2024-10-30 15:00:00+01:00 623 404 0 2000 0 0 0 1781 0 1781 0.164 -0.11 -0.146 -0.146