Thanks for this great add-on, I am still exploring all the possibilities.
is it possible to change ‘battery_charge_power_max:’ together with the naive_mpc_optim.
Does battery charge power applies for grid and for PV?
The reason is that in our country we are taxed on the capacity of import. (so if I import 1h 4000w/h I pay more then 2h 2000w/h), but of course when the battery is charging from PV this has to be full power.
If I change to 30 minute intervals, do I need to change all the forecast data? (solcast, nordpool?)
You can set the max power from the grid and the max charge and max discharge for the battery. Three different parameters.
Not sure I understand your question but the forecast has to be aligned with the intervals. So if you switch form 1h to 30’ intervals you have to double the number of elements you pass.
Nope (to my best knowledge - it’s something not mentioned in the documentation so I guess it’s not possible). But maybe as a workaround you can set the power from the grid to 2000 w to achieve what you need as the charge from PV would be driven by the battery (dis)charge power limit.
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 -m or dpkg --print-architecture
If you are on armhf you should stick with the add-on version v0.4.2
Other thing that you can try is that as you are on supervised, then you can erase the old add-on images. First uninstall the EMHASS add-on.
Then do docker iamges
Then identify the EMHASS add-on images id’s and do docker rmi <image_id>
Then reinstall the add-on.
I adjusted this so that there is always some positive value in def_total_hours (at least one hour or pool pump operation). However, this happened again for a short period this morning and quickly recovered.
I didn’t have time to capture it. One thing I notice when this happens is the battery percentage is very low or zero, even though minimum stat or charge is 0.1.
After this drop there are a number of p_batt_forecasts with ridiculous values. The max should only be -3300W but there are three that are below -10,000W?
This raises the question, should I be using the Real battery percentage rather than the User percentage? Also, why would EMHASS produce p_batt_forecast values below -3300?
You can only have control on USOC. I noticed that there is no fixed delta between USOC and RSOC which is greater when the battery available charge (USOC) is close to zero and decreases as you get closer to 100%. RSOC accounts for an internal residual charge and is used to prevent battery deep discharge. So to me it is correct to work with USOC which is the level of charge available to be used.
Also in your case the same event affected RSOC as well as USOC so it seems something drained your battery (you may also crosscheck on the Sonnen portal) and I doubt that switching to RSOC would change anything, if this is the cause of this strange behaviour of EMHASS.
If you obtain any unexpected behavior like this it is highly possible that you are falling into an infeasible condition in that time slot. Use the new optimization status sensor to catch that situation and either fix that data input to EMHASS or set an automation to switch your battery control to some basic rules to avoid wild behaviors.
{"set_def_constant":[0, 0]} and {"set_def_constant":[1, 0]} both work.
But when I set {"set_def_constant":[0, 1]} or {"set_def_constant":[1, 1]} it is infeasible.
And I both need it to be 1.
-After testing the different settings, when setting to what first was working:[1, 0] now also gives infeasible.
-I changed time step to 60 and that solved the status to optimal. But now it plans the loads during the day while there is no sun and during peak hours. It also plans the loads at the same time which is not so good for the peak usage that has to be as low as possible here in Belgium.
I think what you say is correct.
If I change one of the two parameters to 0 or false, the forecast is in line with what is expected and runs during the night. If both are 1 or true it behaves not as expected.
After one day this changed and calculation for deferable 1 which was set to 1 is wrong again and wants to run during the day while it is very cloudy.
Since today, my EMHASS add-on is acting very weird. An optimization run takes more than two minutes, also the EMHASS web page takes minutes to load (the graphs load very slowly).
I’m using Node-red to compose the payload to be sent in the HTTP REST calls towards EMHASS.
Node-Red is also loading rather slowly.
Update on my own issue:
I migrated to another Hardware (HA Yellow) and the issue seems to be still present, so it’s not hardware related.
I noticed that the slowness of EMHASS is related to the fetching of data from HA through the API.
Getting 1 day of measurements of a sensor takes at least 46 seconds:
Loading of data from the pkl files also seems to take quite some time.
I’ll investigate further. Any feedbacks are very welcome
Sidenote: I noticed that EMHASS doesn’t have the flags “minimal_response”, “no_attributes”, “significant_changes_only” in the API GET call towards HA. Activating these flags would improve the speed of fetching the measurements from HA. Will further investigate and propose a PR for this.
These options don’t work well. You can test them but the data is not retrieved properly, at least when I tested them at the beginning of the code more than 2 years ago. Your problem is elsewhere. What is your timestep?
