Yes it is possible. Just activate the battery and use just one deferrable load but with 0 total functioning hours. It will give you an optimized schedule for the battery.
Yes the latest results are always saved into a CSV, but it gets reset when the add-on restarts. I need to find a way to save those CSV to a persisting folder. Maybe using volumes in Docker, but I’m not sure how this fits with HA add-on and I don’t want to degrade the add-on security rating by granting a new write access. I’ll will looking into a solution for this but if you have an idea on how to do this please share.
Thank you for the clarification!
I’m new to HA and Docker in general (but I know python quite well). Is it possible to subtract the optimization data before a planed shutdown/reload/reboot and then reapply the results to EMHASS at start?
Ideal I don’t need to restart the add-on that often but right now I am porting my old home automation system to HA and I need to reload HA many times a day. If I rerun dayahead optim every time I reload HA I would get different results (battery optimization) every time. And if time is before 13:00 I don’t even have forcast price data available so I cant run optimization at all.
If I could subtract the data before reload and reapply in a controlled maner it would be enough for me during this intense development phase with many reloads a day.
Maybe make it possible to download the CSV (on demand) to a tmp folder inside config and then have EMHASS read it on demand?
//L
Hi, I just started playing around with EMHASS and managed to get it up and running and spitting out optimzations after having collected sensor data 2 days.
Results for the optimization also seem to make sense.
I have 1 problem though: My battery is not allowed to charge from the grid (local regulation). I can only use solar power to charge the battery (excess solar is going to the grid). EMHASS wants to charge the battery from the grid during night hours because it is cheaper (generally correct) but I cannot.
Can i set a constraint in EMHASS that grid charging is forbidden for the battery?
Thanks
Ok thanks.
So basically my mpc call should contain:?
prediction_horizon (number of prices / hour I have *2 (if having an interval of 30 mins)
load_cost_forecast
prod_price_forecast
I don’t have a battery yet so no soc
How often do you receive new prices? As you are running the opimization each 30 mins. I receive one for each hour.
What about solcast forecasts? At the moment I have solcast_rooftop_id and solcast_api_key at the end of the request. But due to the limited amount of api queries allowed in the free tier, I’m going to store this information in an attribute. Does this need to be included into the mpc query? Also the current load sensor?
Thanks!
Very interesting use case. For now this is not possible but I will add support for this as soon as I can. A new constraint need to be added to the LP formulation.
Thanks a lot. That would be great.
Grid charging seems to be generally forbidden for batteries in Germany. Same applies to discharging into the grid. German regulators don’t want home users to help with grid stability. Our batteries are basically just for delayed use of solar power (charge them with solar and use them for home use only). Stupid logic…
Interesting. I am in Germany and am not aware of grid Charging being prohibited? In fact, how would your energy company even know about it? We don’t have smart meters for the most part and how will the energy company know if it’s your car or your PV battery you are charging?
I am joining Tibber and grid Charging in the cheap hours is actually part of the reason for doing so…
1 Like
See here on current issues with Tesla Powerwall and grid charging in Germany.
The gist: it’s allowed in principle but the PW is not certified, so it’s not allowed. Tesla software just blocks it and doesn’t want to enable the option…
1 Like
When this is added can this be an option to not charge if not profitable based on the price calendar of the day to ex 0.5, if there is no profit to charge then it will not charge from the grid. And to disable this completly we can just set 0?
just a suggestion to add 2 features in 1.
Just released new versions. They will be available as soon as the images are pushed from github. One hour from now.
Added a new parameter set_nocharge_from_grid that let you avoid battery charging from the grid. Set it to true to activate that, its false by default.
1 Like
Thanks a lot! Seems to work perfectly. Since installing the updating and turning on the battery constraint, my log is repeating an error indefinitely:
Blockquote
raise AttributeError("module {!r} has no attribute "
AttributeError: module ‘numpy’ has no attribute ‘typeDict’
Traceback (most recent call last):
File “/usr/lib/python3.9/runpy.py”, line 197, in _run_module_as_main
return _run_code(code, main_globals, None,
File “/usr/lib/python3.9/runpy.py”, line 87, in _run_code
exec(code, run_globals)
File “/usr/local/lib/python3.9/dist-packages/emhass/web_server.py”, line 14, in
from emhass.command_line import set_input_data_dict
File “/usr/local/lib/python3.9/dist-packages/emhass/command_line.py”, line 13, in
from emhass.forecast import forecast
File “/usr/local/lib/python3.9/dist-packages/emhass/forecast.py”, line 10, in
import pvlib
File “/usr/local/lib/python3.9/dist-packages/pvlib/init.py”, line 3, in
from pvlib import ( # noqa: F401
File “/usr/local/lib/python3.9/dist-packages/pvlib/clearsky.py”, line 14, in
import h5py
File “/usr/lib/python3/dist-packages/h5py/init.py”, line 21, in
from . import _debian_h5py_serial as _h5py
File “/usr/lib/python3/dist-packages/h5py/_debian_h5py_serial/init.py”, line 46, in
from ._conv import register_converters as _register_converters
File “h5py/_debian_h5py_serial/_conv.pyx”, line 1, in init h5py._debian_h5py_serial._conv
File “h5py/_debian_h5py_serial/h5t.pyx”, line 293, in init h5py._debian_h5py_serial.h5t
File “/usr/local/lib/python3.9/dist-packages/numpy/init.py”, line 284, in getattr
raise AttributeError("module {!r} has no attribute "
AttributeError: module ‘numpy’ has no attribute ‘typeDict’
Blockquote
The optimization seems to work regardless. Any ideas?
Thanks!
Hi this is a current issue. Working on a fix to this.
Issues should be normally solved, images are being built.
1 Like
Hi!
I’m currently rebuilding my requests to EMHASS and am getting some 500 errors. I think the Add-On showed the request in log, but I can not see it in the docker version. Is there a way to get that? Unfortunately the Node-Red http request node does not provide that.
Thanks
You can check the container logs using:
docker logs --details <container-name-or-id>
From there if that doesn’t help then you can enter the container with:
docker exec -it <container-name-or-id> bash
And then try to launch an optimization with the emhass entry point like this:
emhass --action 'dayahead-optim' --config '/home/user/emhass/config_emhass.yaml' --costfun 'profit' --log2file 'true'
With the --log2file option the run will save all the logger messages to a log file that you can inspect.
I still haven’t really tried Emhass and am currently building my optimisations with HA automations, but definitely want to give EMHASS a try.
There is one thing I am trying to figure out though, and that is how to handle certain quirks or conditions on Devices.
For example…my PV battery has a “switch” in HA to enable or disable grid charging and it offers several options to force charge, either for a certain time or to a predefined SoC.
How would I plug all that into EMHASS?
Also, how would I plug in data from something like Tibber or Nordpool
EMHASS will give you the SOC profile that your battery should follow to optimize your energy bill. Now you need to take that information and define some automations to follow that optimal SOC profile as good as possible. In your case it is relatively easy if you already have what you said. So define an automation so that when the SOC profile from EMHASS is asking for a charge then you activate that “switch” or better give your battery the predefined SOC that you said you have as an option. On the other hand have an automation to allow your battery to discharge only when the SOC profile from EMHASS says so. You will need to fine tune these automations so that they adapt to your needs.
This example in the documentation allow you to do exactly that, pass the Nordpool data when calling for an optimization task: The forecast module — emhass 0.7.8 documentation
1 Like
Here is my automation to follow the SOC forecast:
alias: Battery SOC Forecast
description: ""
trigger:
- platform: state
entity_id:
- sensor.soc_batt_forecast
condition: []
action:
- service: number.set_value
data:
value: "{{states('sensor.soc_batt_forecast')|int(0)-5}}"
target:
entity_id: number.home_energy_gateway_backup_reserve
mode: single
Thanks!
I think I have now finally understood what Emhass actually is and does. I always thought it does the automations as well and didn’t grasp that it essentially just provides calculations I then have to use in my automations. Feeling very stupid right now …
With that new knowledge I can re-evaluate it’s usefulness.