For everyone is using solcast, the new HA beta breaks it…
Got a little further now with a graph that is published anyway. However, still having problems in the log. however, it could be that the sensor doesn’t have two days of history, but at the same time I’m doubtful if my shellscripts are ok.
dayahead_optim: "curl -i -H \"Content-Type:application/json\" -X POST -d '{}' http://localhost:5000/action/dayahead-optim"
publish_data: "curl -i -H \"Content-Type:application/json\" -X POST -d '{}' http://localhost:5000/action/publish-data"
trigger_nordpool_forecast: 'curl -i -H "Content-Type: application/json" -X POST -d ''{
"load_cost_forecast":{{((state_attr("sensor.nordpool_kwh_se3_sek_3_10_025", "raw_today") | map(attribute="value") | list + state_attr("sensor.nordpool_kwh_se3_sek_3_10_025", "raw_tomorrow") | map(attribute="value") | list))[now().hour:][:24] }},
"prod_price_forecast":{{((state_attr("sensor.nordpool_kwh_se3_sek_2_10_0", "raw_today") | map(attribute="value") | list + state_attr("sensor.nordpool_kwh_se3_sek_2_10_0", "raw_tomorrow") | map(attribute="value") | list))[now().hour:][:24]}}
}'' http://localhost:5000/action/dayahead-optim'
ml_forecast_fit: 'curl -i -H "Content-Type:application/json" -X POST -d ''{"num_lags": 24}'' http://localhost:5000/action/forecast-model-fit'
ml_forecast_tune: 'curl -i -H "Content-Type:application/json" -X POST -d ''{}'' http://localhost:5000/action/forecast-model-tune'ice_forecast":{{((state_attr("sensor.nordpool_kwh_se3_sek_2_10_0", "raw_today") | map(attribute="value") | list + state_attr("sensor.nordpool_kwh_se3_sek_2_10_0", "raw_tomorrow") | map(attribute="value") | list))[now().hour:][:24]}}}'' http://localhost:5000/action/dayahead-optim'
s6-rc: info: service s6rc-oneshot-runner: starting
s6-rc: info: service s6rc-oneshot-runner successfully started
s6-rc: info: service fix-attrs: starting
s6-rc: info: service fix-attrs successfully started
s6-rc: info: service legacy-cont-init: starting
s6-rc: info: service legacy-cont-init successfully started
s6-rc: info: service legacy-services: starting
services-up: info: copying legacy longrun emhass (no readiness notification)
s6-rc: info: service legacy-services successfully started
2023-10-26 09:35:35,963 - web_server - INFO - Launching the emhass webserver at: http://0.0.0.0:5000
2023-10-26 09:35:35,963 - web_server - INFO - Home Assistant data fetch will be performed using url: http://supervisor/core/api
2023-10-26 09:35:35,963 - web_server - INFO - The data path is: /share
2023-10-26 09:35:35,964 - web_server - INFO - Using core emhass version: 0.5.1
waitress INFO Serving on http://0.0.0.0:5000
2023-10-26 09:37:57,069 - web_server - INFO - EMHASS server online, serving index.html...
2023-10-26 09:40:00,226 - web_server - INFO - Setting up needed data
2023-10-26 09:40:00,248 - web_server - INFO - >> Publishing data...
2023-10-26 09:40:00,248 - web_server - INFO - Publishing data to HASS instance
2023-10-26 09:40:00,248 - web_server - ERROR - File not found error, run an optimization task first.
2023-10-26 09:45:00,246 - web_server - INFO - Setting up needed data
2023-10-26 09:45:00,249 - web_server - INFO - >> Publishing data...
2023-10-26 09:45:00,249 - web_server - INFO - Publishing data to HASS instance
2023-10-26 09:45:00,249 - web_server - ERROR - File not found error, run an optimization task first.
2023-10-26 09:50:00,226 - web_server - INFO - Setting up needed data
2023-10-26 09:50:00,227 - web_server - INFO - >> Publishing data...
2023-10-26 09:50:00,227 - web_server - INFO - Publishing data to HASS instance
2023-10-26 09:50:00,227 - web_server - ERROR - File not found error, run an optimization task first.
2023-10-26 09:55:00,244 - web_server - INFO - Setting up needed data
2023-10-26 09:55:00,247 - web_server - INFO - >> Publishing data...
2023-10-26 09:55:00,248 - web_server - INFO - Publishing data to HASS instance
2023-10-26 09:55:00,248 - web_server - ERROR - File not found error, run an optimization task first.
2023-10-26 10:00:00,245 - web_server - INFO - Setting up needed data
2023-10-26 10:00:00,248 - web_server - INFO - >> Publishing data...
2023-10-26 10:00:00,248 - web_server - INFO - Publishing data to HASS instance
2023-10-26 10:00:00,248 - web_server - ERROR - File not found error, run an optimization task first.
But this would mean to loose the pre-trained model?! E.g. when the source data is discarded I can’t train it on that data. Isn’t there a way to migrate the model? This would mean we need to hold the data as long as possible in HA?
@davidusb figured out that prediction_horizon of 36 produces the same issue sometimes. I wonder if there is a gerneral recommendation for setting the prediction_horizon or does everybody needs to find his “sweet spot”? It’s not clear to me why the prediction_horizon sometimes produces the right result and on the other side the same setting gave me splitted loads (many 1 watt loads) instead of scheduling it the expected way (3h x 2000 watts).
Can you give a bit more detail?
Which part is actually broken?
Still don’t get it.
Running MPC with set_def_constant set to true gives me (moves the load in the last possible hours, nevermind which prediction_horizon was choosen):
prediction_horizon=12
prediction_horizon=24
When setting it to false it gave me the expected - and cost-efficient - result.
But may schedule loads multiple times when a higher
prediction_horizon was choosen.
Not sure if I’m doing something wrong when running a MPC every 15 min or if this is a bug in EMHASS?
curl -i -H "Content-Type: application/json" -X POST -d '{
"load_cost_forecast": [0.3341, 0.3259, 0.3259, 0.307, 0.307, 0.292, 0.292, 0.2822, 0.2822, 0.2895, 0.2895, 0.3118, 0.3118, 0.3141, 0.3141, 0.3277, 0.3277, 0.3286, 0.3286, 0.3052, 0.3052, 0.2804, 0.2804, 0.2766, 0.2766, 0.2728, 0.2728],
"prediction_horizon": 24,
"pv_power_forecast": [737, 782, 999, 1123, 1159, 717, 691, 665, 629, 592, 512, 512, 506, 386, 296, 173, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0],
"alpha": 0.75,
"beta": 0.25,
"num_def_loads": 2,
"def_total_hours": [
3,
0
],
"P_deferrable_nom": [
2750,
2000
],
"treat_def_as_semi_cont": [true, true],
"set_def_constant": [false, false] #<<<----- or set this to true
}' http://localhost:5000/action/naive-mpc-optim
EDIT: This is a example with prediction_horizon = 24 and in that case better pv forecast data, setting set_def_constant to false.
1 Like
Thanks, I applied your fix here and I’m back online:
2 Likes
It seems emhass has difficulties grasping the day light saving time which is reverting to wintertime in Europe this weekend:
return meth(self, *args, **kwargs)
File "/usr/local/lib/python3.9/dist-packages/pandas/core/arrays/datetimes.py", line 1043, in tz_localize
new_dates = tzconversion.tz_localize_to_utc(
File "pandas/_libs/tslibs/tzconversion.pyx", line 284, in pandas._libs.tslibs.tzconversion.tz_localize_to_utc
pytz.exceptions.AmbiguousTimeError: Cannot infer dst time from 2023-10-29 02:00:00, try using the 'ambiguous' argument
As from 3 am last night my emhass tripped, look in at the log its probably because 2am does not exist today as this is the moment when we change the time?
Will turn emhass off for the remainder of the day. Suspect Tomorrow this will be resolved but perhaps there is a solution for next year?
3 Likes
Same problem here. EMHASS stopped with similar errors.
Same problems here.
Possible to set timezone for emhass same as home assistant?
Yes this has been seen before, two times per year 
I just haven’t found an efficient way to prevent this. Open to suggestions if anyone have a solution
What about keeping EMHASS internal time calculations in one time zone, maybe UTC, and then converting to locale when displaying externally?
Though my emhass addon is working again all optimizations are one hour late. Anyone else experiencing the same? I think it’s because of the additional hour in the array with prices so hopefully back to normal tomorrow…
Hi, I like this project, but I can’t get it to work. I can’t save the configuration and don’t understand why.
Could you add your configuration yaml file instead of an image? Something like this:
hass_url: empty
long_lived_token: empty
costfun: profit
logging_level: DEBUG
optimization_time_step: 30
historic_days_to_retrieve: 2
method_ts_round: first
set_total_pv_sell: false
lp_solver: COIN_CMD
lp_solver_path: /usr/bin/cbc
set_nocharge_from_grid: false
set_nodischarge_to_grid: false
set_battery_dynamic: false
battery_dynamic_max: 0.9
battery_dynamic_min: -0.9
load_forecast_method: naive
sensor_power_photovoltaics: sensor.sonnenbatterie_84324_production_w
sensor_power_load_no_var_loads: sensor.house_power_consumption_less_deferrables
number_of_deferrable_loads: 2
list_nominal_power_of_deferrable_loads:
- nominal_power_of_deferrable_loads: 1300
- nominal_power_of_deferrable_loads: 7360
list_operating_hours_of_each_deferrable_load:
- operating_hours_of_each_deferrable_load: 2
- operating_hours_of_each_deferrable_load: 1
list_peak_hours_periods_start_hours:
- peak_hours_periods_start_hours: "10:00"
- peak_hours_periods_start_hours: "10:00"
list_peak_hours_periods_end_hours:
- peak_hours_periods_end_hours: "16:00"
- peak_hours_periods_end_hours: "16:00"
list_treat_deferrable_load_as_semi_cont:
- treat_deferrable_load_as_semi_cont: true
- treat_deferrable_load_as_semi_cont: false
load_peak_hours_cost: 0.1907
load_offpeak_hours_cost: 0.1419
photovoltaic_production_sell_price: 0.065
maximum_power_from_grid: 14490
list_pv_module_model:
- pv_module_model: CSUN_Eurasia_Energy_Systems_Industry_and_Trade_CSUN295_60M
list_pv_inverter_model:
- pv_inverter_model: Fronius_International_GmbH__Fronius_Primo_5_0_1_208_240__240V_
list_surface_tilt:
- surface_tilt: 30
list_surface_azimuth:
- surface_azimuth: 205
list_modules_per_string:
- modules_per_string: 16
list_strings_per_inverter:
- strings_per_inverter: 1
set_use_battery: true
battery_discharge_power_max: 3300
battery_charge_power_max: 3300
battery_discharge_efficiency: 0.95
battery_charge_efficiency: 0.95
battery_nominal_energy_capacity: 9300
battery_minimum_state_of_charge: 0.1
battery_maximum_state_of_charge: 1
battery_target_state_of_charge: 0.1
Click the three dots at the top of the configuration page and select yaml.
Hello @DarthMob
Do you mind sharing your ac_dimmer config in Esphome?
What is the dimmer model you use for 3 kW application?
I am having issues with zero crossing in a similar setup.
can we set Timezone for the running docker same as the host system I guess this will fix?