You should be able to test the forecast.solar method after the current version update >> v0.2.23. Please confirm that it is now working as expected.
Hi David, I am building my own docker container for synology from github sources. But with the last commit on github I have still the same results with forecast.solar:
And maybe one suggestion - solar.forecast api is rate-limited for 1 IP for <10 gets per hour. Could you try to implement option for scraping data from forecast.solar HA integration to emhass - to avoid this rate limits (HA websocket {âtypeâ:âenergy/solar_forecastâ} )?
So for me this problem exists just when I upgrade the add-on, not when HASS restarts.
So the automation that is useful for me is finally this:
- alias: Relaunch EMHASS tasks after HASS restart
trigger:
- platform: state
entity_id: update.emhass_update
to: 'off'
for:
minutes: 10
action:
- service: shell_command.dayahead_optim
- service: notify.sms_free
data_template:
title: Updated EMHASS and relaunched optimization
message: The EMHASS add-on was updated and the optimization task was relaunched
Bummer!
I will look for this on the specific case of the standalone docker container. I didnât test it with the docker container presuming that my unittests were sufficient.
As for the number of API calls the easiest way will be to treat yourself the forecast.solar integration and build the list of values with templates, then pass them to emhass inside the shell command with the pv_power_forecast key.
1 Like
Hi David, thanks to help from you and Mark I have EMHASS running nicely. My pool is several months away from completion and my EV is in the shop for repair so I donât have many deferrable loads at the moment.
My question is about home load forecasting. I was wondering if you had considered more âexoticâ ways of generating the forecast. For example a federated learning approach that could see all those who use EMHASS leveraging a shared model that is trained locally. Here is an example recent paper explaining this approach.
I would be happy to run the central server if there is interest. Bit of a left field question!
1 Like
Hi. Yes this is very interesting and one of the main tasks to further improve EMHASS. Today we are only using a very naive persistance model. I begun some months ago with this subject and trained some machine learning models to try to predict my own load at home. You can check the results in this very thread some posts ago. I left this on a side while waiting to save more historical data, because at the time I realized that my recorder was set to purge every 30 days. My goal is to propose this load forecast based on machine learning as a new add-on or directly integrate it to EMHASS, but I fear the the docker will become too big. I basically benchmarked all the models in the Darts Python module which include some advanced deep learning models: LTSM, N-BEATS, etc.
Now the approach in the paper that you show is very interesting and useful to preserve data privacy. What I propose is to start trying to obtain some nice results based on the user own historical data, then we can try to improve the system with the federated approach proposed in the paper. But if you put together the server and the necessary architecture to deal with the federated approach then I will be more than happy to contribute to the project. As I said I think that we should start simple (with no so simple deep learning models) then scale up with the federated approach. What do you think?
2 Likes
anyone who have a guide on how to implement tibber prices?
I agree we should start with a model that is shipped in the add on, then perhaps support to train the model with local data. Then we can see if there is sufficient improvement to warrant the federated learning approach. Iâll do some further investigation into what the needs of the central server are.
Well, Iâm using Nordpools prices instead but the principle is the same.
First I made a template that take Nordpools prices for tomorrow and then adds the transmission fee(in my case 0.69kr)
electricity_consumption_price:
friendly_name: "Elkons.pris med avgift"
value_template: >-
{%- set data = state_attr('sensor.nordpool', 'raw_tomorrow') | map(attribute='value') | list %}
{%- set values = namespace(all=[]) %}
{% for i in range(data | length) %}
{%- set v = ((data[i] | float + 0.69) |round(4)) %}
{%- set values.all = values.all + [ v ] %}
{%- endfor %} {{ (values.all)[:24] }}
Then I use it like this when optimizing the data:
post_nordpool_forecast: "curl -i -H 'Content-Type: application/json' -X POST -d '{\"load_cost_forecast\":{{(
(states('sensor.electricity_production_price')))
}},\"prod_price_forecast\":{{(
(state_attr('sensor.nordpool', 'raw_tomorrow')|map(attribute='value')|list)[:24])}}}' http://localhost:5000/action/dayahead-optim"
Do note that Iâve copy pasted from otherâs in this thread so the work can not be credited to me 
Thank you. Now got the prices in. They do not match the right time but gues that they will do when I optimize 23:57
1 Like
Finaly got everything up and running.
I want to make an automatin that charges my home battery from the grid if there is profitt to be made by doing so. Also I do not want it to be charging to much if there is a good way with solar production the next day or hours before solar kicks in. Any suggestions on how this can be configured?
If there is no higher prices the next hours when battery charging have been done i do not want to Charge from the grid.
Also my hot water heater can run when power is cheapest if not solar is present. But I gues this works right out of the box?
The optimised schedule should set the correct values in sensors for you to do this.
You then need to have some automatics to turn on your hot water and charge your battery.
Which battery do you have? Is it in Home Assistant? Do you have some comments to start charging.
Here is my plan for today you can see when my devices including my battery are scheduled to be switched by Home Assistant.
1 Like
I can send mqtt to the inverter to turn on off charging or change the minimum soc.
What sensor to you look for when doing this?
You have a few choices.
There is a battery SOC forecast sensor;
And a potential automation
Or a battery power forecast sensor;
With potential automation:
alias: p_batt automation
description: ""
trigger:
- platform: numeric_state
entity_id: sensor.p_batt_forecast
below: -4500
- platform: numeric_state
entity_id: sensor.p_batt_forecast
above: -4500
below: 4000
- platform: numeric_state
entity_id: sensor.p_batt_forecast
above: 4000
condition: []
action:
- choose:
- conditions:
- condition: numeric_state
entity_id: sensor.p_batt_forecast
below: -4500
sequence:
- service: select.select_option
data:
option: Backup
target:
entity_id: select.home_energy_gateway_operation_mode
- service: notify.mobile_app_pixel_6
data:
title: p_batt alert {{states('sensor.p_batt_forecast')}} - mode:backup
message: Price:{{states('sensor.amber_general_price')}} $/kWh
- conditions:
- condition: numeric_state
entity_id: sensor.p_batt_forecast
above: 4000
enabled: true
sequence:
- service: select.select_option
data:
option: Self-Powered
target:
entity_id: select.home_energy_gateway_operation_mode
- service: notify.mobile_app_pixel_6
data:
title: >-
p_batt alert {{states('sensor.p_batt_forecast')}} - consider
mode:autonomous
message: Price:{{states('sensor.amber_general_price')}} $/kWh
default:
- service: select.select_option
data:
option: Self-Powered
target:
entity_id: select.home_energy_gateway_operation_mode
- service: notify.mobile_app_pixel_6
data:
title: >-
p_batt alert {{states('sensor.p_batt_forecast')}} -
mode:self_consumption
message: Price:{{states('sensor.amber_general_price')}} $/kWh
mode: single
1 Like
Ok. Will analyze the data from a time forward and see if it work as expected. But when summer is coming then i do not need to charge battery from grid. Will this understand this and not charge from the grid if it is not profit to be made?
Think i saw this earlier when there was nothing to save by charging battery from grid that in the forcast it still wanted to charge the battery from grid based on forcast of soc and usage.
Also when forcast soc is 90 or 50 do you send soc 100 and soc 0 to be consumption from battery to the inverters?
Kind of hard to know how all of this works without testing this hard.
My pricing doesnât vary much today (normally I get about 40¢ variation) so there is no point in charging from the grid.
The EMHASS plan doesnât want to charge from the grid. It keeps my battery around 50% SOC until the evening peak and then discharges. Normally if the evening peak was large it would charge during the day.
It depends on which battery you have and what commands are available.
With the Powerwall2 I can set Backup reserve, if I set 100% then it will charge from grid, if I set reserve to 0% it doesnât export, just allows consumption.
The Time Based Control automations will export from the battery to the grid during peak windows.
index P_PV P_Load P_deferrable0 P_grid_pos P_grid_neg P_grid P_batt SOC_opt unit_load_cost unit_prod_price cost_profit cost_fun_selfcons
2022-11-30 00:00:00+01:00 -1.500000 2301.460674 0.0 2461.9441 0.0 2461.9441 -158.98343 0.608631 3.896 2.773 -9.591734 -9.591734
2022-11-30 01:00:00+01:00 -1.500000 2108.367688 2000.0 4900.0000 0.0 4900.0000 -790.13231 0.651523 3.780 2.680 -18.522000 -18.522000
2022-11-30 02:00:00+01:00 -1.500000 1799.433428 2000.0 4900.0000 0.0 4900.0000 -1099.06660 0.711187 3.737 2.646 -18.311300 -18.311300
2022-11-30 03:00:00+01:00 -1.500000 1775.278409 2000.0 4900.0000 0.0 4900.0000 -1123.22160 0.772162 3.694 2.611 -18.100600 -18.100600
2022-11-30 04:00:00+01:00 -1.500000 1632.909348 2000.0 4900.0000 0.0 4900.0000 -1265.59070 0.840865 3.776 2.677 -18.502400 -18.502400
2022-11-30 05:00:00+01:00 -1.500000 1809.178771 2000.0 4900.0000 0.0 4900.0000 -1089.32120 0.900000 3.826 2.717 -18.747400 -18.747400
2022-11-30 06:00:00+01:00 -1.500000 3660.277620 0.0 3661.7776 0.0 3661.7776 0.00000 0.900000 4.060 2.824 -14.866817 -14.866817
2022-11-30 07:00:00+01:00 -1.500000 3952.965812 0.0 3954.4658 0.0 3954.4658 0.00000 0.900000 5.325 3.836 -21.057530 -21.057530
2022-11-30 08:00:00+01:00 -1.500000 2344.498567 0.0 2345.9986 0.0 2345.9986 0.00000 0.900000 5.373 3.874 -12.605050 -12.605050
2022-11-30 09:00:00+01:00 -1.500000 1928.548105 0.0 0.0000 0.0 0.0000 1930.04810 0.783907 6.331 4.641 -0.000000 -0.000000
2022-11-30 10:00:00+01:00 60.234411 1733.764706 0.0 0.0000 0.0 0.0000 1673.53030 0.683243 6.465 4.748 -0.000000 -0.000000
2022-11-30 11:00:00+01:00 210.359176 1757.254438 0.0 1546.8953 0.0 1546.8953 0.00000 0.683243 5.361 3.865 -8.292906 -8.292906
2022-11-30 12:00:00+01:00 370.751610 2598.750716 0.0 2227.9991 0.0 2227.9991 0.00000 0.683243 5.325 3.836 -11.864095 -11.864095
2022-11-30 13:00:00+01:00 359.764121 1845.220670 0.0 4360.8159 0.0 4360.8159 -2875.35930 0.839334 5.266 3.789 -22.964057 -22.964057
2022-11-30 14:00:00+01:00 163.852435 1720.623229 0.0 1556.7708 0.0 1556.7708 0.00000 0.839334 5.326 3.837 -8.291361 -8.291361
2022-11-30 15:00:00+01:00 15.988537 1647.753501 0.0 1631.7650 0.0 1631.7650 0.00000 0.839334 5.311 3.825 -8.666304 -8.666304
2022-11-30 16:00:00+01:00 -1.500000 2564.144886 0.0 0.0000 0.0 0.0000 2565.64490 0.685010 6.505 4.780 -0.000000 -0.000000
2022-11-30 17:00:00+01:00 -1.500000 2561.808140 0.0 0.0000 0.0 0.0000 2563.30810 0.530826 6.832 5.042 -0.000000 -0.000000
2022-11-30 18:00:00+01:00 -1.500000 2313.297753 0.0 0.0000 0.0 0.0000 2314.79780 0.391590 6.728 4.958 -0.000000 -0.000000
2022-11-30 19:00:00+01:00 -1.500000 1521.182609 0.0 0.0000 0.0 0.0000 1522.68260 0.300000 6.339 4.647 -0.000000 -0.000000
2022-11-30 20:00:00+01:00 -1.500000 2844.982659 0.0 4305.2288 0.0 4305.2288 -1458.74610 0.379189 5.255 3.780 -22.623977 -22.623977
2022-11-30 21:00:00+01:00 -1.500000 3418.428977 0.0 4900.0000 0.0 4900.0000 -1480.07100 0.459536 4.672 3.313 -22.892800 -22.892800
2022-11-30 22:00:00+01:00 -1.500000 3679.946779 0.0 4900.0000 0.0 4900.0000 -1218.55320 0.525686 4.359 3.063 -21.359100 -21.359100
2022-11-30 23:00:00+01:00 -1.500000 3529.554572 0.0 4900.0000 0.0 4900.0000 -1368.94540 0.600000 3.860 2.744 -18.914000 -18.914000
Not sure if I have configured it wrong then. If you se forcast soc is when not pv input. I do not understnad that.
Your configuration and results looks good.
Your maximum PV is 370W which is very small. What size is your solar system?
Based off your inputs it is fully charging your battery to 90% SOC by 05:00, as your overnight grid charges are cheap 3.6. It has correctly calculated this as the cheapest time to charge as it correctly identifies using your PV later saves you buying from the grid at 5.3. Are you able to automate your battery charging at this time via home assistant?
When your max PV generation (12:00) 370 W, your household load is 2598W your grid price is 5.3 so it doesnât use battery and imports the balance 2227 W from grid. Saving the battery for later. You get greater savings using the PV immediately rather than storing in your battery at this time.
At the evening price spike (17:00) your grid price is the maximum 6.8 so it maximises your battery consumption 2563W so you donât need to import anything from grid.
It is scheduling your 2000W load to run at the cheapest time of the day overnight.
Those all look like the optimal schedule for your household. You would get maximum benefits if you were about to increase your solar production to over 2500W.
Yes. It is winter time now so not much production. Also lot of rain. 10kw setup.
Mabey you want to share the dashboard?
Yes I can automate everything against inverter and battery. 