Negative production prices

[rixxxx]

Describe the bug
Emhass wants to sell with negative production prices

To Reproduce
Feed emhass with negative production prices

Expected behavior
Negative production price can't make profit and shouldn't cause grid export.

Screenshots

[davidusb-geek]

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

[rixxxx]

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.

[davidusb-geek]

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.

[rixxxx]

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.

[davidusb-geek]

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.

[rixxxx]

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.

[purcell-lab]

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.

[davidusb-geek]

Adding PV curtailment capabilites seems like the best option. I will add that to the road map.

[LaurensVanAcker]

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

[davidusb-geek]

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

[purcell-lab]

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.

[rixxxx]

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.

[martinarva]

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.

[davidusb-geek]

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.

[purcell-lab]

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])

[davidusb-geek]

Solved!
Added support for both the hybrid inverter and the PV curtailment.
Closing but reopen if needed

[rixxxx]

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.

[rixxxx]

For comparision same from 0.9.1

[davidusb-geek]

There seems to be something wrong about this. I'll look into it.

[davidusb-geek]

Did you set your inverter model/brand correctly?

[rixxxx]

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

[davidusb-geek]

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

[purcell-lab]

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 ?

[davidusb-geek]

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.

[rixxxx]

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.

[davidusb-geek]

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

[davidusb-geek]

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?

[purcell-lab]

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)

[davidusb-geek]

Closing as completed.
@purcell-lab If your latest problem persists feel free to open a new issue on that topic.