emhass icon indicating copy to clipboard operation
emhass copied to clipboard

Inverter can't output the load that EMHASS seems to think it should.

Open Deztak opened this issue 11 months ago • 22 comments

It seems that EMHASS is not accounting for my inverter having to supply the load and feed-in. Hence my 10kW inverter is currently outputting about 10kW but only 6kW is making it to the grid while EMHASS thinks about 10kW should be making it.

I have it setup in the Config that my max battery draw is 10kW and the max grid load is 13kW and the nominated inverter from the csv is a 10kW inverter. If I reduce the grid draw it'll fix this issue but then it will start recharging the batter early and I end up filling it while the feed-in price is still negative so I have solar going to waste and I needless paid higher prices to charge the battery.

I think this may be why I seem to be struggling to discharge the battery per the EMHASS planned discharge. I usually still have about 20-30% charge when the projection at midday was to drop it to 9% by the end of the peak feed-in period.

image

Deztak avatar Mar 08 '24 05:03 Deztak

I have my EMHASS forecasts (on the left) aligned with my actual readings (on the right) so I can debug these types of issues

Screenshot_20240308-160452

The EMHASS forecasts should always be in balance, if Optimal.

Grid +  PV + Battery = Load (+ deferrable loads)

It's not clear from your example above what are the four EMHASS forecasts.

purcell-lab avatar Mar 08 '24 06:03 purcell-lab

The bottom row are actuals, second bottom row is the planned. I’m re-running the option and publish every few minutes, basically when there is new pricing or Solar forecasts.

Most of the first three rows are actuals, total power is the sum of all of the power sources (actuals) and the percentages are the percentage of the total power that is being sourced (first row) and drawn (second row)

So EMHASS Grid Power is -9,679.09 W and this is just states.p_grid_forecast EMHASS PV Power is states.p_pv_forecast

I do have an output that shows the sum of the power sources from EMHASS and it was over 13,000 W … if there is an inverter power limit in the config then I’ve missed it but, I think this could be solved with an Inverter power limit as the batteries can be charge with up to 15,000 W from the PV on the DC circuit but the AC circuit is always limited to 10,000 W whether it’s powering the house or feeding the grid. When it’s recharging it will trip my 63amp circuit breaker at about 15,200 W so I could in theory power the house with 5,200 W while recharging the batteries from grid with 10,000 W … but tripping the circuit breaker too often has lead me to only allow 13,000 W that way turning on a 2,000W oven or kettle won’t trip the circuit breaker.

Deztak avatar Mar 08 '24 10:03 Deztak

Use the template editor in developer tools to share your actual curl command and the actual data that you are passing to each enpoint call. Also share the details of your setup/config as asked on the issue template. Otherwise it is difficult to provide help.

davidusb-geek avatar Mar 08 '24 10:03 davidusb-geek

Mark helped me out via an Amber-Home Assistant Facebook group to get some rest sensors setup that pull data from Solar.Forecast as well as pushing data to EMHASS. Unfortunately I can’t seem to copy-paste from the Mobile UI in Samba or access the add-on tabs.

If I end up not being able to get to sleep then I’ll copy-paste it all here but, if the issue is the user then I’m thinking it’s in the config. I messed about with it a bit, trying to get the EMHASS outputs to be right. SolarEdge setup the batteries with a charge limit of 11,400W as this is basically the theoretical peak PV power of my setup. I do have three of their 9.7kVA batteries, with a theoretical max DC charge rate of 15,000W (so I have spare capacity in my DC circuit)

I had the charge and discharge rates set to 10,000 W but then EMHASS was feeding back to the grid while the feed-in price was forecast to be negative, so I bumped up the charge rate to 11,400 W and that solved that issue but if I bumped up the discharge rate to 11,400 W then it would predict it discharging at 11,400 W … as that’s not possible I put it back to 10,000 W but, EMHASS seems to think the inverter can push out peak PV + peak battery discharge power at the same time.

Below is a plot of the actual total power and EMHASS total power. Below that is a plot of EMHASS PV, Batt, Grid & Load with the same time period actuals. Note in the processed data for the gauge display I need to negate the actual grid power as I have +ve for drawn power for each power source.

image image

Deztak avatar Mar 08 '24 12:03 Deztak

My rest commands: Copy-pasted from stuff Mark sent me on facebook as I tried to get his code from the help docs to work and struggled a lot. I don't use SolCast

