OK, thanks for your reply.
I’m working with 30min timesteps, as my solcast PV forecast has that time resolution.
I noticed that every now and then, the speed issue is resolved automagically, but it only lasts for a few minutes. After these few minutes of joy, the time to load data from HA drastically increases again (a call to get 1 day measurements for 1 sensor takes up to 3 minutes…)
Result of my further investigation:
removing the homeassistant_v2.db SQLite database file solves the issue, but I then lose all of my history of course. Too bad, it is what it is.
Sorry for polluting this EMHASS topic; in the end, the issue was not at all related to EMHASS. It was rather EMHASS suffering from slows data retrieval from HASS.
Hi!
I have configured:
P_grid_max: 28000
Pd_max: 15600
Pc_max: 15600
eta_disch: 0.95
eta_ch: 0.95
Enom: 40960
SOCmin: 0.13
SOCmax: 1.0
SOCtarget: 0.13
What I can tell it keeps the promise to finish at 0.13. I have enough battery so my typical pattern is to charge to ~80-90% SOC and discharge to 13% SOC. Is there any way to force emhass to fully charge the batteries to 100% and even keep them at 100% for some time before discharge cycle begins? In todays case I would like to start charging at 03:00 with the full power and switch to discharging at 06:00.
Why would you like to buy electricity to reach 100% SOC if the charge EMHASS predicts and reaches is enough to cover your next day consumption?
You may find yourself buying that today and maybe in two days you are able to charge the batteries through PV so at no cost.
Because there is a spread between the price at 3am and 6am which generates a profit. (In my case 8 am - delta is ca 10c, or 40% including tax
I do exactly the same; take efficiency of 80% into account to avoid Emhass acting on too thin spreads.
Do you use mpc? If you feed the right tariff and apply correct efficiency to charge and discharge Emhass should do what you want it to do.
My PV is covered with snow. No real production at least few months. I’m also feeding in zereoish PV forecast.
I use MPC and feed in the tariffs. Don’t really know whats the correct efficency. I’ll experiment with something lower than default. Currently SOC forecast doesn’t hit 100%, if I lower the efficiency then the real SOC will probably exceed the forecast?
Mine was just an example, I meant “why buy today if you can buy tomorrow”. That said… have you tried to increase the target and minimum allowed SOC? If you max reach 80-90% you could try with increasing by 10-20% and see what happens. But also there are several things we do not know and may affect this approach (if you discharge to grid for example).
“why buy today if you can buy tomorrow” is really good question, but very hard to answer. If you average it out, it doesn’t matter if the charge/discarge cycle happens at the higher or lower SOC, daily energy consumption is still the same. Being at higer SOC gives at least one advantage, you have some spare power in case of power cut. If I increase the SOCtarget, then if the daily consumption happens to be higer I end up charging at some mid-day lower point, which is not optimal either. I don’t discharge to grid.
Then you could try to differentiate SOCmin and SOCtarget. Keep current SOCmin and increase SOCtarget, in my experience unless really needed (unexpected higher consumption) you would not go below target. You could change these and run a simulation. For example I use SOCmin = 0 and target = 0,2.
The real efficiencies of today’s power electronics are quite high, normally >95%.
But you could define a fake lower efficiency as a penalty factor for using your battery and then maybe try to orient its behavior as you desire. In the near future I will be adding real explicit penalty weights to account for battery degradation for example.
Why don’t upgrade to the latest version: bookworm
That’s the debian version I’m using for Python 3.11.
But anyhow as we said we are working with containers so this shouldn’t matter.
I have problems supporting armfh architectures for now, but armv7 are supported. Can we double check your architecture?
Please post the results of:uname -mordpkg --print-architecture
If you are on armhf you should stick with the add-on version v0.4.2
A little late reaction, but Christmas time is always quit busy!
As you suggested and as-well planned for the future by myself, I installed a fresh new Debian bookworm on my Raspberry Pi4. On top of that a fresh install of Home Assistant Supervised. After restoring my last HASS backup I could succesfully update EMHASS from 0.4.2 to 0.5.3 and everything is running very nicely.
For the record, here is my architecture:
Okay I’m totally lost.
Always get infeasible or results that are not logical. It only wants to run both loads I have at the same time at night. Or split the running times although I stated set_def_constant for both loads to 1. The results are more or less the same if I change max grid power to 9000.
hass_url: empty
long_lived_token: empty
costfun: profit
logging_level: INFO
optimization_time_step: 60
historic_days_to_retrieve: 5
method_ts_round: nearest
set_total_pv_sell: false
lp_solver: COIN_CMD
lp_solver_path: /usr/bin/cbc
set_nocharge_from_grid: false
set_nodischarge_to_grid: false
set_battery_dynamic: false
battery_dynamic_max: 0.9
battery_dynamic_min: -0.9
load_forecast_method: mlforecaster
sensor_power_photovoltaics: sensor.pv_power
sensor_power_load_no_var_loads: sensor.power_load_no_var_loads
number_of_deferrable_loads: 2
list_nominal_power_of_deferrable_loads:
- nominal_power_of_deferrable_loads: 1800
- nominal_power_of_deferrable_loads: 1000
list_operating_hours_of_each_deferrable_load:
- operating_hours_of_each_deferrable_load: 4
- operating_hours_of_each_deferrable_load: 4
list_peak_hours_periods_start_hours:
- peak_hours_periods_start_hours: "07:00"
- peak_hours_periods_start_hours: "07:00"
list_peak_hours_periods_end_hours:
- peak_hours_periods_end_hours: "22:00"
- peak_hours_periods_end_hours: "22:00"
list_treat_deferrable_load_as_semi_cont:
- treat_deferrable_load_as_semi_cont: true
- treat_deferrable_load_as_semi_cont: true
load_peak_hours_cost: 0.2162
load_offpeak_hours_cost: 0.1777
photovoltaic_production_sell_price: 0.0665
maximum_power_from_grid: 3500
list_pv_module_model:
- pv_module_model: LONGi_Green_Energy_Technology_Co___Ltd__LR6_72HBD_380M
- pv_module_model: LONGi_Green_Energy_Technology_Co___Ltd__LR6_72HBD_380M
list_pv_inverter_model:
- pv_inverter_model: OutBack_Power_Technologies___Inc___SBX5048_120_240__240V_
- pv_inverter_model: OutBack_Power_Technologies___Inc___SBX5048_120_240__240V_
list_surface_tilt:
- surface_tilt: 30
- surface_tilt: 30
list_surface_azimuth:
- surface_azimuth: 90
- surface_azimuth: 270
list_modules_per_string:
- modules_per_string: 9
- modules_per_string: 9
list_strings_per_inverter:
- strings_per_inverter: 1
- strings_per_inverter: 1
set_use_battery: false
battery_discharge_power_max: 1000
battery_charge_power_max: 1000
battery_discharge_efficiency: 0.95
battery_charge_efficiency: 0.95
battery_nominal_energy_capacity: 5000
battery_minimum_state_of_charge: 0.3
battery_maximum_state_of_charge: 0.9
battery_target_state_of_charge: 0.6
shell_command:
forecast_model_fit: "curl -i -H \"Content-Type:application/json\" -X POST -d '{}' http://localhost:5000/action/forecast-model-fit"
forecast_model_tune: "curl -i -H \"Content-Type:application/json\" -X POST -d '{}' http://localhost:5000/action/forecast-model-tune"
naive_mpc_optim: "curl -i -H \"Content-Type:application/json\" -X POST -d '{}' http://localhost:5000/action/naive-mpc-optim"
perfect_optim: "curl -i -H \"Content-Type:application/json\" -X POST -d '{\"set_def_constant\":[true, true]}' http://localhost:5000/action/perfect-optim"
dayahead_optim: "curl -i -H \"Content-Type:application/json\" -X POST -d '{\"set_def_constant\":[true, true]}' http://localhost:5000/action/dayahead-optim"
publish_data: "curl -i -H \"Content-Type:application/json\" -X POST -d '{}' http://localhost:5000/action/publish-data"
What shell commands do I have to call to make the basics work? I’m doubting everything now.
Hi, sorry for the late answer on this issue.
With the current formulation there seems to be a problem when setting both set_def_constant and treat_def_as_semi_cont to True.
I got into this and just found another analog formulation where these two options can live normally together.
Its a working in progress but it will be released as soon as possible: https://github.com/davidusb-geek/emhass/pull/142
I’ve noticed that my battery never quite makes it to 100% charge with EMHASS (maybe 95%) unless I intervene and top it up manually. It’s a 5 year old sonnen eco 9.43 10kWh (9kWh usable) LFP battery. It no longer drops below about 12% charge, unless something goes wrong as seen lately where it will drop from 12% to 0% suddenly (haven’t figured that one out yet).
I’ve got the following settings in the EMHASS configuration.
set_battery_dynamic: true
battery_dynamic_max: 0.9
battery_dynamic_min: -0.9
maximum_power_from_grid: 14490
set_use_battery: true
battery_discharge_power_max: 3300
battery_charge_power_max: 3300
battery_discharge_efficiency: 0.95
battery_charge_efficiency: 0.95
battery_nominal_energy_capacity: 9300
battery_minimum_state_of_charge: 0.1
battery_maximum_state_of_charge: 1
battery_target_state_of_charge: 0.1
What have other people set up for this scenario?
Should I change the charge and discharge efficiency to something lower?
Should min/max/target state of charge be something else?
Any thoughts appreciated.
I find I get to 100% most days if there is a good spread of prices between midday and sunset.
The last couple of days this hasn’t been a good spread so it hasn’t gone all the way to 100%. This is with 95% efficiency. I have also recently reduced efficiency to 70% to prevent exports at low price.
In NSW on Ausgrid there’s this two way tariff trial that presents a distinctive jump in export price so I don’t have that issue (yet).
I’ve just released a new version of the add-on v0.5.4: https://github.com/davidusb-geek/emhass-add-on/releases/tag/v0.5.4, it should be available soon.
This version solves these infeasibility issues with set_def_constant and treat_def_as_semi_cont.
In any case always check the optimization status, which is now a sensor on Home Assistant. If the status is infeasible one should not even bother to understand the numerical results because they can get pretty wild.
With AusGrid you definitely want to get to 100% each day.
How you do charge?
Do you follow SOC forecast or battery power forecast?
Maybe update your battery automation to put a bit more in the tank.
I have noticed I need to set maximum power to 16667 W, to get the battery power forecast to reach 15000 W, which I presume is a function of the efficiency ~ 0.9. I was thinking about raising this as an issue as I specify output power with Powerwall after losses, but EMHASS seems to want me to specify output power before losses. How do out batteries perform?
