Yep, aware of the fix. But deleting my recorder database is a bit complicated. I am on mariadb which includes the databases for various other addons. How did you prevent the loss of long term statistics including your energy dashboard?
I didn’t prevent the loss of data. I had to start afresh.
Another idea is to establish a second instance of Home Assistant just for EMHASS. This separates the energy control complexities from all the other home automation functions.
A workaround is to manually inject your load forecasts for the next 24 hours in the payload, that will override it pulling the data it can’t process from the recorder.
You can just have an average value, day 24 * [1.2] and it will get your EMHASS back up and running.
1 Like
Thanks! That sounds good, assume the syntax is somewhere on this forum? (Was not aware load could also be input as a shell command)
Syntax is the same as other fields.
https://emhass.readthedocs.io/en/latest/forecasts.html#passing-your-own-forecast-data
"prod_price_forecast": {{
([states('sensor.amber_feed_in_price')|float(0)] +
(state_attr('sensor.amber_feed_in_forecast', 'forecasts')|map(attribute='per_kwh')|list))
| tojson
}},
"load_cost_forecast": {{
([states('sensor.amber_general_price')|float(0)] +
state_attr('sensor.amber_general_forecast', 'forecasts') |map(attribute='per_kwh')|list)
| tojson
}},
"pv_power_forecast": {{
([states('sensor.solaredge_nopowerlimit')|int(0)] +
state_attr('sensor.solcast_pv_forecast_forecast_today', 'detailedForecast')|selectattr('period_start','gt',utcnow()) | map(attribute='pv_estimate')|map('multiply',1000)|map('int')|list +
state_attr('sensor.solcast_pv_forecast_forecast_tomorrow', 'detailedForecast')|selectattr('period_start','gt',utcnow()) | map(attribute='pv_estimate')|map('multiply',1000)|map('int')|list
)| tojson
}},
"load_power_forecast": {{ 48 * [1.2]}}
Result type: string
"prod_price_forecast": [0.15, 0.18, 0.17, 0.18, 0.17, 0.1, 0.27, 0.22, 0.15, 0.09, 0.05, 0.07, 0.06, 0.05, 0.05, 0.04, 0.04, 0.04, 0.09, 0.09, 0.16, 0.15, 0.23, 0.28, 0.09, 0.04, 0.04, 0.05, 0.05, 0.04, 0.04, 0.04, 0.04, 0.04, 0.04, 0.05, 0.06, 0.05, 0.09, 0.21, 0.26, 0.27, 0.26, 0.38, 0.39, 0.49, 0.39, 0.38, 0.3],
"load_cost_forecast": [0.38, 0.41, 0.41, 0.42, 0.26, 0.19, 0.38, 0.33, 0.24, 0.18, 0.14, 0.15, 0.15, 0.14, 0.14, 0.13, 0.13, 0.13, 0.18, 0.18, 0.26, 0.25, 0.34, 0.38, 0.18, 0.13, 0.13, 0.14, 0.13, 0.12, 0.12, 0.12, 0.12, 0.12, 0.12, 0.13, 0.14, 0.13, 0.17, 0.31, 0.36, 0.37, 0.5, 0.64, 0.64, 0.76, 0.64, 0.64, 0.55],
"pv_power_forecast": [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 19, 339, 1163, 2285, 3386, 4481, 5441, 6245, 6923, 7390, 7743, 7905, 7918, 7811, 7465, 6895, 6093, 5119, 3979, 2706, 1245, 288, 9, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0],
"load_power_forecast": [1.2, 1.2, 1.2, 1.2, 1.2, 1.2, 1.2, 1.2, 1.2, 1.2, 1.2, 1.2, 1.2, 1.2, 1.2, 1.2, 1.2, 1.2, 1.2, 1.2, 1.2, 1.2, 1.2, 1.2, 1.2, 1.2, 1.2, 1.2, 1.2, 1.2, 1.2, 1.2, 1.2, 1.2, 1.2, 1.2, 1.2, 1.2, 1.2, 1.2, 1.2, 1.2, 1.2, 1.2, 1.2, 1.2, 1.2, 1.2]
1 Like
Hey all
One question I have is if the Battery Power Forecast compensates so that it reaches the Battery SOC Forecast if it is worth manipulating the discharge or charge power.
I think if you manipulate with more effect if emhass itself compensates for the intended SOC goal. I have seen that the SOC when charging or discharging jumps up/down a lot if you want to reach the intended SOC as quickly as possible and vice versa. (I might be overthinking)
I run my .post_naive_mpc_shell every 5 minutes and also fifobuffer every 30 minutes
can you use this as a mpc call or only day-ahead?
Do I have to change the config settings to list, or can I keep using mpc? (or naive)
Yes this can be added to your MPC calls.
I confirm 48 hours wait. My copy of the EMHASS done this twice. Remedy is just to wait 48 hours, it recovers.
You can feed a set of interim load_forecast values so you don’t need to be offline for 48 hours.
@davidusb Do you want to put a folder in your github repo to store sample battery/inverter automation scripts so new users has someone to refer to rather than starting from scratch? I’m happy to contribute my Sungrow one.
I used to manipulate the charging power but it turned out to be overthinking it.
If you run mpc-optim frequently (I run it every minute) then I just charge/discharge at full power and when EMHASS decides its reached the desired SoC, it will set the grid_forecast/batt_forecast to 0 and stop the charging/discharging
So instead of discharging at rate of 2000w over 30 min, I discharge at 10,000w and EMHASS will stop the discharge after 6 min.
2 Likes
Your approach may work for discharging but it could cause issues when charging, among others when certain other heavy users are active. The beauty of emhass is that it operates within the constraints you set out.
my growatt inverter expects a % of max. I solve for this by using the emhass generated a discharge/charge in kw. My solution is to divide that over the max discharge to arrive at the percentage - rounded and floored at 5% (by conditioning minimum 400watt)
value: >-
{{((states('sensor.p_batt_forecast') | float(default="0") / 8000 * -100 ) |
round(0) | float(default=0))}}
I run MPC only once per hour. There is no need to run it more frequently with my tariff structure
1 Like
I have created helpers in HA to let me set all additional values like VAT, tax refund, transfer fee etc, then add/subtract these to both purchase and sale prices in the call to emhass optimization.
Something like this. Fetch all the inputs.
Create the nordpool list of prices for the next (up to) 24 hours.
Loop though the list and add the input values to the nordpool values in the list. This uses a rather weird namespace workaround that I don’t really understand, because Homeassistant doesn’t allow modifying list values otherwise… But it does the trick. The nordpool_sell and nordpool_buy lists are then sent to the optimization.
{%- set tax=states('input_number.elpris_skatt_per_kwh_ink_moms')|float %}
{%- set transfer_fee=states('input_number.elpris_vattenfall_overforingsavgift_per_kwh_inkl_moms')|float %}
{%- set extra_fee=states('input_number.elpris_tranas_paslag_per_kwh_ink_moms')|float %}
{%- set tax_return=states('input_number.elpris_skatteaterbaring_per_kwh')|float %}
{%- set extra_sales_fee=states('input_number.elpris_tranas_avdrag_per_kwh_ink_moms')|float %}
{%- set energy_compensation=states('input_number.elpris_vattenfall_energiersattning_per_kwh')|float %}
{%- if state_attr('sensor.nordpool_kwh_se3_sek_0_10_025','tomorrow_valid') == true %}
{%- set nordpool=((state_attr('sensor.nordpool_kwh_se3_sek_0_10_025', 'raw_today') | map(attribute='value') | list
+ state_attr('sensor.nordpool_kwh_se3_sek_0_10_025', 'raw_tomorrow') | map(attribute='value') | list)) [now().hour:][:24] %}
{%- else %}
{%- set nordpool=(state_attr('sensor.nordpool_kwh_se3_sek_0_10_025', 'raw_today')
| map(attribute='value') | list) [now().hour:][:24] %}
{%- endif %}
{%- set nordpool_sell = namespace(values=[]) %}
{%- set nordpool_buy = namespace(values=[]) %
{%- for i in nordpool %}
{%- set nordpool_sell.values=nordpool_sell.values+[((i+energy_compensation-extra_sales_fee)/100)|round(2)]%}
{%- set nordpool_buy.values=nordpool_buy.values+[((i+transfer_fee+extra_fee+tax-tax_return)/100)|round(2)]%}
{%- endfor %}
...
1 Like
Same thing today where emhass again chose to alternately charge at max and then discharge some, even though the energy price was level.
As you can see, the gross energy price (buy and sale) differs by almost nothing and is close to zero. Adding the additional charges and additions, the net price is 0.38 SEK buy and 0.15 SEK sell. Again, I have the battery charge and discharge weights set to 0.5 (SEK).
Still, without any changes to sales price, emhass thinks it should charge and discharge repeatedly for each time slot.
It doesn’t make the least sense to me. Considering I buy at 0.38 SEK, sell at 0.15, and also have a 0.50 SEK this behavior is not the least economical. There’s apparently something wrong with optimization and I suspect the battery charge/discharge weights to be at fault, but I don’t understand the code well enough to know.
I’ve added an issue to github.
What is the status of the “Emhass optimization status” sensor?
Can you share the charge/discharge efficiency you applied and the code for the price add-on? Any other restrictions you included?
Hi, yes of course. Sample automation are very welcome to help people setting this up. Probably some place in the documentation along with the other current examples is a good option to place these.
1 Like
Something else is driving EMHASS to make these optimisations. I have requested additional information from you in the GitHub issue to provide a full picture for debug purposes.
I must be blind but I don’t see where the other current examples are.
There are some examples here for Amber, Nordpool, Solcast forecasts: https://emhass.readthedocs.io/en/latest/forecasts.html#example-using-solcast-forecast-amber-prices
And also here for some example configurations: https://emhass.readthedocs.io/en/latest/study_case.html