rest_command: post_mpc_optim_solcast: url: http://homeassistant.local:5000/action/naive-mpc-optim method: POST content_type: 'application/json' payload: >- { "pv_power_forecast":{{states('sensor.solcast_24hrs_forecast')}},"load_cost_forecast":{{states('sensor.amber_gen_price_forecast')}},"prod_price_forecast":{{states('sensor.amber_prod_price_forecast')}},"prediction_horizon":{{states('sensor.solcast_24hrs_forecast')|from_json|count}},"soc_init":{{(states('sensor.med_battery_charge')|float(0)/100)|round(2)}},"soc_final":{{float(0.15)|round(2)}} } dayahead_optim: url: http://homeassistant.local:5000/action/dayahead-optim method: POST content_type: 'application/json' payload: >- {} publish_data: url: http://homeassistant.local:5000/action/publish-data method: POST content_type: 'application/json' payload: >- {}

The data passed through the 'post_mpc_optim_solcast' function looks like:

{ "pv_power_forecast": [ 3722, 4558, 5324, 6030, 6646, 7180, 7562, 7790, 7868, 7924, 7886, 7694, 7346, 6856, 6248, 5534, 4726, 3852, 3046, 2300, 1536, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 ], "load_cost_forecast": [ 0.13, 0.11, 0.14, 0.13, 0.07, 0.04, 0.04, 0.04, 0.04, 0.04, 0.04, 0.33, 0.35, 0.36, 0.38, 0.39, 0.39, 0.39, 0.41, 0.41, 0.45, 0.45, 0.46, 0.19, 0.19, 0.19, 0.18, 0.19, 0.19, 0.2, 0.19, 0.2, 0.19, 0.19, 0.19, 0.16 ], "prod_price_forecast": [ 0.04, 0.02, 0.04, 0.02, -0.04, -0.06, -0.07, -0.07, -0.07, -0.07, -0.07, 0.24, 0.27, 0.28, 0.29, 0.31, 0.31, 0.3, 0.32, 0.32, 0.36, 0.36, 0.37, 0.09, 0.09, 0.09, 0.08, 0.09, 0.09, 0.09, 0.09, 0.09, 0.09, 0.09, 0.09, 0.07 ], "prediction_horizon": 36, "soc_init": 0.17, "soc_final": 0.15 }

Deztak avatar Mar 08 '24 21:03 Deztak

EMHASS add-in config file: Note, I have no deferrable loads setup. Mark recommended that I try a shelly device to setup my hot water as a deferrable load. I'm still looking into this. My inverter and solar panels are not listed in the csv.

logging_level: INFO costfun: profit sensor_power_photovoltaics: sensor.solar_power_w sensor_power_load_no_var_loads: sensor.consumption_power_w set_total_pv_sell: false set_nocharge_from_grid: false set_nodischarge_to_grid: false maximum_power_from_grid: 10000 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: 0 list_start_timesteps_of_each_deferrable_load:
  • start_timesteps_of_each_deferrable_load: 0 list_end_timesteps_of_each_deferrable_load:
  • end_timesteps_of_each_deferrable_load: 0 list_peak_hours_periods_start_hours:
  • peak_hours_periods_start_hours: "00:00" list_peak_hours_periods_end_hours:
  • peak_hours_periods_end_hours: "00:00" list_treat_deferrable_load_as_semi_cont:
  • treat_deferrable_load_as_semi_cont: true list_set_deferrable_load_single_constant:
  • set_deferrable_load_single_constant: false load_peak_hours_cost: 0.1907 load_offpeak_hours_cost: 0.1419 photovoltaic_production_sell_price: 0.065 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: 32
  • surface_tilt: 36 list_surface_azimuth:
  • surface_azimuth: 34
  • surface_azimuth: 216 list_modules_per_string:
  • modules_per_string: 16
  • modules_per_string: 16 list_strings_per_inverter:
  • strings_per_inverter: 1
  • strings_per_inverter: 1 set_use_battery: true battery_nominal_energy_capacity: 29100 battery_discharge_power_max: 8000 battery_charge_power_max: 11399 battery_discharge_efficiency: 0.95 battery_charge_efficiency: 0.95 battery_minimum_state_of_charge: 0.12 battery_maximum_state_of_charge: 1 battery_target_state_of_charge: 0.1 weather_forecast_method: solar.forecast load_forecast_method: naive

Deztak avatar Mar 08 '24 21:03 Deztak

Note in today's plan @ 1700 I have 8,512 W in P_grid_neg and 3,813 W in P_load ... so the total power through the inverter per the plan is 12,325 W

