Comments (28)
This seems like a missing constraint on the maximum possible value of PV curtailment.
I will add this to a new patched version. Along with the missed publish of PV curtailment.
from emhass.
Adding PV curtailment capabilites seems like the best option. I will add that to the road map.
from emhass.
Sure, that's what I said earlier, the next best thing to do is to schedule some deferrable load. It is true that thermal storage, either by cooling or heating methods are quite interesting
from emhass.
but the PV curtailment command in our case could be easily computed (and coded in a HA automation) using the following logic
Two cases to consider for optimal curtailment strategy.
load_cost <= 0
This is what happened to me yesterday for three hours. In this circumstance the optimal strategy is to switch off all production and run from the grid.
For each timestep that load_cost <= 0 - pv_curtailment = p_pv (ie 100% curtailment)
Which I implement as follows:
** prod_price <= 0 & load_cost > 0 **
This is the more common case and the optimal strategy is to limit exports to zero p_grid should not be allowed below 0.
p_curtailment = min (p_pv, p_load + p_deferrable[0..x])
from emhass.
I have configured some random(my inverter vendor is not present in the db) inverter with correct 20kW Paco and now the results are same with 0.10.0 and 0.9.1. Thanks.
from emhass.
That table shows exactly the opposite that you say. It is avoiding injection to the grid when prod prices are negative by charging the battery.
What is the problem here? I don't see it, at least at a first glance
from emhass.
1st row at 13:00 sends 6880W to the grid and 2551W to the battery when the price is -0.009. Next row is correct, everything goes to the battery. At least I understand it this way.
from emhass.
Yes at 17:00 and 18:00 it also injects to the grid but I'm guessing that there's not much else to do. I mean the battery is full, the other option would be to degrade the MPPT of your PV production or to start some deferrable load but it seems that don't have any, so we are out of options. What are you expecting to happen here?, that produced energy has to go somewhere at the end.
from emhass.
I can understand 17:00 and 18:00. Batteries are full and nowhere else to go. Pretty easy to limit MPPT if I don't want to sell. However 13:00 is strange, batteries are not full, production price is negative, still it wants to sell instead of charging. I didn't make a screenshot before but it wasn't the only hour like that.
My logic tells, if production price is negative then every exported W decreases the profit. So if there is something else to do with the energy then it should do(eg charge the batteries, run deferred loads). Selling would be the last restort.
from emhass.
I think that the optimization is right. Look at the values for prod price. At 13:00 the prod price is less negative, so it makes more sense to inject to the grid there and not on the 3 time slots after that where the price is even more negative and the battery is correctly scheduled to charge as much as it can.
You need to consider that with this type of optimization the optimal minimum is guaranteed, given that all constraints are feasible, the problem is convex, so that solution shown in the table is the best possible outcome. Even if sometimes on some time slot it seems counterintuitive. You can check this yourself, just change the solution as what you think it was logic for you in this case and then compute the total value of the cost function, I bet it won't be better than what the algorithm obtained.
from emhass.
You are probably right. Could Emhass lower the p_pv_forecast(or some additional sensor) when there is going to be too much energy and and the price is negative to limit the loss of profit? Then we can use automation to cap MPPTs. Negative prices are becoming pretty common here.
from emhass.
Pretty easy to limit MPPT if I don't want to sell.
EMHASS doesn't currently provide a way to limit MPPT (solar curtailment/ export control), so it currently makes the next best option of only exporting when it minimises the losses of exporting with negative prices.
I also have 8 hours of negative prod_price for today and another 8 hours tomorrow.
I currently have a different automation that switches on my zero export control when the prod_price goes negative, but then EMHASS sees that as reduced PV production, so it re-optimises with the lower PV values, whilst it could continue to schedule loads upto the uncurtailed value.
I have a helper which provides a unconstrainted PVnow value, which can work around the issue for the now value:
sensor.solaredge_nopowerlimit:
{{min(15000,
states('sensor.solaredge_i1_ac_power')|float(0)
/ states('sensor.solaredge_i1_active_power_limit')|float(0.01)*100
+ states('sensor.solaredge_i2_ac_power')|float(0)
/states('sensor.solaredge_i2_active_power_limit')|float(0.01)*100)
}}
However, your original issue with EMHASS scheduling negative value exports does require some consideration, as we are all seeing larger hours of negative feed in pricing.
Here is my case from today, you can see at 1430 & 1500 timestep my battery is full (SOC=1) and the PV production has no where else to go except export to the grid, and my cost_profit for those timesteps is calculated to be negative:
index | P_PV | P_Load | P_deferrable4 | P_grid_pos | P_grid_neg | P_grid | P_batt | SOC_opt | unit_load_cost | unit_prod_price | cost_profit |
---|---|---|---|---|---|---|---|---|---|---|---|
2024-05-13 14:00:00+10:00 | 8459 | 400 | 600 | 0 | 0 | 0 | -7459 | 0.981 | 0.02 | -0.05 | 0 |
2024-05-13 14:30:00+10:00 | 7076 | 900 | 600 | 0 | -3873 | -3873 | -1702 | 1 | 0.03 | -0.04 | -0.077 |
2024-05-13 15:00:00+10:00 | 5768 | 400 | 600 | 0 | -4768 | -4768 | 0 | 1 | 0.06 | -0.01 | -0.024 |
2024-05-13 15:30:00+10:00 | 4271 | 400 | 600 | 0 | -3271 | -3271 | 0 | 1 | 0.1 | 0.02 | 0.033 |
2024-05-13 16:00:00+10:00 | 2608 | 300 | 0 | 0 | -2308 | -2308 | 0 | 1 | 0.29 | 0.06 | 0.069 |
2024-05-13 16:30:00+10:00 | 1107 | 1400 | 0 | 0 | 0 | 0 | 293 | 0.997 | 0.38 | 0.15 | 0 |
2024-05-13 17:00:00+10:00 | 0 | 1200 | 0 | 0 | -6593 | -6593 | 7793 | 0.907 | 0.56 | 0.31 | 1.022 |
2024-05-13 17:30:00+10:00 | 0 | 2400 | 0 | 0 | -12600 | -12600 | 15000 | 0.735 | 0.58 | 0.33 | 2.079 |
2024-05-13 18:00:00+10:00 | 0 | 700 | 0 | 0 | -14300 | -14300 | 15000 | 0.562 | 0.57 | 0.32 | 2.288 |
2024-05-13 18:30:00+10:00 | 0 | 700 | 0 | 0 | -14300 | -14300 | 15000 | 0.39 | 0.56 | 0.31 | 2.216 |
2024-05-13 19:00:00+10:00 | 0 | 800 | 0 | 0 | -13052 | -13052 | 13852 | 0.231 | 0.55 | 0.3 | 1.958 |
2024-05-13 19:30:00+10:00 | 0 | 400 | 0 | 0 | -7400 | -7400 | 7800 | 0.141 | 0.55 | 0.3 | 1.11 |
I find EMHASS does it's best to schedule as many Deferrable loads early to minimise this outcome, in my case today it is only two timesteps at the end of the day, but tomorrow I have the same issue.
Looking to potential solutions, so how EMHASS needs to understand that if the prod_price is negative for a timeslot that curtailment maybe an option and publish a lower value on p_pv to match loads and ensure that p_grid_negative remains zero during those timesteps, this however can be a complex model. However, I do see this at multiple EMHASS instances so a solution certainly is worthy of consideration.
from emhass.
Or integrate optional, non-energy-efficient optional loads? For instance, consider implementing thermal storage units that activate only when surplus energy is abundant. For example, I have a deep freezer capable of adjusting its temperature from -18 to -32 degrees Celsius to store excess cold as "cold storage". I also have a water heater that refrains from electric heating unless electricity is either free or penalized. See also here: #277
from emhass.
Adding PV curtailment capabilites seems like the best option. I will add that to the road map.
One suggestion for implementation would be to utilise the EMHASS no discharge to grid constraint but have it only apply to negative prod_price periods.
from emhass.
One suggestion for implementation would be to utilise the EMHASS no discharge to grid constraint but have it only apply to negative prod_price periods.
If you don't reduce solar production its still overflows to the grid when batteries are full. We need to have some variable to indicate the desired production rate.
from emhass.
Adding PV curtailment capabilites seems like the best option. I will add that to the road map.
That would be great. I have pool heater where I can offload the excess PW power when electricity export prices are negative.
Just have to figure out how to make the pool heater variable power. It's 12kw three phase at the moment. It would be fairly easy to make it 4,8,12kw as it has three heating elements, but would be awesome to have a variable 1-12kw power.
from emhass.
Hi all,
Correct me if I'm wrong, but the PV curtailment command in our case could be easily computed (and coded in a HA automation) using the following logic:
if prod_price < 0 and p_grid < 0:
pv_curtailment = p_grid
else:
pv_curtailment = 0
This is true I guess if we consider here that the PV curtailment is truly the last resort.
from emhass.
Solved!
Added support for both the hybrid inverter and the PV curtailment.
Closing but reopen if needed
from emhass.
Thanks for implementing this! However, I'm struggling understanding whats happening with curtailment. Why it chooses to curtail instead of selling excess PV when the price is not negative.
from emhass.
For comparision same from 0.9.1
from emhass.
There seems to be something wrong about this. I'll look into it.
from emhass.
Did you set your inverter model/brand correctly?
from emhass.
No, I haven't configured inverter model. I'm feeding all the forecasts from HA and I have configured P_from_grid_max, P_to_grid_max, Pd_max, Pc_max and Enom
from emhass.
Well now you need to. Just pick an inverter with the same nominal peak power as yours. You are using the 5kW inverter defined by default, giving you wrong results
from emhass.
Great work on 0.10, big release.
I have a couple of cases where p_pv_curtailment goes above p_pv, likely this should be prevented with another constraint.
Without this constraint perhaps EMHASS is trying to get to my soc_final of 0 and the only method is to export from battery during negative prod_pricing, earlier curtailment would have prevented earlier battery charging ?
from emhass.
I have configured some random(my inverter vendor is not present in the db) inverter with correct 20kW Paco and now the results are same with 0.10.0 and 0.9.1. Thanks.
Great! Yes only that Paco
variable is used, so its ok if its not exactly your inverter model
from emhass.
have a couple of cases where p_pv_curtailment goes above p_pv, likely this should be prevented with another constraint.
Could you confirm if it is better with the patched version?
from emhass.
Could you confirm if it is better with the patched version?
I haven't seen a repeat, so I think that constraint is implemented correctly now.
One other minor issue, I am seeing is curtailment when there are options to avoid early curtailment, for example when the battery hasn't yet hit max_soc or there are still deferrable loads that could be brought forward.
Some examples below:
At the 10:30 timestep scheduled to curtail 6045 W, but the battery is only at 0.198 SOC (for this exercise I have set max_soc to 0.50), so an alternative to curtailing at this time would be to charge the battery more early and curtail more later (13:00-15:00), or deferrable0 hasn't yet completed the required run hours so the run slot at 14:00 could be scheduled at 11:00. EMHASS currently has the cost of all these timeslots (09:30-15:00) as 0.00, which is optimal and wouldn't be changed by moving the schedule around.
However, I think it is more desirable to charge the battery more earlier and curtail more later, rather than curtailing when the battery still isn't fully charged)
from emhass.
Related Issues (20)
- EMHASS makes non profitable decisions about battery charge, despite battery charge/discharge weights HOT 6
- Missing EMHASS_button.svg HOT 2
- day-ahead optimisation fails since 0.9.0 HOT 6
- Docker not starting, web_server.py: error: unrecognized arguments: python3 src/emhass/web_server.py HOT 2
- Error while using forecast.solar (free version) HOT 2
- Repository structure v0.9.1 HOT 2
- Feature request: support power input sensors in kW HOT 6
- MPC optimization KeyError: 'inverter_is_hybrid' HOT 3
- Add: Huawei SUN2000-3/4/5/6/8/10KTL-M1 (High Current Version) into inverter database HOT 3
- Documentation: The meaning of alpha and beta values is reversed HOT 1
- Documentation update to help find compatible modules and panels HOT 2
- Data posted via home assistant is different to what appears in the EMHASS logs HOT 6
- Infeasible result with 0.10.1, optimal with 0.9.1 HOT 2
- Feature request: Provide p_hybrid_inverter as a sensor HOT 1
- Sensor unit: Unit is missing for 'Total cost function value' HOT 1
- load_cast_forecast nordpool fails, HOT 7
- pv_forecast is not aligning with JSON input for naive-mpc-optim command HOT 3
- Unable to connect to home assistant HOT 2
- Warning: deprecated lags_grid argument HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from emhass.