EMHASS: An Energy Management for Home Assistant

Share your Projects! Custom Integrations
1192

This is my dayahead template for PV:

"pv_power_forecast":{{([states('sensor.sonnenbatterie_84324_production_w')|int(0)] + 
state_attr('sensor.forecast_today', 'detailedForecast')|selectattr('period_start','gt',utcnow()) | map(attribute='pv_estimate')|map('multiply',2000)|map('int')|list +
state_attr('sensor.forecast_tomorrow', 'detailedForecast')|selectattr('period_start','gt',utcnow()) | map(attribute='pv_estimate')|map('multiply',2000)|map('int')|list)[:48]| tojson
}}

Still using older version of solcast integration, version 3.1.6.
This template produces this data:

"pv_power_forecast":[1880, 2075, 2552, 2940, 3250, 3502, 3641, 3749, 3788, 3797, 3740, 3613, 3394, 3147, 2819, 2427, 1908, 1404, 854, 315, 15, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 72, 482, 1010]

This data looks like this:

image
image2226Ɨ1069 96.2 KB

1193

Thanks, passing the values would be an option that overcomes the problem.
The fact is that retrieving the data from solar.forecast is not immediate at all and solcast has a really limited number of API calls.
For the moment Iā€™m using scrapping that seems to work quite well (even thought I canā€™t limit the kWp in this way).
I wanted to highlight something that seems not to work properly (for me at least).

1194

Yes I think its only 10 API calls per day or somehting like that?

I only use 5 calls myself.

image
image1034Ɨ437 45.2 KB

1195

image
image1012Ɨ1208 222 KB

Entire EMHASS config in Node-Red

4 Likes
1196

A work of artā€¦

1 Like
1197

Cant we use export limiting for the config?

I export limit the inverter past -0 that way its full controlled and i dont spend money to export.

Im with amber aswel so you would understand that.

And my work around is control the charging cycle and export limit then swap back to emhass if certain peramters are met

1199

Jeza
what kind of inverter do you have. Iā€™m still trying to get a solution to have my inverters switch off when fit is negative. SMA keeps saying it canā€™t be done. I argued with them that they swicth them off when the grid drops, why not when I decide?
Pat

1200

Can you share it? Thanks in advance

1202
1 Like
1203

This is an example of why emhass is a bit difficult to use. Itā€™s not very intuitive and the documentation is hard to read. Iā€™ve been strugglingā€¦
In the config, you can set SOCTarget, which is the target SOC that optimization algorithms use. But the weird thing is that itā€™s value is also used as the initial SOC when you call dayahead-optim.

dayahead-optim use the runtime parameter SOCTarget (yes, itā€™s different from the SOC runtime parameters for naive-mpc-optim). This value, when passed as a runtime parameter, overrides the SOCTarget value in the config. SOCTarget is used as both initial and final SOC for dayahead-optim. I have never understood this, but then I donā€™t understand the underlying algorithms usedā€¦

If you want to set the initial SOC to current SOC, which makes sense, and then set a different target SOC, you need to set up and use the naive-mpc-optim optimization. That one takes the runtime parameters soc_init and soc_final. Note, that naive-mpc-optim has a maximum horizon of 24 hours.

I have set up naive-mpc-optim to run every five minutes and I feel it gives me a better, and much more adaptive optimization than dayahead.

1204

There is lot of room for improvements, contributions are much welcomed!

I donā€™t see it as weird assumption. For proper balanced energy management for a complete day is quite common to suppose that SOCinit = SOCfinal = SOC target

If you want to further optimize intra-day and dinamically adjust your SOC init then yes, your analysis is correct, you should switch to MPC optimization.

1 Like
1205

I will try. Itā€™s hard to contribute to document something you donā€™t fully understandā€¦
How do I contribute? Can I just send you suggestions or can you do pull requests on readthedocs?

Optimization is a complex area, and lots of things appear counter intuitive for laymen such as myself.

I made the same mistake myself with dayahead-optim so I could relate to his question. A rather valid situation is that I know my battery is 20%, and I want it to be 50% by the same time tomorrow. Not being able to do that with dayahead was something I learned the hard way. :laughing:
If youā€™re interested in actually controlling something, I canā€™t see dayahead-optim to be of much use, as it only makes sense to run once a day and canā€™t adapt to changes. It would be great to understand more about the use of each call. For what purpose or scenario do they make sense?
Again, for us laymen to learn, not only how to, technically, make an optimization call, but also to understand when and why to use them.
This thread contains massive amounts of information, but is quite a mouthful to read throughā€¦

1206

Everything is on github, even the documentation which is automatically generated in readthedocs when the github repo is updated.

The workflow will be something like this: clone the repo, create a new git branch with your modifications, apply your contributions, push the changes to github using git and open a new pull request. In the meantime a discussion on the proposed changes is also a good idea.

Yes this is why it is important to continuously update and improve the documentation.

1 Like
1207

I think documentation should be developed at different levels. Certainly the main documentation done by David service a purpose in explaining the details of how the system works but what is missing is how to best implement for certain combinations of equipment.

The implementer is left to their own devices to develop a configuration that will work with their mix of battery, inverter, size of systems, deferrable load, and choice of forecasting services such as electricity supplier and solar production estimation.

So effort may be best spent documenting under different headings or combos. Probably only need three or four different document forks to cover eighty percent of the interested community.

Iā€™ve tried to document for my combination. I doubt itā€™s fully comprehensive, but provides a starting position and may have some of the secrets discovered along the way that will save other peopleā€™s time.

3 Likes
1208

I 100% agree with this,

The number 1 statement i want to make obvious for anyone who is starting out. Is do the exact steps his tells you to do without implimenting your own system. Then once its working, alter the values and check that it works.

This is how i did it and then implemented this threads experiance. To be honest it took me about a week to figure it out and about 30 hours to make mine work. ( it turns out raspberry pi 3 clocks out using emhass and doesnt process data very well haha)

Im an electrican who installs solar with no experiance in this field at all with programming. But if i made mine work then anyone with the hobiest enthusiasm can make it work.

Happy to share my system to anyone who needs help too.

1 Like
1209

Mark, perhaps a bit of a novice question but is there a way to push this on 60 minutes interval? Probably to get the most out of this that would require dividing the sum of the hourly and half hourly value by 2? and map those values. Struggling a bit though to manipulate the array, any tips?

1210

The updated SolCast integration included both 30 minute and Hourly forecasts.

Use the detailedhourly attribute:

1000005535
1000005535864Ɨ1920 196 KB

1 Like
1211

oopsā€¦ thanks!

1212

Just noticed that the web UI is more being delivered via ingress, well done.

I can now access when Iā€™m offsite and not connected to my LAN as I no longer need to connect to the port 5000 interface.

1000005543
1000005543864Ɨ1920 77.6 KB

3 Likes
1213

Yes! Help was found. Thanks to the great work of @siku2 on github.

1 Like