newplot (2)

Deztak avatar Mar 08 '24 21:03 Deztak

I don't see a total inverter of 12 kW. According to that graph the maximum power through your inverter is around 8 kW peak. I really don't see the issue here.

davidusb-geek avatar Mar 08 '24 22:03 davidusb-geek

So looking at it from a power source perspective when my SolarEdge inverter is in "Discharge to maximise export" mode it outputs all available pv and batt power to the grid. At 1700 in the plot the pv power is about 5kW and the battery power is about 8kW, so the combined power is still more than the peak output of the inverter.

And as above, from a load perspective, my inverter can't power the grid independantly of the load, so as above the inverter outputs 10kW and what isn't consumed by the load goes to the grid ... with a load forecast of 3.8kW the grid export cannot be above 6.2kW (while the forecast is 8.5kW)

Deztak avatar Mar 09 '24 00:03 Deztak

I suspect your issue maybe that you have a DC coupled battery, so only the one inverter is servicing both PV and battery. So whilst your settings for your PV inverter can export 10 kW, your settings also state your battery (inverter) can discharge 8 kW. However your system is only capability of exporting a total of 10 kW, in any combination of battery and PV.

I have an AC coupled battery, so in effect I have two inverters; battery inverter and a PV inverter that can function independently. So in effect my maximum export is battery inverter (15 kW) + PV inverter (15 kW). This is how EMHASS models batteries and PV inverters.

purcell-lab avatar Mar 09 '24 01:03 purcell-lab

Yes, that makes the most sense for where my setup isn't as EMHASS assumes my setup is configured.

@purcell-lab

I suspect your issue maybe that you have a DC coupled battery, so only the one inverter is servicing both PV and battery. So whilst your settings for your PV inverter can export 10 kW, your settings also state your battery (inverter) can discharge 8 kW. However your system is only capability of exporting a total of 10 kW, in any combination of battery and PV.

the EMHASS forecast only makes sense to me if you have an inverter for the batteries and another for the pv … but with only one inverter with a common DC connection bus, the inverter is the bottleneck.

Deztak avatar Mar 09 '24 01:03 Deztak

Couldn't this issue be solved by a maximum power from grid settings AND a maximum power to grid setting?

davidusb-geek avatar Mar 10 '24 09:03 davidusb-geek

Couldn't this issue be solved by a maximum power from grid settings AND a maximum power to grid setting?

I don't that that work resolve the issue.

Power from grid could be upto 10 kW through the inverter to charge battery + what ever amount of household load an additional 5, 10, 15 kW. Typically the network limits single phase households to 15 kW (63 A) - 20 kW (80 A)

Power to grid would be a maximum of 10 kW (through inverter mix of battery + solar), but if household load is 2 kW then max to grid is 8 kW, if household load is 5 kW then max to grid is 5 kW, ...

I think within EMHASS DC coupled batteries sharing an inverter need to be calculated differently taking into account the constraint of only having one inverter.

purcell-lab avatar Mar 10 '24 09:03 purcell-lab

Couldn't this issue be solved by a maximum power from grid settings AND a maximum power to grid setting?

I did try this but, my inverter CAN charge the batteries with 10kW and still support about 5kW of house load before tripping the 63amp breaker. I have a calculator that goal seeks on 13kW total draw from the grid. I tried goal sealing on 14kW but have too many appliances that can draw over 1kW and I have too many breaker trips.

So the system was overcharging at higher prices and it seemed to be costing me more than the current issue as that energy could have cost nothing if the pv provided it.

I think the simple solution would be to have a ‘maximum power to grid’ along with the current ‘maximum power from grid’ rather than assuming both are the same limit. Acknowledging that you have a good mix of optional and required variables already, I don’t know if it should be an optional or required input. I am biased but, maybe it should be ‘required’?

I think I could do a work-around where:

if p_grid_forecast < 0 then: set max_from_grid = int(10000) else set max_from_grid = int(13000)

then of course I’d need to lookup the docs to see if I can include this in my optim rest command.

Deztak avatar Mar 10 '24 10:03 Deztak

On this topic, I also have another code that checks if I’m better of charging from the grid or just charging from Solar and having the house load come from the grid. Where: If p_pv > 13kW - p_load then Call script: set_charge_solar_only Else Call script: set_charge_solar_and_grid

… so I have actually achieved a total power exceeding 15kW but I had about 6kW of house load due to my massive aircon struggling with the heatwave conditions.

Deztak avatar Mar 10 '24 10:03 Deztak

