That’s what I find so hard with the documentation. The documentation is clear, but the application doesn’t behave as the documentation states. If I run the command above, I get the below. Apparently, the application takes the --config argument as a path to the folder where a config.yaml is located.
> emhass --action 'dayahead-optim' --config './config_emhass.yaml' --costfun 'profit'
C:\Users\Ivar\Documents\Programmering\Python\emhass\emhassenv\Lib\site-packages\pvlib\forecast.py:20: UserWarning: The forecast module algorithms and features are highly experimental. The API may change, the functionality may be consolidated into an io module, or the module may be separated into its own package.
warnings.warn(
2023-06-13 11:07:35,394 - emhass.command_line - INFO - Setting up needed data
INFO:emhass.command_line:Setting up needed data
Traceback (most recent call last):
File "<frozen runpy>", line 198, in _run_module_as_main
File "<frozen runpy>", line 88, in _run_code
File "C:\Users\Ivar\Documents\Programmering\Python\emhass\emhassenv\Scripts\emhass.exe\__main__.py", line 7, in <module>
File "C:\Users\Ivar\Documents\Programmering\Python\emhass\emhassenv\Lib\site-packages\emhass\command_line.py", line 182, in main
input_data_dict = setUp(config_path, costfun, logger)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "C:\Users\Ivar\Documents\Programmering\Python\emhass\emhassenv\Lib\site-packages\emhass\command_line.py", line 30, in setUp
retrieve_hass_conf, optim_conf, plant_conf = get_yaml_parse(config_path)
^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "C:\Users\Ivar\Documents\Programmering\Python\emhass\emhassenv\Lib\site-packages\emhass\utils.py", line 70, in get_yaml_parse
with open(config_path + '/config.yaml', 'r') as file:
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
FileNotFoundError: [Errno 2] No such file or directory: './config_emhass.yaml/config.yaml'
After a HASS restart, I am seeing the following error when a run the predict and publish for the new ML Forcaster.
2023-06-14 08:45:33,181 - web_server - INFO - Setting up needed data
2023-06-14 08:45:33,182 - web_server - INFO - Retrieve hass get data method initiated...
2023-06-14 08:45:34,437 - web_server - INFO - >> Performing a machine learning forecast model predict...
2023-06-14 08:45:34,442 - web_server - ERROR - Exception on /action/forecast-model-predict [POST]
Traceback (most recent call last):
File "/usr/local/lib/python3.9/dist-packages/flask/app.py", line 2190, in wsgi_app
response = self.full_dispatch_request()
File "/usr/local/lib/python3.9/dist-packages/flask/app.py", line 1486, in full_dispatch_request
rv = self.handle_user_exception(e)
File "/usr/local/lib/python3.9/dist-packages/flask/app.py", line 1484, in full_dispatch_request
rv = self.dispatch_request()
File "/usr/local/lib/python3.9/dist-packages/flask/app.py", line 1469, 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 216, in action_call
df_pred = forecast_model_predict(input_data_dict, app.logger)
File "/usr/local/lib/python3.9/dist-packages/emhass/command_line.py", line 361, in forecast_model_predict
predictions = mlf.predict(data_last_window)
File "/usr/local/lib/python3.9/dist-packages/emhass/machine_learning_forecaster.py", line 210, in predict
predictions = self.forecaster.predict(steps=self.num_lags,
File "/usr/local/lib/python3.9/dist-packages/skforecast/ForecasterAutoreg/ForecasterAutoreg.py", line 637, in predict
check_predict_input(
File "/usr/local/lib/python3.9/dist-packages/skforecast/utils/utils.py", line 620, in check_predict_input
raise ValueError(
ValueError: `last_window` has missing values.
I have run the “fit” and “tune” steps. Any thoughts? I am running 0.3.13 of the add on.
Hi. I will need to test this but I see why the fit and tune methods worked and not the prediction. This is because there are NaN’s in your data probably caused by the HA restart and they are not treated for the prediction and the last window of data needed for that prediction. They are only treated for fit and tune. This should be fixed and a linear interpolation is a good solution for small windows of missing values. However if you have too many missing values it can lead to unexpected results. But I guess is the best we can do in that case.
It should be fixed if you wait for correct non missing data for at least the number of lags used by your predictor, ex. 48h, this value is shown in the logs when launching the fit and tune methods.
Could you please open an issue on github to fix this?
Just a question about the forecast, almost every day is spot on exacly correct forecast. But if there are som sky or rain it miss a lot like this.
The solarpanel that is configured in emhass is:
Phono_Solar_Technology_Co__Ltd__PS360MH_24_T, Dont understand where to find these list in the documentation for other 360W mono crystal panels. if we could try replacing with another panels see if results will be more close on all days?
Changing the panel model won’t change much.
Anyway the list of models can be found in the links here: https://emhass.readthedocs.io/en/latest/config.html#system-configuration-parameters
The errors with cloudy and/or rainy days are normal, all forecast are bounded to some error and confidence levels.
What you can do is test the other forecast methods, like Solcast or Solar.Forecast.
Another subject could be improving or adapting that forecast to your local conditions using your own measured data and some machine learning. But it is kind of a rabbit hole and an actual open research subject.
I’m trying to figure out what is causing this error… from time to time… I get an error in the MPC optimisation and messes up the SOC battery forecast. Any tips on how to look further?
my battery SOC iis 70%
Is it possible not to publish if there is a error in the MPC optimisation?
I have found it difficult to diagnose these transient errors as they are generally todo with a sensor state that then changes again quickly and every thing is good for the next run of MPC.
One thing i have found to help is using the rest_command integration as a replacement for the curl as when there is an error the expanded payload gets logged.
Do we know why sometimes (quite often) the initial SoC does not match what’s being fed in for the soc_init?
For example, just now, my optimsation ran at 15:30.
The value passed into the REST call was 0.85:
I think it is saying over this time slot (1530-1600) it wants to charge your battery p_batt_forecast -1263 W because you have excess solar and that at the end of the timeslot your SOC will be 90%.
I use soc_batt_forecast to drive my battery, I set my backup reserve to this value which forces my battery to charge upto this value.
I was wondering if the soc_batt_forecast is the final/ideal SOC in the timeslot… if this is the case how can I use this in the automation loop as the final soc_batt_forecast as its always changing every 5 minutes. can I put it in a global variable that doesn’t change and compare it in my loop automation to stop charging?
or do you use this as the target SOC in the time slot regardles of what value every 5 minute?
Depends on what is there best method to charge your battery. What sort of battery do you have and how do you control?
p_batt_forcast tells you exactly how many W to set your charging/ discharging
soc_batt_forecast tells you what you should aim for at the end of the time slot, so you can just set it and let the battery manage the charging rate. Once you have reached the require SOC it will equalise and stop charging.
See below for when it is above or below the actual level of charge.
Ive had EMHASS running for about a week, last night i change a setting and restarted EMHASS but it failed to restart, i put the setting back to how it was and still failin.
Cant find any info about this error related to EMHASS on the github or this forum post, does anyone know what might be going on?
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 289, in <module>
injection_dict = pickle.load(fid)
EOFError: Ran out of input
Hi. I’ve never seen this one before. But my guess is that you stopped EMHASS at the exact moment where it was trying to save something to that pickle file.
Go to the share folder in your HA instance and manually erase that injection_dict.pkl file and restart EMHASS, it should work after that.
