Is there a way to send rest command to change the profit to self consumption?
Im finding the system predicts a bad weather day for day ahead but batteries are dumping everything into the grid and it predicts it has to charge from the grid the following day even with charge from grid turned off.
I was hoping to send a command on bad weather days to swap out its max allowable amount so im not buying energy.
In my case that’s a REST command to the battery itself. I have a sonnen battery and you set it in automatic (self consumption) or manual mode by PUT.
Battery then takes over and tracks the consumption and uses solar first to supply consumption etc.
I gotcha, but its more for predictions,
Its clearly a poor day ahead and yet its dumping everything to the grid, the prediction can see it on the emhass graph that it wont generate enough.
I have the auto on off switches aswell but i the math should be auto?
In my case the data I pass every 60 seconds in the MPC post contains the actual PV output first and then the forecast data from solcast. Today its moderate to heavy rain (very low PV output) but for some reason solcast is forecasting moderate output from my 5 kWp PV cells? Don’t know why.
"pv_power_forecast": {{
([states('sensor.sonnenbatterie_84324_production_w')|int(0)] +
state_attr('sensor.solcast_pv_forecast_forecast_today', 'detailedForecast')|selectattr('period_start','gt',utcnow()) | map(attribute='pv_estimate')|map('multiply',1000)|map('int')|list +
state_attr('sensor.solcast_pv_forecast_forecast_tomorrow', 'detailedForecast')|selectattr('period_start','gt',utcnow()) | map(attribute='pv_estimate')|map('multiply',1000)|map('int')|list
)| tojson
}},
Output:
"pv_power_forecast": [284, 1329, 1552, 1717, 1758, 1748, 1657, 1665, 1674, 1665, 1628, 1536, 1407, 1210, 938, 734, 617, 511, 316, 125, 37, 5, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 34, 142, 473, 743, 970, 1147, 1340, 1502, 1639, 1781, 1952, 2090, 2154, 2183, 2168, 2094, 2011, 1940, 1850, 1728, 1523, 1276, 1071, 791, 439, 115, 18, 0, 0, 0, 0, 0, 0, 0, 0, 0],
So the first element ‘284’ is the actual production at the moment (this changes every 60 seconds) and the elements thereafter are the forecast data from solcast.
It looks like this graphically:
The yellow line seems to be disjointed (virtical at first then following the solcast curve) because the actual is 284 but the next half hour forecast is 1329 W which is clearly too high as this rain is not going to clear.
The same applies to the supply and feed-in tariffs (don’t have example of disjointed tariffs at the moment) so I assume calculations are tempered by the actual data element in front of the forecast data and this is adjusting the p_batt_forecast entity every 60 seconds towards the actual data with an eye on the forecast (so to speak).
Do you have the same structure and are you running the MPC model? Is my understanding correct?
@davidusb I’ve had to delete my recorder database and restart HA to create a new one. After doing this dayahead returns the following errors:
2023-11-05 20:08:45,574 - web_server - INFO - Setting up needed data
2023-11-05 20:08:45,576 - web_server - INFO - Retrieving weather forecast data using method = list
2023-11-05 20:08:45,577 - web_server - INFO - Retrieving data from hass for load forecast using method = naive
2023-11-05 20:08:45,577 - web_server - INFO - Retrieve hass get data method initiated...
2023-11-05 20:08:45,586 - web_server - ERROR - The retrieved JSON is empty, check that correct day or variable names are passed
2023-11-05 20:08:45,586 - web_server - ERROR - Either the names of the passed variables are not correct or days_to_retrieve is larger than the recorded history of your sensor (check your recorder settings)
2023-11-05 20:08:45,586 - web_server - ERROR - Exception on /action/dayahead-optim [POST]
Traceback (most recent call last):
File "/usr/local/lib/python3.9/dist-packages/flask/app.py", line 1455, in wsgi_app
response = self.full_dispatch_request()
File "/usr/local/lib/python3.9/dist-packages/flask/app.py", line 869, in full_dispatch_request
rv = self.handle_user_exception(e)
File "/usr/local/lib/python3.9/dist-packages/flask/app.py", line 867, in full_dispatch_request
rv = self.dispatch_request()
File "/usr/local/lib/python3.9/dist-packages/flask/app.py", line 852, 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 179, in action_call
input_data_dict = set_input_data_dict(config_path, str(data_path), costfun,
File "/usr/local/lib/python3.9/dist-packages/emhass/command_line.py", line 91, in set_input_data_dict
P_load_forecast = fcst.get_load_forecast(method=optim_conf['load_forecast_method'])
File "/usr/local/lib/python3.9/dist-packages/emhass/forecast.py", line 585, in get_load_forecast
rh.get_data(days_list, var_list)
File "/usr/local/lib/python3.9/dist-packages/emhass/retrieve_hass.py", line 147, in get_data
self.df_final = pd.concat([self.df_final, df_day], axis=0)
UnboundLocalError: local variable 'df_day' referenced before assignment
MPC doesn’t work either.
I’m not sure how to fix this? Can you help?
My curl template is:
{
"load_cost_forecast": {{
([states('sensor.cecil_st_general_price')|float(0)] +
state_attr('sensor.cecil_st_general_forecast', 'forecasts') |map(attribute='per_kwh')|list)
| tojson
}},
"prod_price_forecast": {{
([states('sensor.cecil_st_feed_in_price')|float(0)] +
(state_attr('sensor.cecil_st_feed_in_forecast', 'forecasts')|map(attribute='per_kwh')|list))
| tojson
}},
"pv_power_forecast": {{
([states('sensor.sonnenbatterie_84324_production_w')|int(0)] +
state_attr('sensor.solcast_pv_forecast_forecast_today', 'detailedForecast')|selectattr('period_start','gt',utcnow()) | map(attribute='pv_estimate')|map('multiply',1000)|map('int')|list +
state_attr('sensor.solcast_pv_forecast_forecast_tomorrow', 'detailedForecast')|selectattr('period_start','gt',utcnow()) | map(attribute='pv_estimate')|map('multiply',1000)|map('int')|list
)| tojson
}},
"num_def_loads": 2,
"def_total_hours": [3,0],
"P_deferrable_nom": [1300, 7360],
"treat_def_as_semi_cont": [1, 0]
}
And this is the result from that template:
{
"load_cost_forecast": [0.18, 0.17, 0.16, 0.16, 0.16, 0.16, 0.16, 0.16, 0.15, 0.16, 0.15, 0.13, 0.13, 0.13, 0.13, 0.13, 0.13, 0.13, 0.13, 0.13, 0.16, 0.16, 0.16, 0.13, 0.13, 0.13, 0.12, 0.1, 0.12, 0.1, 0.09, 0.08, 0.07, 0.07, 0.07, 0.07, 0.35, 0.36, 0.36, 0.36, 0.38, 0.38, 0.39, 0.4, 0.41, 0.43, 0.45, 0.45, 0.19],
"prod_price_forecast": [0.08, 0.08, 0.06, 0.06, 0.06, 0.06, 0.06, 0.06, 0.06, 0.06, 0.06, 0.04, 0.04, 0.04, 0.04, 0.04, 0.04, 0.04, 0.04, 0.04, 0.06, 0.06, 0.06, 0.04, 0.04, 0.04, 0.03, 0.01, 0.0, -0.01, -0.02, -0.03, -0.04, -0.04, -0.04, -0.04, 0.26, 0.28, 0.28, 0.28, 0.29, 0.29, 0.3, 0.31, 0.32, 0.34, 0.36, 0.36, 0.09],
"pv_power_forecast": [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 34, 147, 493, 796, 1061, 1254, 1443, 1613, 1771, 1946, 2114, 2211, 2286, 2355, 2365, 2298, 2163, 1978, 1849, 1727, 1465, 1137, 903, 621, 313, 82, 12, 0, 0, 0, 0, 0, 0, 0, 0, 0],
"num_def_loads": 2,
"def_total_hours": [3,0],
"P_deferrable_nom": [1300, 7360],
"treat_def_as_semi_cont": [1, 0]
}
Thanks in advance.
You may need to wait the two days before your recorder has sufficient history.
Thanks Mark. Thought so.
Im running basicly your setup, mixed with marks.
All my node red calls are wrapped with yours mixed with my solaredge ,
Im finiding nose red to stop very frequent nd reboot with the watchdog lately with no logs.
That’s no good. What version HA and Node Red are you running? What hardware is it running on?
Currenltly on a NUC,
Im currently doing updates, how did you turn those logs on to obtain further info? I belive theres something rebooting the node red but theres no trace data,
Ive deployed a watchdog outside of the node red to watch entity disconnect and its very frequent but constant. Nothing thats sticks out to do this.
I changed your calls to poll request so its frequest but scheduled and ive been swapping thwm around to see if this was the cause and still no Change.
Was going to write something in the home assitant github for node red shortly.
Which logs are you talking about?
What entities are disconecting?
Latest Tesla update has disabled car location update in the Tesla HACS integration ( device_tracker.CARNAME_location_tracker).
Have to change to smartphone location to determin if Tesla is home rather than actual car location. Works if only one person drives the car.
A fix for Tesla location tracking is incoming:
However, I was using Tesla location to open my garage via MyQ integration which is completely broken (hostile upstream) and won’t be coming back anytime, MyQ is being dropped from HA.
I have a Magic Button gate mechanism which uses 433MHz remote. My old Tesla model 3 had a HomeLink garage door opener built into the car but it didn’t work because the magic button system is encrypted.
So I have to put a Sonoff SV in the gate controller and wire it into the terminals that toggle the gate open and shut and put a magnetic switch on the gate to detect when it was closed and then use a Sonoff 433MHz bridge to work with the Tesla HomeLink.
The new Model Y doesn’t have a HomeLink built in so I’m back to a remote button again.
Great to see the fix coming in. As an FYI if you have a Gen3 Tesla wall charger you can use sensors from it to see if a vehicle is connected rather than rely on the location tracker in the Tesla.
Hello!
Big thanks to davidusb for this excellent development and also to markpurcell for contributing with his knowledge. This an fascinating topic.
I also started to test this integration and and few questions and issues. Maybe it’s already touched in this thread but it’s a long one and couldn’t find the answer.
First item for EU users who are buying electricity according to Nordpool spot price (including me). Since day ahead prices are published every day afternoon, we get at least a 36h forecast for energy prices. So it’s a 12 hour advantage compared to EMHASS 24h optimization. It would be great if we could take this into use somehow. Maybe it is but I’ve understood it’s possible to do only 24h ahead optimizations?
Other item is, I found EMHASS results to be 1 hour off from inserted values.
If I post forecast values at 23:55 of solcast and nordpool, they are reported with one hour lag in results. I’ve attached some explaining pictures:
EMHASS report:
Solar forecast from energy tab:
Will add in next post due to “New user” restrictions
Solar in EMHASS:
Will add in next post due to “New user” restrictions
Nordpool price list:
today:
Data is forwarded by this shell command:
trigger_emhass_forecast: “curl -i -H "Content-Type: application/json" -X POST -d ‘{"load_cost_forecast":{{((state_attr(‘sensor.nordpool_kwh_ee_eur_3_05_02’, ‘raw_today’) | map(attribute=‘value’) | list + state_attr(‘sensor.nordpool_kwh_ee_eur_3_05_02’, ‘raw_tomorrow’) | map(attribute=‘value’) | list))[now().hour:][:24] }},"prod_price_forecast":{{((state_attr(‘sensor.nordpool_sell’, ‘raw_today’) | map(attribute=‘value’) | list + state_attr(‘sensor.nordpool_sell’, ‘raw_tomorrow’) | map(attribute=‘value’) | list))[now().hour:][:24]}},"pv_power_forecast":{{states(‘sensor.solcast_24hrs_forecast’)}}}’ http://localhost:5000/action/dayahead-optim”
So what about 1,5 day forecasting option and is there a way to get EMHASS results with correct timestamps?
And solar forecast shown in EMHASS:
Try to set the “timestamp rounding”
“Last” would associate the results to 00:00, “first” to 23:00, “nearest”… well… to the nearest; in your case 00:00.
This should be related to the fact you are passing the 23:00 slot cost as first item of the list (I see 16,94 in the table). Other people using nordpool may confirm.
Dear community,
I have a rather simple question I guess, but haven´t found any documentation or workaorunds on this one…
Is it possible to set defferable loads not to run in parrallel?
E.g. I have a heat pump which I want to use for two defferable loads, heating and warm water production. This can´t be done at the same time. So I have to tell these two defferable loads not to run at the same time.
Is this possible?