if p_grid_forecast < 0 then: set max_from_grid = int(10000) else set max_from_grid = int(13000)

Ok this seems like a condition that should be implemented in the code to properly support this special configuration of the same inverter for both PV and battery. Do you agree @purcell-lab ?

Well I think that this is exactly waht you meant with this:

I think within EMHASS DC coupled batteries sharing an inverter need to be calculated differently taking into account the constraint of only having one inverter.

davidusb-geek avatar Mar 12 '24 12:03 davidusb-geek

Couldn't this issue be solved by a maximum power from grid settings AND a maximum power to grid setting?

As Deztalk said - not for this case, but for another case where you have a limit on the amount of power you can send back to the grid, which is lower than the amount you can pull, that would be a useful change.

philjohn avatar Mar 13 '24 18:03 philjohn

I agree, I just don’t know what would be involved as I don’t know the code. From reading the API info for my inverter, it has heaps of different operating modes such as limited energy return per day and proportion of energy generated per day. It even seems to have an ability to call on a backup generator, I guess for applications where you are off grid.

The output plots have to_grid and from_grid power separated, so logically speaking the code does breakup the grid power at some point … but is this done before or after the optimisation?

How much is involved in adding it to the config? Or should it be passed to EMHASS via the CURL or REST_command? Yes, not having it in the config file may make it harder, but it’s potentially a feature for more advanced users … so maybe adding it to the config would make the initial setup that little bit more complex for the average user and thus turn them away… I don’t know any of the answers to these questions, so it’s up to the best judgement of the devs and I’ll respect the decision they make as they would also have to deal with the consequence of other complaining about these potential issues.

I am very grateful for this, the sales team lead me to believe that SolarEdge does this optimisation for us and after trying for over 12 months to get something similar coded, I never broke even over a billing cycle. Currently I am about $85 in the black in the first billing cycle with EMHASS. Thankyou Devs.

Deztak avatar Mar 13 '24 20:03 Deztak

The output plots have to_grid and from_grid power separated, so logically speaking the code does breakup the grid power at some point … but is this done before or after the optimisation?

It is braked down before the optimization to convert the problem to a linear one.

How much is involved in adding it to the config? Or should it be passed to EMHASS via the CURL or REST_command? Yes, not having it in the config file may make it harder, but it’s potentially a feature for more advanced users … so maybe adding it to the config would make the initial setup that little bit more complex for the average user and thus turn them away… I don’t know any of the answers to these questions, so it’s up to the best judgement of the devs and I’ll respect the decision they make as they would also have to deal with the consequence of other complaining about these potential issues.

I've marked this as a necessary enhancement and we will add support for this in the future, as is not even a strange use case. I guess that in the future with more batteries people will have this configuration more often. We just need to add a boolean in the configuration to state that we have one single inverter for PV and batteries and based on this we need to add some conditions and constraints before the optimization.

I am very grateful for this, the sales team lead me to believe that SolarEdge does this optimisation for us and after trying for over 12 months to get something similar coded, I never broke even over a billing cycle. Currently I am about $85 in the black in the first billing cycle with EMHASS. Thankyou Devs.

Cheers, glad to hear!

davidusb-geek avatar Mar 14 '24 11:03 davidusb-geek

Thanks Davidusb.

With the grid in this part of NSW there is a 10kW inverter limit, anymore and we had to register it as a virtual power plant and other BS costs and delays would be added. So I hesitated ALOT as, I would have to decide on whether to have a 4kW inverter on my (then) 6.6kW array and a 6kW inverter on my 29.1kWh of batteries or put leave the old inverter and have a smaller inverter for the batteries.

None of it really worked out to my setup being any where near cost positive. Then they told me about the setup I eventually got and I went all-in … max number of the biggest batteries and added 5.7kW of panels to my Solar array.

I don’t know if they’ll be more common but, within the constraints put on me by AusGrid, I was either never getting batteries or I’d get the setup I now have.

I’m hoping that Amber will payout my bill credits in a way that I can “buy you a coffee” with that payout.

Deztak avatar Mar 14 '24 12:03 Deztak

I setup a hard limit in HA to only allow 10KW export, even when EMHASS instructs more. Its means EMHASS is wrong for periods, but revaluates every 5 mins, so in the wash, its OK.

Agree, grid limits would be an awesome variable to add. both inbound and outbound which includes loads, solar and battery.

kcoffau avatar Mar 19 '24 00:03 kcoffau

