Yes, I had that challenge trying to login to a command line on my home assistant box from work.
I found the Terminal & SSH server add-on, will allow you to login to a local command line, but I haven’t had much joy cutting and pasting in that terminal session.
Sounds like you may need to wait the two days for the sensor to fill up with meaningful data.
I’m a bit more concerned about “ERROR in retrieve_hass: The retrieved JSON is empty, check that correct day or variable names are passed”.
Sounds to me that this is the underlying reason why I get 500 errors when trying to import prices for the next day.
Yes the minimum days_to_retrieve is 2 and this is just how the HA API was designed, we can olny retrieve entire history days in the recorder.
Don’t worry too much about the empty json error, this just most probably means in your case that you don’t have enough data in your sensor.
SOLUTION:
After I created a port forwarding (5000 to 5000) and used the external HA-address (without https) to send the command from Node-Red to EMHASS, the dayahead optimization worked.
If relevant: I’m using the duckdns add-on with the built-in option to generate SSL certificates.
The Home Assistant Instance URL is still set to empty as settings the https URL did not work.
@davidusb Is it possible to set a minimum runtime and a timeframe for a deferrable load? I’d like to plan my domestic hot water heat pump with EMHASS but turning it on/off frequently isn’t healthy for it. It’d be better to set it for a minimum runtime of three hours for example. At the moment it might split 3 hours to 12hrs and 11hr.
Thanks
I have just replaced my instant gas hot water with a heat pump hot water system so am in the process of setting this up for control by EMHASS.
My heatpump is the Stiebel Electron WWK 302 which has an impressed current anode to protect the tank from corrosion. By default it has one mains lead which can be plugged into a 230V/ 10A socket. The until contains a factory installed battery to protect the anode during power cuts but it is recommended if you are going to switch the unit regularly that you either connect the anode circuit separately to a non switched circuit or replace the battery every three years. So I got my installer to connect a second 230V lead for the anode and control electronics to run continuously (drawing about 4 W) whilst the first circuit switches the compressor (drawing between 400W - 600W) when operating. The unit also has a SmartGrid signal line that can temporarily raise the set point from 61° C to 65° C. I have installed a Shelly 1 to switch this signal line, but haven’t yet integrated that into EMHASS.
I recommend you check your manual to see if you are able to protect your anode in this fashion.
Using EMHASS I have setup a 500 W deferrable load with a runtime of 3 hours to control the compressor circuit.
There is an EMHASS option you can set for continuous block operation, which I have considered but haven’t used for the compressor circuit:
set_def_constant: Define if we should set each deferrable load as a constant fixed value variable with just one startup for each optimization task.
I have only had it running this week but the results have been pretty reliable with most scheduling occurring during the midday solar soak window/ or my cheap buy signal from my energy provider.
I’ve been using emhass to control my water heater reliably for more than two years now. As long as I have a 30min time step the water heater will not switch on/off at high frequencies. When operating manually with only the thermostat it actually switch more often. However in my use case I don’t have a lot of variance in my costs inputs.
As Mark noted there is an option to force fixed values in the optimization. This will add more constraints to the linear programming optimization, so if you are close to the solver problem size limit this could not be a good idea. Otherwise the set_def_constant can be set on the add-on during runtime inside the shell command.
@davidusb
I’m using a 60 minutes step currently as I have pv production prices for one hours also (might consider changing that to 30 minutes and just doubling each value in the array).
The heatpump is only for hot water production and therefore does not need to run several times a day. I will check the option “set_def_constant”.
Regarding my question on timeframes: It would be cool if it’d be possible to set timeframes in which specific def loads are allowed to run. Not only to for example move this timeframe close to before it’s usually needed (like heating up the water in the afternoon so it’s hot when showering in the evening), but also as things like non-inverter (and therefore loud) heatpumps, especially for pools, might run in the mid of the night, disturbing neighbors and ourselfs. By saying “def_load_1 can only run between X and Y”, this issue could be addressed.
Also, a minimum time between each run of a def load would be nice, to for example stop the device from running from 22:00 to 23:00 and then again from like 01:00 to 02:00 and not the rest of the day.
@markpurcell
My electric anode is separated from the heat pumps electrical wiring and therefore runs 24/7, only consuming a few watts.
Unfortunately the water heat pump is dump. You can set a temperature and trigger it on/off, but no temperature increase based on a relay.
A second method uses the SolCast solar forecast service. Go to https://solcast.com/ and configure your system. You will need to set
method=solcastand basically use two parameterssolcast_rooftop_idandsolcast_api_keythat should be passed as parameters at runtime.
I can see how to set the two parameters at runtime, but how do I set method=solcast if I’m using emhass-addon? Do I put this into the configuration file?
If I am using the mpc optimisation and calling frequently will each optimisation result in another call to the SolCast API, noting that service has a limited number of calls allowed in each 24 hour period?
When providing the Solcast parameters at runtime the method will be automatically changed internally, so no need to do anything else.
Yes for each optimization call the Solcast API will be used. So I understand that this should be considered and adapt the optimization time steps accordingly
Thanks for the input above about the configuration. I’m still in the process of configuration.
I’m loading the solar forecast from Solcast manually using an own script and adding storing that in a csv file. I have two sites setup that need to be combined and I could only add one Solcast site id. I have confirmed that there is a CSV file in the /data folder with the forecast data.
There is also a scipt running that downloads the electricity prices from my electricity provider and stores that in a CSV file.
The configuration I have now is this:
optim_conf:
- load_cost_forecast_method: 'csv' # options are 'hp_hc_periods' for peak and non-peak hours contracts and 'csv' to load custom cost from CSV file
- list_hp_periods: # list of different tariff periods (only needed if load_cost_forecast_method='hp_hc_periods')
- period_hp_1:
- start: '02:54'
- end: '15:24'
- period_hp_2:
- start: '17:24'
- end: '20:24'
When I trigger a optimization I’m getting the following error in the docker console:
[2022-10-01 11:25:58,714] INFO in command_line: Setting up needed data
[2022-10-01 11:25:58,715] ERROR in app: Exception on /action/dayahead-optim [POST]
Traceback (most recent call last):
File "/usr/local/lib/python3.8/site-packages/flask/app.py", line 2525, in wsgi_app
response = self.full_dispatch_request()
File "/usr/local/lib/python3.8/site-packages/flask/app.py", line 1822, in full_dispatch_request
rv = self.handle_user_exception(e)
File "/usr/local/lib/python3.8/site-packages/flask/app.py", line 1820, in full_dispatch_request
rv = self.dispatch_request()
File "/usr/local/lib/python3.8/site-packages/flask/app.py", line 1796, in dispatch_request
return self.ensure_sync(self.view_functions[rule.endpoint])(**view_args)
File "src/emhass/web_server.py", line 134, in action_call
input_data_dict = set_input_data_dict(config_path, str(config_path.parent), costfun,
File "/usr/local/lib/python3.8/site-packages/emhass-0.3.19-py3.8.egg/emhass/command_line.py", line 42, in set_input_data_dict
retrieve_hass_conf, optim_conf, plant_conf = utils.get_yaml_parse(config_path, params=params)
File "/usr/local/lib/python3.8/site-packages/emhass-0.3.19-py3.8.egg/emhass/utils.py", line 239, in get_yaml_parse
optim_conf['list_hp_periods'] = dict((key,d[key]) for d in optim_conf['list_hp_periods'] for key in d)
KeyError: 'list_hp_periods'
In the /data folder I have these CSV files:
Some content from data_pv_power_forecast.csv
2022-10-02 06:00:00+02:00,0
2022-10-02 06:30:00+02:00,0
2022-10-02 07:00:00+02:00,0
2022-10-02 07:30:00+02:00,0.048100000000000004
2022-10-02 08:00:00+02:00,0.31379999999999997
2022-10-02 08:30:00+02:00,0.8818999999999999
2022-10-02 09:00:00+02:00,1.6953
2022-10-02 09:30:00+02:00,2.6088
2022-10-02 10:00:00+02:00,3.5980999999999996
Some content from data_prod_price_forecast.csv
2022-10-01 20:00:00+02:00,1.0199
2022-10-01 21:00:00+02:00,0.9753
2022-10-01 22:00:00+02:00,1.0066
2022-10-01 23:00:00+02:00,0.998
2022-10-02 00:00:00+02:00,0.9714
Based on the comment # list of different tariff periods (only needed if load_cost_forecast_method='hp_hc_periods') after list_hp_periods this config option should not be needed. I’ve tried commenting that line and still I get the KeyError about list_hp_periods.
I haven’t changed what’s in list_hp_periods, it’s still the same from the default config that came with the download of Emhass.
Why is it throwing an error on this key and how can I fix that?
Please open a new issue here: Issues · davidusb-geek/emhass · GitHub
And provide some information about your setup. Are you using the add-on or the standalone docker install?
I’ve created an issue on Github: Error: KeyError: 'list_hp_periods' when running optimization with CSV option · Issue #24 · davidusb-geek/emhass · GitHub
Emhass is running in a standalone docker container.
Port ‘5000’ is already in use by something else on the host
Could it be some other port 5000 is used by the electrical vehicle addon.
Thank you
Yes, this is somewhat painful. I’m struggling right now to implement ingress on the add-on and avoid this kind of issues. It is a work in progress but I’m stuck, help wanted here: Feature request: Access EMHASS web interface via ingress · Issue #22 · davidusb-geek/emhass · GitHub
Hi David, I hope this is an easy questions as I am just getting started with EMHASS. I am in the southern hemisphere so latitudes are negative. This seems to be causing issues with getting the weather forecast.
[2022-10-03 18:29:08,050] ERROR in app: Exception on /action/dayahead-optim [POST]
Traceback (most recent call last):
File "/usr/local/lib/python3.9/dist-packages/flask/app.py", line 2525, in wsgi_app
response = self.full_dispatch_request()
File "/usr/local/lib/python3.9/dist-packages/flask/app.py", line 1822, in full_dispatch_request
rv = self.handle_user_exception(e)
File "/usr/local/lib/python3.9/dist-packages/flask/app.py", line 1820, in full_dispatch_request
rv = self.dispatch_request()
File "/usr/local/lib/python3.9/dist-packages/flask/app.py", line 1796, in dispatch_request
return self.ensure_sync(self.view_functions[rule.endpoint])(**view_args)
File "/usr/local/lib/python3.9/dist-packages/emhass/web_server.py", line 134, in action_call
input_data_dict = set_input_data_dict(config_path, str(config_path.parent), costfun,
File "/usr/local/lib/python3.9/dist-packages/emhass/command_line.py", line 76, in set_input_data_dict
df_weather = fcst.get_weather_forecast(method=optim_conf['weather_forecast_method'])
File "/usr/local/lib/python3.9/dist-packages/emhass/forecast.py", line 181, in get_weather_forecast
raw_data.loc[count_row, col] = float(row.get_text())
ValueError: could not convert string to float: '-'
Config is
lat: -33.79843
lon: 151.224112
alt: 75
Hi, are you using the add-on or the docker standalone mode?
If using the add-on, the lat/lon values will retrieved directly from your core HA configuration. So check that.
Otherwise I’ve just tested that clearoutside can accept negative latitudes with no problem. So the iussue is somewhere else.
See:
https://clearoutside.com/forecast/-33/151?desktop=true
I am using the add-on. I removed the lat and lon from the emhass config and picked it up from HA and I am seeing the same issue. When I put more specific lat/lon in I see the following data which has “-” in some of the table cells. I assume this is a case of incomplete data from clearoutside. Maybe I need to shift to Solcast.
Odd, I’m southern hemisphere and the forecast module has not missed a beat, subscribers a little inaccurate so I have switch to solcast now.
You don’t need to put or add any additional parameters from those readily available to modify on the add-on configuration pane. Please share your complete configuration file (change the sensible/private information) and the automation commands that you’re using to trigger the optimization task.
I’m betting that this is the problem:
I removed the lat and lon from the emhass config and picked it up from HA and I am seeing the same issue.
You’re adding some parameters that don’t need to be there.
