Just to share thoughts maybe for improvements, I was thinking… is it needed in self-consumption mode to have a desired final SOC, especially in combination with the non discharge into grid option? Ideally if I’m operating my system in such mode I would like to keep my battery as charged as possible and I’m not really interested in profit; the SOC I reach at the end of the day, after the consumption is covered, would already maximise my goal. I’m asking that because when I set the non-discharge option, especially in summer time, it’s likely the outcome turns to be infeasible (I don’t want to set a high final SOC at the end of the day to avoid to charge from the grid - at a cost - as the next day I can already foresee I will charge from PV) . From what I see the battery/grid charge/dischare seems still to be reliable and it’s just the SOC curve that can’t keep a physical reasonable trend. Of course I could ignore any discharge phases and maybe adjust the desired final SOC as the day goes by but maybe there is a more elegant way to do that.
Thoughts?
Ive been playing with my calcs and i cant figure a way to trick or use export limiting.
Is there a way to add this vs dumping energy at a cost?
I have node red turn on and off my emhass and operate seperate until a large demand dimp is requested, so im missing the tru return cost fun,
I think if there was an export limiting calc incorperated it may work better but i might be the only one that wants it.
You can setup the companion battery automation to stop exporting and put your solar inverter into zero export mode.
I also like giving visibility to EMHASS of the full PV potential even when curtailing production, so EMHASS can switch on other loads and further maximise my self consumption.
Emhass don’t start anny more. After I made some changes in the config everything stoped working. Now I can’t get to run again. Tried to uninstall everything but it didn’t work. Any ideas. The emhass is installed as a addon.
What does the log says? What is the error message?
Go to the share folder in your HA instance and manually erase the injection_dict.pkl file and any other pickle (.pkl) file in that folder and restart EMHASS, it should work after that.
Yes that solved my problem. Thanks.
Can someone explain me how I should interpret the soc_opt in the table? Currently it’s not near my current soc state.
If you performed a day-ahead optimization then that soc_opt is the optimized trajectory for your battery state of charge. That information and the optimized battery power are used to control your real battery to follow as close as possible those optimal trajectories.
If your real current SOC and the optimized SOC trajectories are not near then there is a problem with your battery control. How are you controlling your battery?
Another issue that may lead to some strange behavior is unfeasibility of the optimization problem, check the logs to see if you are falling on this case.
I have a deferrable load, which I’d like to find a timeframe during night hours.
Usually, when creating the forcast, it is scheduled during day, when PV is active. But I want to have a second slot during night, when prices are low (but probably not lower than PV selling prices.
I now try it with creating a forcast in the morning and one in the evening (each for 14 hours at the moment).
Is this the correct approach?
No in this case the MPC. But let’s assume that at 15.00 hours the SOC_opt is 0.71 and 16.00 hours the SOC is 0.90. Would the SOC at 15.00 should be 0.71 or at 15.59?
It is not an easy question to answer. It depends on what suits well for your case and it depends on the size of that time step.
Remember that this is a discrete representation of something that is continuous in reality: the battery SOC.
If it were me then I would just use mean values and for your example I will try to reach a SOC of 0.71 at 15.30. I would test that and if it allows for a correct SOC following for a complete day then it is settled, otherwise try the “first” or “last” options and see how it goes.
How/Which strategy do you use to make sure the optimization process has ended before you publish data?
I see many of you just call the services in sequence in the same automation but in my case, as I expected, the publish service is executed too soon (11 s) and the optim has not ended yet.
So if I check the log the two activities get mixed (actually publish is performed before optim).
Should I just add a wait? Any better suggestion?
Thank you!
PS:
I’m using the REST command integration, not using Node-Red
I have another question about MPC, hope somebody can give me good advice.
I’m planning to run the optimization every hour. I have an optimization time step of 30 minutes. So for a 24h optimization I am passing 48 data points, as mentioned several times in the thread and in the documentation. Also the prediction horizon is progressively reduced (according to documentation) to keep the 24h prediction: so at 00:00 it is 48 datapoints, at 01:00 it is 46 and so on. So I’m passing the load_cost_forecast and prod_price_forecast datapoints accordingly (while the PV forecast is taken from scraping/solar.forecast).
Tonight I was testing and ran the optimization at 23:00, which implied a prediction of 1h with 2 datapoints. I got an error mentioning that the prediction_horizon should be at least 5 times the optimization time step (true, it’s also in the documentation).
The problem now is that I have to stay within the same day for the prediction (so in my example 1h), I can’t modify the optimization time step (and I’ve seen nobody in this thread doing this)… so I’m a bit out of options.
Can anybody tell me what I’m doing wrong and if I’ve not understood how this should work?
Thank you!
Is there a reason you need to stay within the same day. I’m running MPC and often roll over between one day and the next with my forecasts.
Which forecasts are you injecting into MPC and can you roll them over into the next day? Even if you just copies the values from he current day as a proxy for the next day.
My understanding you have to (or should) cover one day comes from the EMHASS optimisations section of the documentation, where it’s used in combination with the dayahead optim (then from previous messages I understood some of us are using MPC alone, for its flexibility that allows continuous fine tuning), and then from the the MPC section below, where it is explained the horizon is progressively reduced to keep the one-day optimisation notion.
That was also making sense in my head as if I define the final Soc I need to know when I want to reach it (especially for profit) otherwise I would keep postponing it and then I may find myself running the optim at midday and requiring to reach 20% SOC at the same time of the following (maybe sunny) day (which may probably turn to be infeasible or not desired).
How are you approaching this aspect and what is your strategy?
Maybe I totally misunderstood the sense of this.
Thanks!
PS
Values or forecasts are not a problem (I’m using either solar.forecast or scrapping - I’m also passing the cost datapoints according to the horizon), I need to understand what the right approach is and how many datapoints I have to pass depending on the time.
No I think that you understood this correctly. The sense of MPC that is described in the documentation is the receding horizon approach. For me this is the form of MPC that makes more sense here in our context and that is why I presented it like that in the documentation. In this form you think for complete days and the horizon is constantly shrinking for each MPC call. For this to work you will need call a first day-ahead optimization that will give you the optimal SOC trajectory for the day, then constantly call the MPC to try to meet that SOC trajectory providing SOC min and max for each MPC call. Also for each MPC call you will need to pass the remaining number of working hours for each deferrable load. At least this is how I would have implemented this and this is what I thought when I designed this. I myself I’m just using day-ahead call at my home because with almost constant pricing there is not much at risk.
Most people here are using this MPC functionality in a secondary manner. This is without receding horizon and just using the MPC as a small intra-day sliding window of optimizations. Which is ok I guess because either way you are constantly optimizing. However, like I said, the first option makes more sense to me for complete day optimizations. The first option needs more template working and tweaking though.
I was thinking… Is there maybe the possibility to get a shell/rest command answer (the one you would see in the terminal maybe) through a restful sensor (or similar)?
That would allow to perform a text search to understand if the optim was successful or not.
Or is there maybe another method? Access the addon-log? … ?
Yes this is in the makings. I’ll work on this in the next dev sessions.
Here is the github tag for this FR: Feature request: Add a published parameter with the status of latest optimization · Issue #109 · davidusb-geek/emhass · GitHub