I setup a hard limit in HA to only allow 10KW export, even when EMHASS instructs more. Its means EMHASS is wrong for periods, but revaluates every 5 mins, so in the wash, its OK

this follows my experience too, but I noticed that I was losing more money due to less Solar being directly exported this way and I was better off with just tolerating not fully draining the battery while prices are high.

Deztak avatar Mar 19 '24 01:03 Deztak

I look forward to a DC-Coupled battery option, thanks everyone for looking into this and explaining exactly what I'm experiencing.

altonius avatar May 19 '24 07:05 altonius

I setup a hard limit in HA to only allow 10KW export, even when EMHASS instructs more. Its means EMHASS is wrong for periods, but revaluates every 5 mins, so in the wash, its OK.

Agree, grid limits would be an awesome variable to add. both inbound and outbound which includes loads, solar and battery.

These grid limits were already added recently. It is now possible to set these in the configuration file:

P_from_grid_max: 9000 # The maximum power that can be supplied by the utility grid in Watts
  P_to_grid_max: 9000 # The maximum power that can be supplied to the utility grid in Watts

davidusb-geek avatar May 19 '24 08:05 davidusb-geek

I will try to work very soon on adding support for hybrid inverters.

davidusb-geek avatar May 19 '24 08:05 davidusb-geek

I will try to work very soon on adding support for hybrid inverters.

Happy to help out with any testing when you're close to finishing this.

altonius avatar May 20 '24 01:05 altonius

I will try to work very soon on adding support for hybrid inverters.

Happy to help out with any testing when you're close to finishing this.

Hi, I've just implemented a first solution. The results seems coherent to me. I solved this by adding an additional constraint like this: $P_{hybrid}=P_{PV}+P{bat}^{pos}+P{bat}^{neg}\leq P_{hybrid}^{nominal}$ Where $P_{hybrid}^{nominal}$ is the nominal power of the hybrid inverter.

I will gladly use your help @altonius or anyone willing to provide help analyzing this. To test this you need to clone this branch https://github.com/davidusb-geek/emhass/tree/davidusb-geek/dev/hybrid_inverter_def_seq Then launch the script in: scripts\script_debug_optim.py

The input data: artificially added negative prod prices image image

The optimization results: image

The results table:

image image

Does these seem logical to you?

davidusb-geek avatar May 20 '24 12:05 davidusb-geek

Hi, I've just updated this implementation as it was certainly not complete when I posted those results in my previous post. Actually I realized that a PV curtailment variable is needed to implement this. I guess that this type of behavior is internally implemented in this type of inverter. Or that the PV system and the battery are well sized to avoid curtailement.

In any case to test this I have the same inputs that in my previous post but I have now multiplied the PV forecast by 2 to force the curtailment and to check the nominal power limitation of the hybrid inverter. I again considered a period of negative prod prices. The nominal power of the tested hybrid inverter is 5 kW.

Now the constraint looks like this: $P_{hybrid} = P_{PV} - P_{curtailment} + P_{bat}^{pos} + P_{bat}^{neg} \leq P_{hybrid}^{nominal}$

Here are my inputs: image image

And the main results: image

With the results table:

image

As we can see we now have P_hybrid_inverter and a P_PV_curtailment variables. The curtailment effectively activates on the period of negative prod prices and the P_hybrid_inverter never exceeds the nominal power of 5 kW even when the PV production is higher than 5 kW. The system converges to a solution where no power is injected to the grid during negative prod prices.

What do you think?

For reference this is what it looks like when setting inverter_is_hybrid = False. So this is to check the behavior of curtailment, I think that it is applied properly here and again no power is injected to the grid during negative prod prices.

image

davidusb-geek avatar May 20 '24 20:05 davidusb-geek

I'll wait for your feedback but I think that this solves this issue. One thing is that for now I'm using the model of the inverter defined in the configuration file to obtain the nominal power of the inverter, which is needed by the defined new constraints. This can be a problem for people using solar.forecast, soclast or passing their own PV forecast data. However the solution will be to properly define this entry in the configuration with at least an inverter model with at least similar nominal power as yours. I've developed a little app to help find the models in the database: https://emhass-pvlib-database.streamlit.app/

davidusb-geek avatar May 20 '24 20:05 davidusb-geek

Let me have a go at testing. I'm going to try running this locally (instead of trying to update the EMHASS add-on) and how I go back on a command line. The calculations look correct to me. I just need to get my head around how the calculation handles the different scenarios.

altonius avatar May 20 '24 21:05 altonius