Not sure if this is the problem you are facing, but I have had similar issues many times. So far I have been able to track them all to bugs I’ve created when coding template sensors for load data, time of the day for deferrables to run, history stats for the deferrables etc. It is surprisingly easy to get failures with time and date variables when the month changes.
Hi,
Can someone explain me why EMHASS don’t try to charge the battery to 100%? The production price is low.
See the picture:
{
"prod_price_forecast": {{
((state_attr('sensor.nordpool_30min', 'prices') | list)) | tojson
}},
"load_cost_forecast": {{
((state_attr('sensor.nordpool_30min', 'prices') | list)) | tojson
}},
"pv_power_forecast": {{
([states('sensor.solaredge_ac_power')|int(0)] +
state_attr('sensor.solcast_pv_forecast_forecast_today', 'detailedHourly')|selectattr('period_start','gt',utcnow()) | map(attribute='pv_estimate')|map('multiply',1000)|map('int')|list +
state_attr('sensor.solcast_pv_forecast_forecast_tomorrow', 'detailedHourly')|selectattr('period_start','gt',utcnow()) | map(attribute='pv_estimate')|map('multiply',1000)|map('int')|list
)| tojson
}},
"prediction_horizon": {{
min(48, ((state_attr('sensor.nordpool_30min', 'prices') | list)) | tojson|length)
}},
"def_start_timestep":[0,0,0],
"def_end_timestep":[0,0,0],
"alpha": 0,
"beta": 1,
"num_def_loads": 3,
"weight_battery_charge": 0.0,
"weight_battery_discharge": 0.03,
"def_total_hours": [{{states('input_number.def_total_hours_ww')}},{{states('input_number.def_total_hours_ev')}},{{states('input_number.def_total_hours_wwdisinfection')}}],
"treat_def_as_semi_cont": [1,0,0],
"set_def_constant": [0,0,0],
"soc_init": {{ (states('sensor.sofarcontroller_battery_soc')|int(0))/100 }}
}
load_forecast_method: naive
battery_discharge_power_max: 3400
battery_charge_power_max: 3400
battery_discharge_efficiency: 1
battery_charge_efficiency: 1
battery_minimum_state_of_charge: 0.1
battery_maximum_state_of_charge: 1
battery_target_state_of_charge: 0.1
Can you share the full table and not just the rows where the production price is low?
Might be your hours with high prices (where it is beneficial to sell) are in sufficient to shed the battery - your target is a 10% SoC.
Based in the Netherlands. Same as you I believe. So the price between 11 and 17 is almost the same price, but emhass isn’t charging with full power.
Forgot to answer this earlier. I created a plugin with pysolarmanv5. This can conmunica with wifi Modbus signals. Do you also use deye inverter?
Yes, I am in NL. My emhass is not working today because i upgraded HA. Expect it to be back online tomorrow when the sensor history is back . If it would work though I would see a charge to 100% between the hours you indicate followed by 3 hours of discharge between 8 an 11pm. My inverter supports 8kva, i have however capped the battery at 50% to preserve it’s life. I also discharge to max 20% for the same reason. That leaves roughly 12kwh battery capacity to optimise. Charge and discharge efficiency are at 92% each to account for roundtrip losses.
The question is what other constraints you put up. Eg. Grid capacity. You instruct your system to end the plan period at a SoC of 10%. Emhass will optimize for that. If your inverter or grid connection in general is constrained then it simply may be there is no need to charge to 100%.
Already saw your config elsewhere. Your battery is 15kwh right, max discharge 3.4kva, suggests you need 5 profitable hours to sell in order for emhass to “see” the need to charge the battery in full. Yesterday, at the time of your post those hours were probably not in scope yet but as from 23.00 they should be. What’s the prediction now?
Can you share your full output table?
I also have the same, can it be a HA 2024.05 issue?
Just wait 48 hours.
There is probably a glitch in your sensor data following the upgrade process. I have this every time I upgrade HA which is why I stopped doing the minor versions.
Next question, when I click in the UI on the ML Fit, i get this error
2024-05-06 12:51:56,830 - web_server - ERROR - The retrieved JSON is empty, A sensor:sensor.power_load_no_var_loads may have 0 days of history or passed sensor may not be correct
But my sensor has a different name in the config. Does it have to be the exact same name?
I used to have the same problem. Every time I rebooted HA I would have to run dayahead calculations instead of MPC for two days.
Then I deleted the recorder database and implemented an include statement to restricted the data going into the recorder database.
Now it doesn’t happen any longer.
I can confirm this, since using the include statement in the recorder settings I no longer have issues with missing data on sensors.
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.