I’m now up and running with my energy storage system. While preparing for it I discovered something that puzzled me that I hope you can shed some light on.
When I started using EMHASS the config method_ts_round was set to nearest. This resulted in that publication of my forecast data into Home Assistant occurred every half hour (X:30) instead of at the top of the hour. In Sweden the price changes every hour sharp, which means that I want to adjust charge/discharge rates exactly then and not halfway into the hour.
When I noticed this I tested both setting method_ts_round to last and first. I’ve been performing day ahead optimization 23:57 using next day data from Nordpool.
What I found was the following:
When method_ts_round = last I get a forecast starting right after midnight (as intended), but the published data into Home Assistant feed the forecast from next day already when the optimization is finished. This means that I would start the charge/discharge too early.
When method_ts_round = first I get a forecast starting from 23:00 on the same day I ran the optimization (one hour early). This means that price data is shifted one hour as well so that won’t work. I’ve solved this by shifting starting my optimization 00:00:01. I also have to shift publishing new data some seconds forward to allow for the optimization to finish.
My impression, from reading instructions and this forum, is that intended workflow is to perform optimization using future data a few minutes before midnight (or any other time for that matter) and that publishing data into Home Assistant should be triggered at the hour and not halfway into the hour.
What I’m doing seems like a patch solution and I’d like to understand what I’m doing wrong. Could you let me know the best way to achieve the intended behavior that I can optimize ahead of time but get published forecast data into Home Assistant that is synchronized with my production schedule?
I’ve done some further experimenting this evening and found a solution that seems more satisfying.
I’ve reverted back to method_ts_round = nearest and send prices starting from the next hour when performing optimization. I’ve adjusted the automation for publishing into HA as below:
I’ve noticed that it is hard to follow the SOC forecast when charging the batteries of my Ferroamp ESS system. Has anybody found an elegant solution to compensating for slower actual charge rate as the batteries approach 100%?
Firstly, I think your battery following the SOC forecast closely is really good. I don’t have the fine controls on my powerwall to achieve that level of control.
Before 0600 your SOC forecast is set at 100%, but your battery seems to stop at around 95% for at least a hour, so it might not be the slow charging at the top end, maybe something else stops at 95%.
Are you able to charge to 100% in Home Assistant without EMHASS?
Looking at your other multi hour steady state values there always seems to be around a 5% difference, maybe add 5% to your charging value?
Anyway as I said your charge/ discharge cycle matching the forecast is very impressive.
My first experiment with increasing the charge power by 5% relative to the p_batt_forecast resulted in a charge state of 89%. I had also reduced the configuration variable battery_charge_power_max to 7600 W to more accurately reflect what seems to be achievable.
This morning I did an experiment where I set the charge power to 3000 W to see if the power would go down as it approaches 100% SOC. I did not see this up to 96% although the SOC change rate appears go down.
I will experiment a bit further with increasing the charge power during the forecasted hours that we should be charging to see if this bring us closer to 100%. I guess another approach is to always charge as fast as possible when EMHASS suggest that charging is a good idea.
Please let me know if what I’m trying to achieve is simply unrealistic.
I installed Emhass a few days ago, but so far haven’t been able to really understand how it works. I hope I will be able to work out if this is the right project for me or not.
My mid- to long-term plan is to use a dynamic energy tariff (like Tibber) and then try to optimise my useage as well as possible.
For this I need the solar forecast, Tibber price forest, my PV battery “force charge from grid”, my (ordered but not yet delivered) heat pump “boost mode” for heating, cooling and hot water and of course my Tesla automated charging. This is a rather daunting project and I am still unsure whether this would best be handled with a set of Automations in HA, a separate management entity like EMHASS or possibly dedicated hardware.
My advice is start simple with one device at a time and build up an understanding in Home Assistant. Once you have a base level of functionality working then move into the complexity of EMHASS.
Thanks. I bookmarked your Thread and will take inspiration from there when I have made some progress on the basics.
My current Challenge:
I have an entity with the EPEX Prices for electricity for a 24h Timeframe. Sadly the Values are in a “list” (Hour 00-23) stuck in the “Attributes” section of that Entity. I am currently trying to find an elegant way of extracting that list, putting it in a “Min-Max-Med” helper and then using the “Min” as a trigger to grid-charge my PV Battery to SoC 100-“Solar Forecast Tomorrow”. The Grid-Charge and the SoC calculation seem to be functional, but the “extract and compute attributes” part is still a gordian knot.
If you search the forum for entso-e and nordpool you will find many examples where the attributes are “manipulated” into boolean sensor (cheapest hours, cheapest consecutive hours etc). Not sure which api you use for your epex info but perhaps you can use this to reverse engineer something for your use case.
I’m using EMHASS since several months and am optimizing the production of hot water in my heatpump which is working pretty good.
I receive the prices per kwh which I receive for energy I put back into the grid each day at 02:00 p.m. for the following 24 hrs.
Therefore, I’m running the day-ahead optimization at about 02:10 p.m. together with PV forecast data from solcast.
While the published prices do not change, the PV forecast does and therefore it is not exact at the moment.
How would I trigger the import of new PV forecast information without changing something on the prices? Unfortunately if I would import the prices for example at 04:00 p.m., the prices for the following day from 02:00 p.m. till 04:00 p.m. would be missing and therefore would mess up the optimzation.
Then something different:
I have several appliances which I could run using EMHASS: ACs, washing machine and so on.
While the washing machine or the dryer are not needed every day and therefore I’m not yet ready to integrate them, I would like the ACs to start if some condititons are met:
More PV energy produced then used while PV sales price is below X and there is a need to heat or cool the rooms (based on thermostats)
Price for grid energy below Y while there is a need to hear or cool
Price for grid energy below Z while more PV energy is produced then used and PV sales price is below Z and there is a need for heating / cooling
and so on
I could do most of those automations in node red but my question is if I could also do some of the optimization in EMHASS or at least on how it would not interfere with it (I guess I should add ACs to the sensor without variable loads then (as the water heatpump))
@davidusb was wondering how you are going with a more advanced approach to load forecasting? I have been looking at some similar projects and I came across GitHub - LBNL-ETA/DOPER: Distributed Optimal and Predictive Energy Resources . DOPER allows you to model EVs as batteries which means they support charging and discharging. This is a great forward looking feature given where we are going with Vehicle-to-home and Vehicle-to-grid. Would it be easy to add this capability to EMHASS. This involves:
time series input representing the EV load (ie driving around)
time series input representing when the EV is connected vs not connected.
output that indicated when and EV should be charged and at what power
Is this something that I can help add to EMHASS? I hope to get an EV (and charger) that supports V2G in the next 6 months or so.
Hi advanced a little bit but didn’t had the time to put anything into the production code. What I did is to test the quality of results with a dataset containing even more data. What I found is that it may be a challenge to fit those PyTorch models on systems with no cuda support. So that’s a problem that I need to solve, I need to switch to more simple models and for decent results.
That’s a very interesting module right there from LBNL. I think that you are right we should start looking to optimize V2G applications. I will take a deeper look at this and try to analyze how this may be integrated to EMHASS if this is a valuable option.
I’m moving from Home Assistant OS (and therefore from the Add-On) to Docker on Synology.
Therefore, also EMHASS will run in Docker in the future. Can I just take the current config file and put it in the mapped docker storage location or do I have to change anything?
Just on/off periods for now. What I will do in the near future is to add a simple model of a heat pump. I intend to use this article as the main reference: https://arxiv.org/pdf/2009.02349v2.pdf
More information will need to be fetch from HA, notably the outdoor temperature and the technical specifications of the heat pump and the household thermal isolation.
