Thanks for your assistant, sorry it is a 24 hour turn around to debug these issues.
0.1.24 is still having issues for me. I might switch to github issues rather than continue to clutter the discussion here.
Moved to 0.1.24 500 Internal Server Error · Issue #3 · davidusb-geek/emhass-add-on · GitHub
I was hoping you could provide some clarity on the numbers as I don’t follow what is going on:
1.How is cost_profit calculated?
When importing from grid - cost_profit should be negative?
0.001 * P_grid_pos * unit_load_cost
When exporting to grid - cost_profit should be positive?
0.001 * P_grid_neg * unit_prod_cost
At 1530 the PV is generating 10618 W (P-PV), the load is 592 W (P_Load), which means we are exporting to the grid 9925 W (agrees with P_grid_neg, the export price is 0.3 (unit_prod_price) and as we are exporting we get a credit.
0.001 * 9925 * 0.3 / 2 (as we are in 30 minute blocks) = 1.48875 (which doesn’t equal cost_profit)
2.Why is cost_profit sometimes positive and sometimes negative?
From 1530-1830 we see values in P_grid_negative because we are exporting to the grid across all those time windows, as the sell price is positive (unit_prod_price) then why isn’t cost_profit positive. At 1700 and 1800 we see cost_profit is negative even though we are exporting to the grid.
From 1830 onwards solar production (P_PV) ceases and we import from the grid and cost_profit is negative.
Oh yes, thank you for your remark!
The cost function equations are found here: An EMS based on Linear Programming — emhass 0.2.11 documentation
I see the thing here. You’re considering an auto-consumption case where you directly consume your house load from the produced PV. In that case your calculation is correct, for 1530 you should be getting a credit of 1.48875. The equation that I’m using for cost_profit is based on a second type of self-consumption implemented here in France where you sell ALL your PV production to the grid and then you don’t have a direct consumption of your PV produced power. There is an energy counter for exported energy and a second different energy counter for imported energy to the house.
I will update the code and the add-on to consider your case that will also be a more worldwide generalized case, which is direct self-consumption of your PV energy.
So for your case the cost_profit sign is a direct reflect of the sign of the grid power: negative for exported power to the grid and positive for imported power from the grid. I will update the cost_profit equation to treat this case.
After the update it should look like this table for your case:
where cost_profit_updated will be the new equation for your case that I will update soon…
Done! I added a parameter set_total_pv_sell to consider that all PV power is injected to the grid or not. By default is set to false to consider a direct self-consumption case where the house load can be directly supplied with produced PV power.
Update to >> v0.1.39: Release EMHASS add-on v0.1.39 · davidusb-geek/emhass-add-on · GitHub
I can see you have updated the calculation:
But I am still getting the incorrect (and some negative values when exporting to the grid 14:00 and 14:30), so for some reason the if statement around set_total_pv_sell isn’t being recognised correctly.
Yes I can see why. The if statement is being taken care without any issue during the optimization. In the code at the end of the optimization the costs are recomputed to be saved and printed on the table and I just forgot an if statement there. I’ll be out of town today but I’ll be able to fix it tomorrow. So the optimization results and the scheduling of deferrable loads should be ok, it’s just the final table that was not properly updated.
Hi, the new version with the fixed issue is out >> v0.1.40: Release EMHASS add-on v0.1.40 · davidusb-geek/emhass-add-on · GitHub
I also added support for mixed orientation systems, with this you can now simulate multiple PV array configurations for example one east-facing array (azimuth=90) and one west-facing array (azimuth=270).
For this you should pass the following parameters as comma separated strings: pv_module_model,
pv_inverter_model, surface_tilt, surface_azimuth, modules_per_string, strings_per_inverter.
For example:
surface_azimuth: 90,270
If you have two different PV arrays orientation.
See the add-on documentation for more info: emhass-add-on/DOCS.md at 54b5317e8a39cf244bbb10f26fe6136767b9633f · davidusb-geek/emhass-add-on · GitHub
Thanks for the update, you are certainly developing this add on quickly.
With the update to 0.1.40 I am unable to save the configuration, even with the default settings, and thus cannot start the add-on. Unsure if this is related to the mixed orientation settings.
I have managed to work the format to have multiple arrays.
This is looking great now, I’m using the PVLib forecasts, although still can’t quite find the correct inverter.
But it is telling me when to charge/ discharge my battery and well as cuing my deferable loads all with my variable sell/buy costs…
Great!!!
What was the problem? Is there any explanation that I can add to the docs to help the user avoid that kind of error?
What is the brand/model of your inverter?
And how did you managed to make the battery work? You augmented the time step to 60min?
What was the problem? Is there any explanation that I can add to the docs to help the user avoid that kind of error?
0.1.40 has an issue with a clean install:
If I edit config to two inverter setup I can save and start server.
I had to simplify the complexity of the problem space. I am wondering if falling back to GLPK_CMD isn’t as powerful solver? I find a working solver will take between 6-8 seconds, whereas an unworking solver just continues to run without stopping with CPU load showing in the add-on window.
I reduced the deferable loads from 4 to 2 and reduced their operating windows.
Interesting dayahead optimisation with over $100 credit in the next three hours, which is correct, and why I am so interested in EMHASS, to automate these responses.
I did set up a battery with maximim discharge rate of 5000W, but it has chosen 4750W as the maximum discharge rate.
Wow, indeed, you’re directly exposing the importance of the optimization. It could be interesting to evaluate of much are you gaining. I mean what is the cost_profit of your system with and without the optimization. How far is the rule-based management of your battery from an optimization-based approach?
The real maximum discharge power in the simulation is accounting for the battery efficiency. This is modeled linearly in the LP formulation, but still will be fairly close to reality. On most of the range of the battery operating power the efficiency is fairly linear. For maximum power you will have minimum efficiency, hence: 4750 = 0.95*5000.
Here is a typical battery efficiency map:
If in reality your battery is able to really deliver 5000 W then set the max nominal power to 5% higher if you set your efficiency at 95%.
This efficiency is also considered when computing the battery state of charge SOC.
This is what my live dashboard looks like, we hit over $15 /kWh for a 30 minute block and tapering down now to $2.14 / kWh:
One thing I have noticed is there is no way to specify the starting SOC for the battery, which is generally available in a sensor entity. SOC will always be different for each dayahead iteration. Similarly with the optimal SOC at the end of the cycle, there maybe different needs. For the profit case, at end of a high price cycle SOC would be as low as possible (to backup reserve) but at the end of a low cost cycle you would want SOC to be as high as possible.
Perhaps a lookup of the battery SOC entity is required before each dayahead process to seed the LP model?
That got me thinking, the LP model could also be seeded with actual current PV, load, price & cost as a perfect representation of the current time period?
Similarly the expected run time (or energy to be delivered) for each deferrable load could also be useful to seed the LP model. E.g. EV with variable starting point (1 hour at 90% SOC, 4 hrs at 50% SOC, 8 hrs at 29% SOC), (water) heater - temp difference to desired set point (one hour for each degree of difference)?
For now the LP constraints for the battery are written to consider only a typical energy management LP formulation where SOC_init = SOC_final. The battery power is optimized so that the initial SOC is equal to the final SOC. The LP can be formulated to handle other different cases. This is in the roadmap: Home · davidusb-geek/emhass Wiki · GitHub
Yes this is in the roadmap, the initial SOC should be added by the user in the future.
This can be easily done. You can just provide as the first elements of the forecasts your current measured values. So you should be able to manipulate your lists to add this before passing them to emhass.
This is also in the roadmap. I will be adding a new constraint for total energy by deferrable load very soon.
I’ve just released >> v0.1.41: Release EMHASS add-on v0.1.41 · davidusb-geek/emhass-add-on · GitHub
In this release it is now possible to define the deferrable loads as semi-continuous variables. Semi-continuous variables are variables that can take either their nominal value or zero. So if you set the parameter treat_deferrable_load_as_semi_cont to false, the deferrable load will now take variable values after the optimization.
Also an issue installing the add-on was fixed.
It is possible to define the total energy by deferrable load using the nominal_power_of_deferrable_loads and the operating_hours_of_each_deferrable_load parameters.
