EMHASS add-on: An energy management optimization add-on for Home Assistant OS and supervised

There is always the possibility to do things better, but you should keep into consideration that this project is not something commercial and has grown exponentially from the initial build. Actually David has done a terrific job in making this tool available to the community and developing it in what I can assume is his spare time, with the help of just a few great contributors and experienced users available to help and guide EMHASS newbies.
I can share my personal experience and I can tell you it took at least one month to me before I could implement something; I had to read a lot on the forum (here as well) and deeply study the documentation, which has improved a lot over the time.
If you think something should be changed or done differently David is always open to contribution (in the code, in the documentation, …) on the GitHub page of the project.

Coming to your question about the reason why you have to indicate the PV panels and the inverter in that funny way: because at the beginning the tool was making use of a DB developed by a 3rd group and that was the way the devices were recorded. Each string corresponds to a specific model that corresponds to specific electrical parameters.
Indicating your panel and inverter models is needed if you want to use the scrapping method, because it will convert the solar forecast into PV [W] production needed by EMHASS to predict and optimize your battery usage.
In addition to that, as the 3rd party DB was pretty outdated, David kindly implemented a newer and expanded database with more models; to make our life easier he also released a webapp where you can filter the results and look for your model or the one that is the closest to yours. (https://emhass-pvlib-database.streamlit.app/) [doc reference: https://emhass.readthedocs.io/en/latest/forecasts.html]

So do not give up, it’s not something you should expect to have up and running in minutes but not even days. If you have doubts post a message and somebody will try to help :wink:

2 Likes

I have to be honest. I didn’t expect a reply (and definitely not this fast).
And since I don’t tend to log on often, this would’ve been buried in my messages at some point.

I have looked at your references as well as the webapp. Unfortunately it seems like the manufacturer is not included in the DB, which isn’t too bad now that I got to understand this system a bit more though. I guess I will have to search for a panel with similar electrical characteristics.

I must admit that “at least to me” it would make more sense to skip this “extra step” and just ask the user the required parameters directly. Most people that implement this solution will presumably know their panel name and be able to look up the parameters in the datasheet.

However, I also have to admit that I neither have the knowledge, time nor Endurance to actively develop such a system from scratch. Likely, as you stated, in one’s free time.

So I understand that if I want to use this software, I will have to adapt to the method chosen by the developer(s). I could propose ideas to improve the usability and intuitiveness of the software. But this would require a redesign and reevaluation of the entire project. Which isn’t feasible just for one person who spend just a few hours with this project up until this point. I have to live with what other people deem “a good solution” even if that’s “not a good solution” to other people.

One can’t complain about something for free, which I did out of frustration primarily driven by tiredness (quite late in my Timezone) which still isn’t an excuse, obviously.

I have the habit of implementing solutions in under a day with all my HA related projects. Which worked decently great up until now. This however will likely require reading every single word of the doc (multiple times) to extrapolate the meaning of certain configuration options.

I don’t particularly like this process as it reminds me of (Desktop vs Terminal). The Terminal is more powerful but requires n^10 times more understanding than an intuitive GUI, which takes seconds to do 60-80% the Terminal can.

Usually at this point i would readjust my needs and settle with an overpriced premade solution. But since not a single automation solution exists that ties in greatly with HA or costs 6 figures, this is the best solution.
It will require much more time though than initially anticipated. And considering the “inaccurate” quality of irradiance forecasts with low-frequency updates in “free tiers” the providers grant us, this whole efficiency boost gained becomes marginal at best, presumably.

Will I still do it, absolutely, otherwise I wouldn’t have started HA anyway because the time sunken into it would have sufficed to toggle a light switch manually until I’m a thousand years old.

This seems like a curse, until it works, eventually (hopefully).

Thank you for your kind and fast reply.

Scrapper works quite well in any case, I think there is a limit on how frequently you can ask the website to elaborate the forecast for your location (from what I understood clearoutside.com generates the forecast for your location upon request, but the site won’t create a new one before one hour or so - I think to keep the burden low) so this is a good starting point to get some forecast coming in and seeing how EMHASS works. Some of us use solcast (but new users have a strict limit on the number of API calls) others (like me) forecast.solar.
Forecast.solar has a free tier that gives you today and tomorrow forecast which in my case is enough, but you have to heavily work with the jinja code to rearrange the forecast buckets, if you plan to run EMHASS computation more frequently than 1h.
If you do not want to do so forecast.solar also has a cheap (14€/year) personal tier with 30 minutes forecast and 3 days forecast but in any case I believe you’ll have to play with the API calls to download the data, format it and pass to EMHASS (I’m not sure this service is fully implemented in EMHASS and you can just pass the APIkey like it seems possible to do with solcast).

So to start with I suggest you try with the scrapper method and see how it goes.
You can try to just insert a random PV and inverter model and then refine it to match yours as much as possible (you see the results after performing a search in the webapp and you can compare the electrical parameters with your inverter).

Is it possible with the Add-On to implement the Deferrable load thermal model? I find no input in the Add-On Configuration page.
At the moment i am working with these shell-commands:
trigger_tibber_solcast: “curl -i -H ‘Content-Type: application/json’ -X POST -d ‘{"pv_power_forecast": {{ [states(‘sensor.inverter_power_kombiniert’)|int(0)]| list + (state_attr(‘sensor.solcast_pv_forecast_prognose_heute’, ‘detailedHourly’) | map(attribute=‘pv_estimate’) | map(‘multiply’, 1000) | map(‘round’, 0) | list + state_attr(‘sensor.solcast_pv_forecast_prognose_morgen’, ‘detailedHourly’) | map(attribute=‘pv_estimate’) | map(‘multiply’, 1000) | map(‘round’, 0) | list)[now().hour:][:23] }}, "load_cost_forecast":{{states(‘sensor.tibber_forecast’) }}}’ http://localhost:5000/action/dayahead-optim”

trigger_tibber_solcast_mpc_zwei: “curl -i -H ‘Content-Type: application/json’ -X POST -d ‘{"pv_power_forecast": {{ [states(‘sensor.inverter_power_kombiniert’)|int(0)]| list + (state_attr(‘sensor.solcast_pv_forecast_prognose_heute’, ‘detailedHourly’) | map(attribute=‘pv_estimate’) | map(‘multiply’, 1000) | map(‘round’, 0) | list + state_attr(‘sensor.solcast_pv_forecast_prognose_morgen’, ‘detailedHourly’) | map(attribute=‘pv_estimate’) | map(‘multiply’, 1000) | map(‘round’, 0) | list)[now().hour:][:23] }}, "load_cost_forecast":{{states(‘sensor.tibber_forecast’) }}, "alpha":1, "beta":0,"prediction_horizon":24, "soc_init":{{states(‘sensor.battery_state_of_capacity’)|float(0)/100 }},"soc_final":0.1}’ http://localhost:5000/action/naive-mpc-optim”
now i want to regulate my hot-water tank (200L with heating element). And next month i will get a heat pump, which i want to optimize :slight_smile:
Any suggestion how to do this with shell-command or the add-on configuration yaml?

The thermal model works well with the add on, but is not configurable via the GUI, you need to adapt the shell command.

I have started a GitHub discussion here if you would like to share you experiences: