I would ask that you make all parameters runtime enabled, if that is the way you are going…
Machine Learning and price forecasting.
I’m wondering how I could go about taking the two dimensional data from a stagger chart and use that to produce a series of price forecasts.
5 minute price intervals from NSW this afternoon:
No worries, that was actually what i was working on. 
5 Likes
This is the most amazing (shocking) EMHASS optimisation I have seen. 8 hours of price spike ($18/ kWh) ~ $2000 for the day.
Not my system, they have 120 kWh of battery and are going to use all, earlier in the week they earn’t $450 in 3 hours spike.
| index | P_PV | P_Load | P_deferrable0 | P_deferrable1 | P_grid_pos | P_grid_neg | P_grid | P_batt | SOC_opt | P_PV_curtailment | unit_load_cost | unit_prod_price | cost_profit | cost_fun_profit |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2024-11-29 08:30:00+11:00 | 1862 | 5250 | 0 | 0 | 6598 | 0 | 6598 | -3210 | 0.933 | 0 | 3.52 | 3.11 | -11.614 | -11.614 |
| 2024-11-29 09:00:00+11:00 | 5369 | 1619 | 0 | 0 | 13250 | 0 | 13250 | -17000 | 1.000 | 0 | 0.18 | 0.07 | -1.193 | -1.193 |
| 2024-11-29 09:30:00+11:00 | 6136 | 1734 | 0 | 0 | 0 | -20552 | -20552 | 16150 | 0.929 | 0 | 20.23 | 18.30 | 188.051 | 188.051 |
| 2024-11-29 10:00:00+11:00 | 6809 | 1861 | 0 | 0 | 0 | -21097 | -21097 | 16150 | 0.858 | 0 | 20.23 | 18.30 | 193.042 | 193.042 |
| 2024-11-29 10:30:00+11:00 | 7400 | 1642 | 0 | 0 | 0 | -21908 | -21908 | 16150 | 0.787 | 0 | 20.23 | 18.29 | 200.356 | 200.356 |
| 2024-11-29 11:00:00+11:00 | 7885 | 1339 | 0 | 0 | 0 | -22695 | -22695 | 16150 | 0.717 | 0 | 20.23 | 18.29 | 207.555 | 207.555 |
| 2024-11-29 11:30:00+11:00 | 8263 | 2781 | 0 | 0 | 0 | -21631 | -21631 | 16150 | 0.646 | 0 | 20.20 | 18.27 | 197.601 | 197.601 |
| 2024-11-29 12:00:00+11:00 | 8520 | 1698 | 0 | 0 | 0 | -22972 | -22972 | 16150 | 0.575 | 0 | 20.20 | 18.27 | 209.850 | 209.850 |
| 2024-11-29 12:30:00+11:00 | 8650 | 1592 | 0 | 0 | 0 | -23208 | -23208 | 16150 | 0.504 | 0 | 20.20 | 18.27 | 212.011 | 212.011 |
| 2024-11-29 13:00:00+11:00 | 8655 | 3690 | 0 | 0 | 5561 | 0 | 5561 | -10526 | 0.546 | 0 | 16.32 | 14.73 | -45.385 | -45.385 |
| 2024-11-29 13:30:00+11:00 | 8505 | 2427 | 0 | 0 | 0 | -22227 | -22227 | 16150 | 0.475 | 0 | 20.20 | 18.27 | 203.051 | 203.051 |
| 2024-11-29 14:00:00+11:00 | 8232 | 1588 | 0 | 0 | 0 | -22793 | -22793 | 16150 | 0.404 | 0 | 20.20 | 18.27 | 208.221 | 208.221 |
| 2024-11-29 14:30:00+11:00 | 7856 | 1512 | 0 | 0 | 0 | -22494 | -22494 | 16150 | 0.333 | 0 | 20.20 | 18.27 | 205.483 | 205.483 |
| 2024-11-29 15:00:00+11:00 | 7365 | 1638 | 0 | 0 | 0 | -21876 | -21876 | 16150 | 0.263 | 0 | 20.20 | 18.27 | 199.845 | 199.845 |
| 2024-11-29 15:30:00+11:00 | 6751 | 1779 | 0 | 0 | 0 | -21122 | -21122 | 16150 | 0.192 | 0 | 20.45 | 18.28 | 193.062 | 193.062 |
| 2024-11-29 16:00:00+11:00 | 6042 | 1669 | 0 | 0 | 0 | -20522 | -20522 | 16150 | 0.121 | 0 | 20.47 | 18.30 | 187.783 | 187.783 |
| 2024-11-29 16:30:00+11:00 | 5241 | 2000 | 0 | 0 | 0 | -19390 | -19390 | 16150 | 0.050 | 0 | 20.45 | 18.30 | 177.427 | 177.427 |
| 2024-11-29 17:00:00+11:00 | 4376 | 2797 | 0 | 0 | 0 | 0 | 0 | -1578 | 0.056 | 0 | 0.61 | 0.26 | -0.000 | -0.000 |
| 2024-11-29 17:30:00+11:00 | 3475 | 2273 | 0 | 0 | 0 | 0 | 0 | -1202 | 0.061 | 0 | 0.70 | 0.35 | -0.000 | -0.000 |
| 2024-11-29 18:00:00+11:00 | 2521 | 1777 | 0 | 0 | 0 | 0 | 0 | -744 | 0.064 | 0 | 0.76 | 0.41 | -0.000 | -0.000 |
| 2024-11-29 18:30:00+11:00 | 1548 | 2018 | 0 | 0 | 0 | 0 | 0 | 470 | 0.062 | 0 | 0.76 | 0.40 | -0.000 | -0.000 |
| 2024-11-29 19:00:00+11:00 | 625 | 1891 | 0 | 0 | 0 | 0 | 0 | 1266 | 0.056 | 0 | 0.67 | 0.32 | -0.000 | -0.000 |
| 2024-11-29 19:30:00+11:00 | -9 | 3872 | 0 | 0 | 3881 | 0 | 3881 | 0 | 0.056 | 0 | 0.48 | 0.15 | -0.931 | -0.931 |
| 2024-11-29 20:00:00+11:00 | -9 | 10209 | 0 | 0 | 25644 | 0 | 25644 | -15425 | 0.117 | 0 | 0.48 | 0.15 | -6.155 | -6.155 |
| 2024-11-29 20:30:00+11:00 | -9 | 7996 | 0 | 0 | 0 | 0 | 0 | 8005 | 0.082 | 0 | 0.69 | 0.34 | -0.000 | -0.000 |
| 2024-11-29 21:00:00+11:00 | -9 | 7352 | 0 | 0 | 0 | 0 | 0 | 7361 | 0.050 | 0 | 0.61 | 0.26 | -0.000 | -0.000 |
| 2024-11-29 21:30:00+11:00 | -9 | 4743 | 0 | 0 | 4752 | 0 | 4752 | 0 | 0.050 | 0 | 0.31 | 0.20 | -0.737 | -0.737 |
| 2024-11-29 22:00:00+11:00 | -9 | 1596 | 0 | 0 | 18605 | 0 | 18605 | -17000 | 0.117 | 0 | 0.26 | 0.15 | -2.419 | -2.419 |
| 2024-11-29 22:30:00+11:00 | -9 | 1434 | 0 | 0 | 18443 | 0 | 18443 | -17000 | 0.185 | 0 | 0.25 | 0.14 | -2.305 | -2.305 |
| 2024-11-29 23:00:00+11:00 | -9 | 4473 | 0 | 0 | 21482 | 0 | 21482 | -17000 | 0.252 | 0 | 0.25 | 0.13 | -2.685 | -2.685 |
| 2024-11-29 23:30:00+11:00 | -9 | 1788 | 0 | 0 | 18797 | 0 | 18797 | -17000 | 0.319 | 0 | 0.26 | 0.15 | -2.444 | -2.444 |
| 2024-11-30 00:00:00+11:00 | -9 | 1248 | 0 | 0 | 18257 | 0 | 18257 | -17000 | 0.386 | 0 | 0.25 | 0.14 | -2.282 | -2.282 |
| 2024-11-30 00:30:00+11:00 | -9 | 1286 | 0 | 0 | 18295 | 0 | 18295 | -17000 | 0.454 | 0 | 0.27 | 0.16 | -2.470 | -2.470 |
| 2024-11-30 01:00:00+11:00 | -9 | 1412 | 0 | 0 | 18421 | 0 | 18421 | -17000 | 0.521 | 0 | 0.28 | 0.17 | -2.579 | -2.579 |
| 2024-11-30 01:30:00+11:00 | -9 | 1748 | 0 | 0 | 3757 | 0 | 3757 | -2000 | 0.529 | 0 | 0.28 | 0.17 | -0.526 | -0.526 |
| 2024-11-30 02:00:00+11:00 | -9 | 1603 | 0 | 0 | 18612 | 0 | 18612 | -17000 | 0.596 | 0 | 0.26 | 0.15 | -2.420 | -2.420 |
| 2024-11-30 02:30:00+11:00 | -9 | 1193 | 0 | 0 | 18202 | 0 | 18202 | -17000 | 0.664 | 0 | 0.25 | 0.14 | -2.275 | -2.275 |
| 2024-11-30 03:00:00+11:00 | -9 | 1435 | 0 | 0 | 18444 | 0 | 18444 | -17000 | 0.731 | 0 | 0.25 | 0.14 | -2.306 | -2.306 |
| 2024-11-30 03:30:00+11:00 | -9 | 1838 | 0 | 0 | 18847 | 0 | 18847 | -17000 | 0.798 | 0 | 0.23 | 0.12 | -2.167 | -2.167 |
| 2024-11-30 04:00:00+11:00 | -9 | 1599 | 0 | 0 | 18608 | 0 | 18608 | -17000 | 0.865 | 0 | 0.22 | 0.11 | -2.047 | -2.047 |
| 2024-11-30 04:30:00+11:00 | -9 | 1613 | 0 | 0 | 18622 | 0 | 18622 | -17000 | 0.933 | 0 | 0.22 | 0.11 | -2.048 | -2.048 |
| 2024-11-30 05:00:00+11:00 | -9 | 1384 | 0 | 0 | 18393 | 0 | 18393 | -17000 | 1.000 | 0 | 0.23 | 0.12 | -2.115 | -2.115 |
1 Like
Hi guys! I have a working configuration of EMHASS mostly building on Robert’s documentation as I am using a Sonnen Batteri 10 performance. I don’t know anything about writing code so this is mostly chat GPT but here is what I have so far for creating the http request to send to emhass. https://bin.sibe.nu/oLUYCc.js
I’m wondering if you guys have any suggestions on how to improve?
I am not sure how to use the alpha and beta values correctly for example. And would love for emhass to more closely follow the actual consumption from the house. I don’t have any deferrable loads at the moment.
I don’t know how most NordPool customers are doing it but I can see a HACS for NordPool prices. Perhaps that will make it easy to download price forecast. @KasperEdw may have some ideas. @per.takman talks about it here.
I understand the alpha beta thing prioritises the ‘now’ or leading variable rather than ‘forecasts’ to make the system more reactive to actual conditions if you are running MLC often.
"alpha": 1,
"beta": 0
Will push the system to react to sudden changes within the frequency of your MPC execution. Of cause you need to add the current actual state to the front of each array of data and add 1 to the length of the horizon.
For those with Amber Electric, there are changes to EMHASS you will need to make after your transition to 5 minute billing.
Some details are available here: We’re getting ready for 5 minute settlement! · amberelectric/public-api · Discussion #226 · GitHub
In short the Amber API is now supplying 5 minute interval forecasts for the next 1-2 hours and 30 minute intervals forecasts for the remainder of the 24 hour period. (or 0330am which ever is earlier)
Almost all EMHASS instances configured with Amber will currently be assuming a 30 minute forecast default, which will continue to run after your account is transitioned to 5 minute settlement, but the forecasts will not be allocated to the correct intervals within EMHASS.
My concept going forward, which I’m still working through, is to use day ahead to manage the 30 minute forecasts (for the next 24 hours) and MPC to manage the 5 minute forecasts (for the next 1-2 hours).
https://emhass.readthedocs.io/en/latest/lpems.html#the-emhass-optimizations
Lots of things to unpack with this such as the use of publish_prefix to manage these different time horizons:
https://emhass.readthedocs.io/en/latest/intro.html#continual-publish-emhass-automation
The other factor is with a 5 minute settlement window, you need to receive the updated pricing (generally in the first 30 seconds), run the optimisation with new values (maybe upto a minute with HA Green - 288 x 5 minute intervals) and then switch you battery and other loads to perform their actions before the next 5 minute cycle starts again…
2 Likes
Mark when do these changes need to be made?
I received the message today that I had been switched over…
EMHASS was running, but was interpreting the new 5 minute API data as still being 30 minute resolution, so not a total failure, but sub-optimal. That’s the do nothing option.
I have now put a work around in place directly pulling only 30 minute forecasts from the Amber API, so EMHASS is back and running, but not optimal for 5 minutes, but very close. This is the do minimum and would recommend people set this up before they are ‘switched’ over. This isn’t too bad, because the now sensors; general and FeedIn do have the actual 5 minute data and I’m using 30 minute forecasts for the 24 hour horizon.
The long term solution will be the mixture of dayahead and MPC, but there are a number of implementation details with that; how do you send def_total_hours for devices, soc_finial and the like…
2 Likes
Still very cool. 
Ok so the first thing to do is replace Amber HA integration with native API calls to maintain access to 30 min data.
I can see I’ll have to set up a test instance of HA+EMHASS+Node_Red to experiment.
How have you recreated the price entities from the amber API to replace the amber HA integration. Are you creating exactly the same entities as the integration? I haven’t look at the amber api.
Oh! that’s what’s up! I did not know that you had to to that.
The NordPool prices are working fine I think.
1 Like
But I can´t figure out how to add the list with load forecast. Is there a api call I can make to EMHASS to get the forecast? so I can use that, add current load to the front and then send it back to EMHASS. Or how would I solve this? I have been using the Naive load forecast method.
You mean load_power_forecast? This data doesn’t have to be passed to EMHASS via the api as EMHASS will extract the last 2 days of power consumption from the HA Recorder database. Its the total home consumption less deferrable loads. This sensor is configured in EMHASS yaml file as sensor_power_load_no_var_loads.
Alternativly you can pass an array of data, either dummy {500, 500, 500,… the length of your horizon} just to get it working or you can construct an array and pass that.
Thats what I do, I average the power consumption over 30 mins and store that in an input text see 8.7 in my doco.
The reason I construct an array is becuase EMHASS accessing the recorder database seems to be unstable sometimes and it causes a bit of trouble.
The publish data-call will do what you need. I have designed my MPC to use that load-data published by the dayhead and replace the first value with the current power consumption.
I use an automation in HA, and this is a variable:
load_p_fc: >
{% set p_load_fc = state_attr('sensor.p_load_forecast', 'forecasts') | map(attribute='p_load_forecast') | map('int') | list %}
{% set p_load_now = [states('sensor.power_load_no_var_loads') | int(0) ] %}
{% set p_fill = namespace(load=[]) %}
{% for _ in range(48) %}
{% set p_fill.load = p_fill.load + [150] %}
{% endfor %}
{{ (p_load_now + p_load_fc[1:] + p_fill.load)[:prediction_horizon] }}
I replace the first value of the forecast with the current, instead of adding to the front and extending the horizon. That works for me, but now unsure if that’s correct.
I did some more work yesterday. I´m now relying more on api calls directly to the battery to get current information about production/consumption (every 2 seconds) and I run the MPC optim every 10 seconds. Is this overkill? probably… but self consumption works great now. I also used Roberts method of just adding a list of dummy values for load forecast and adding my current load in the front, this works great. Next I will try your (rudolf) method of fetching forecast from the dayahead to replace the dummy values.
Here is my code: wastebin
1 Like
Automatic Mode for Sonnen Batterie with EMHASS and Node-RED
Hi everyone,
I’m working on optimizing the usage of my Sonnen Batterie10, particularly its built-in self-consumption feature (automatic mode). My idea is to switch to automatic mode whenever EMHASS predicts that the load and battery discharge values align. This way, the battery can better follow consumption and potentially handle charging/discharging more efficiently than if I were to send manual charge values via the API.
What I’ve Done So Far
I’ve set everything up in Node-RED. Here’s an overview of my workflow:
- I use EMHASS to forecast load and battery discharge values.
- A Function Node in Node-RED calculates whether the system should switch to automatic mode. The logic is based on the condition:
If P_Load - P_PV = P_Batt, then switch to automatic mode.
This ensures that the battery matches the load dynamically.
3. If the condition is met, the Node-RED flow sets the system to automatic mode by sending a command to the Sonnen API.
4. Here’s the code for the Function Node, which you can check out: Function Node Code.
5. After processing, the result is passed through to a switch node that handles the actual charge/discharge logic.
My Goal
The main goal is to let the battery handle self-consumption intelligently and minimize manual interventions. I believe this could result in smoother charging/discharging behavior and better overall efficiency.
Questions
- Does this approach make sense? Are there any potential pitfalls I should be aware of?
- Are there ways to improve the efficiency of this setup, either in Node-RED or in the logic itself?
- Has anyone tried a similar approach with a Sonnen Batterie or other energy management systems? If so, how did it work out for you?
Looking forward to your thoughts, feedback, and suggestions!
Cheers,
Hello,
I’m not a Node-RED user (others can comment on that side) but I can share what I’m doing with my Sonnen battery.
I agree with your approach, I did the same, and I believe you are interested in maximizing self-consumption via EMHASS.
What I’m doing is to query the battery status every 5 seconds via restful sensor and based on this data and EMHASS prediction (MPC elaboration every 30 minutes, 24h shifting horizon, no deferrable loads at this moment) I operate to keep my battery in automatic mode as much as possible, for the same reasons you mentioned.
I never follow the discharge prediction; I only switch to manual mode (either charge or standby) when p_batt_forecast is negative/zero and p_grid is positive. I immediately switch back to automatic mode whenever I record a local grid push > 0, as I want to store PV energy as much as possible.
So I would say EMHASS is the backbone on which I fine tune my battery use, as I mainly want to charge the battery at night when I expect I’m not able to (fully) cover my consumption by just relying on PV production.
ok. I´m really looking to maximize profit, just thought that automatic mode would put less load on the battery/api compared to sending new values every 5 sec.
In your setup, why not let EMHASS handle all the logic? There is an option for Cost function to optimize for self-consuption.
Because I want to charge my battery as much as possible first and then sell to the grid. The self-consumption function still follows the boundary of the target end SOC. So maybe I’m selling to the grid after I’ve reached 70% of charge, and that’s enough for today, but if tomorrow is cloudy what I’m selling today I would need to fully/partially buy tomorrow. The fact I’m using a 24h rolling window mitigates this but I think I should make EMHASS process 48h to have a bullet proof prediction in such sense.
But if you are after profit then the considerations are completely different from mine I think.