By how the optimization is formulated with the current code is very easy to fall into unfeasible situations when playing with set_def_constant
. So check the optimization status in the logs to see if that’s the case. This works perfectly with one deferrable load but I may have to dig for a solution with multiple deferrables. I kind of see why this introduces a hard constraint that makes the problem unsolvable but it need to be tested. One option is to add relaxations to the LP formulation. It has been on the road map for a while so it is may be time to dig into it. If the problem is unfeasibility and it persist then please open a github issue to treat it properly.
Very interesting Add-on! I’m eager to see if this will help with my energy optimization.
I’m stuck at the beginning - I’ve set up a preliminary configuration and wish to see the Web UI screen and output (if any). Unfortunately, I have not been able to connect to my HA IP address at port 5000. I get a “connection refused” error.
I have no such difficulty accessing the HA UI on port 8123, so I thought I’d check to see if port 5000 is listening.
netstat shows that 0.0.0.0:5000 is in the LISTEN state, as are other ports such as 8123 and 4357. As a test, I can also access the HA ip address at port 4357 and that works (“Home Assistant Observer”).
I’ve tried binding several other available port numbers in the EMHASS configuration with the same result (netstat confirms that the configured port is in the LISTEN state each time, but I cannot connect to my HA ip on that port).
The log does show a couple of errors such as:
File “/usr/local/lib/python3.9/dist-packages/requests/models.py”, line 439, in prepare_url
raise MissingSchema(
requests.exceptions.MissingSchema: Invalid URL ‘/api/config’: No scheme supplied. Perhaps you meant https:///api/config?
I do have a firewall (OPNsense), but I’ve defined no specific rules based on port numbers. My HA device is on a dedicated IOT VLAN, but I allow traffic from the IOT VLAN to my WAN where I connect my PC.
I’d appreciate advice. Thank you.
Hi, thanks!
This has always been problematic, but that GUI is only used to check that everything is working fine before setting up the automations that will handle the functions of the add-on later.
In my case I’m only able to access it from my LAN using the IP address of my HA instance. So if HA is at for example 192.168.0.50, then access the GUI at http://192.168.0.50:5000/
You are welcome! It looks awesome.
I am using my local ip address for HA at 192.168.xx.xxx:5000.
I’ll review the documentation and see what I can do regarding automations. I’m currently controlling use of two heat pumps to make use of solar power generation during peak-rate periods. But when it will be cloudy, I wish to pre-condition the temperature off-peak. On the other hand, when the outdoor temperature will be mild I can be less aggressive and even sell excess solar to the utility.
My current approach is functional but not optimized. I’m eager to see what EMHASS can do!
Thanks again.
I’ve started looking at this again. My apologies for novice issues/questions.
I am using the Add-On in HAOS installed on an ODROID-N2+.
- I restarted EMHass and waited one day. I do not find sensor.p_deferrable0 in my entity list. So I assume I have not configured EMHass correctly. Would it help if I shared my logs or all of my settings?
- I do not understand the definition for:
sensor_power_load_no_var_loads: The name of the household power consumption sensor in Watts from Home Assistant. The deferrable loads that we will want to include in the optimization problem should be substracted from this sensor in HASS. For example: ‘sensor.power_load_no_var_loads’
In my case the deferable loads are two air-air heat pumps, and I do not have sensors for these heat pumps. These heat pumps have nominal power draws of 4000 and 2800 watts (but actual power use varies since the heat pumps are modern inverter-based units). Do I need to provide sensor data from these two loads to use EMHass?
I’ve defined the following template sensor, but to be honest I don’t think it’s useful since most of the time it reads “0.” Here I’m subtracting the total of the two nominal deferable loads (fixed 6800 watts) from the home energy use, limiting the minimum to “0.”
- platform: template
sensors:
power_load_no_var_loads: # Power Use minus EMHass variable load total
friendly_name: "Power without deferable loads"
unit_of_measurement: "W"
value_template: >
{% if (states('sensor.energy_usage') | int(0) - 6800 | int(0)) > 0 %}
{{ (states('sensor.energy_usage') | int(0) - 6800 | int(0)) }}
{% else -%}
0
Modifying this sensor with the actual load values would give a more sensible number, I think.
I would appreciate any guidance. I look forward to experimenting with this awesome add-on!
EMHASS will function better if you have sensors for these devices, but you can work around.
Powercalc - Virtual power sensors will allow you to setup virtual power sensors that can change depending on the mode of your HVAC
This is what I use:
- platform: powercalc
entity_id: climate.daikin_ap33073
fixed:
states_power:
heat: 4500
cool: 4000
dry: 2000
fan_only: 400
sensor.power_load_no_var_loads needs to be setup to only subtract the load values when the device is operational.
Hi @markpurcell
Thanks again for your help. I’ve had a bit of a challenge with Powercalc, but I did manage to create template sensors for power from the two heat pumps, and a template sensor power_load_no_var_loads.
(Note that “Energy Useage” is mislabeled - that comes from the Sense integration. It should read Power…).
I’m not sure this is a useful sensor, though, since my heat pumps represent the primary loads most of the time, and since both loads are variable.
In any case, I’m also having difficulty with EMHass - the web UI won’t load, and even though I’m running the required shell command services, I do not see an entity sensor.p_deferrable0. So I’m going to pause for now and watch the development of this Add-On.
I’ll make another topic that discusses how I’m managing my two (heat pump) loads at present. It’s complex enough with just two loads to manage - I do see a need for much more flexibility and look-ahead forecasting.
Thanks again!
Hello everybody,
I’m starting playing around so a newbie on this cool project.
Sorry if I’m asking something obvious to some of you.
My (first) question is if the only allowed PV and inverter models are the one linked in the documentation of the add-on (back from 2019 it seems) or if we can also use the updated lists from the NREL/SAM project mentioned in the “python” thread (or if there is any plan to update the list accepted by the add-on).
Thanks!
EDIT:
or if we can manually update the list ourselves: it seems there is only one extra column (Manufacturer) in the updated file for PV modules, if compared to the 2019 one.
The PV forecast scrape method is using the PVLib Python module to convert from irradiance to Watts. So as you may understand is out of my hand to keep this database updated.
There have been some updates on PVLib but I don’t think that they updated their modules and inverter databases as we can see here: https://github.com/pvlib/pvlib-python/tree/main/pvlib/data
If you don’t find a suitable model on this database for you then you can use any of the other methods: Solcast, Forecast.Solar, a custom passed list from another service, etc.
This being said you may ask the PVLib maintainers and you may even try to update the database yourself. If like you said you just want to add a new column I don’t see why they will oppose to that.
In the meantime I will just update PVlib to the latest version.
Thank you,
That’s an option (passing solar forecast) I planned to have a look maybe at a later stage, once I have something running, I gain experience and I can fine tune.
Another question if I may… I’m trying to run my first optimization run and as I mentioned I wanted to make the least possible customizations for the moment.
How long does it take in your opinion to perform the optimization?
I’m staying with the defaults (2 days historical data) and I’m running it under a Pi3b+ (with a couple of PV models from the DB) but after two hours it seems nothing is happening/happened.
I also read in older posts that maybe under arm64 I may need to use a different solver, maybe GLPK. Do you think that’s still the point? How do I find the right path of each solver?
This is my log.
Thanks again!
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-08-02 13:20:42,324 - web_server - INFO - Launching the emhass webserver at: http://0.0.0.0:5000
2023-08-02 13:20:42,327 - web_server - INFO - Home Assistant data fetch will be performed using url: http://supervisor/core/api
2023-08-02 13:20:42,328 - web_server - INFO - The data path is: /share
2023-08-02 13:20:42,341 - web_server - INFO - Using core emhass version: 0.4.14
waitress INFO Serving on http://0.0.0.0:5000
2023-08-02 13:20:44,218 - web_server - INFO - EMHASS server online, serving index.html...
2023-08-02 13:20:44,250 - web_server - WARNING - The data container dictionary is empty... Please launch an optimization task
2023-08-02 13:21:07,184 - web_server - INFO - Setting up needed data
2023-08-02 13:21:07,512 - web_server - INFO - Retrieve hass get data method initiated...
2023-08-02 13:22:11,985 - web_server - INFO - Launching the emhass webserver at: http://0.0.0.0:5000
2023-08-02 13:22:11,987 - web_server - INFO - Home Assistant data fetch will be performed using url: http://supervisor/core/api
2023-08-02 13:22:11,987 - web_server - INFO - The data path is: /share
2023-08-02 13:22:12,033 - web_server - INFO - Using core emhass version: 0.4.14
waitress INFO Serving on http://0.0.0.0:5000
2023-08-02 15:35:04,018 - web_server - INFO - EMHASS server online, serving index.html...
2023-08-02 15:35:04,155 - web_server - WARNING - The data container dictionary is empty... Please launch an optimization task
You haven’t launch any optimization yet. You just started the add-on and the server is ready waiting for your instructions. You can send instructions to the server via some “endpoints” using “curl” commands defined using the shell_command
integration from Home Assistant.
Read the documentation and installation method 1 (Add-on) here: Intro / Quick start — emhass 0.4.14 documentation
I tried to launch it from the UI (“perfect optimization”). But after two hours that was the log.
But of course no problem I can still try to shell command.
Edit:
Launching this from the HA terminal:
curl -i -H \"Content-Type:application/json\" -X POST -d '{}' http://localhost:5000/action/dayahead-optim
returns:
HTTP/1.0 400 Bad Request
Connection: close
Content-Length: 56
Content-Type: text/plain; charset=utf-8
Date: Wed, 02 Aug 2023 14:29:41 GMT
Server: waitress
Bad Request
Invalid header
(generated by waitress)
Those logs doesn’t show that you push any button. No optimization was launched. So that’s weird.
These optimization are really fast because we are solving relatively small LP problems. They should take one or two seconds for each optimized day.
Try this instead:
curl -i -H 'Content-Type:application/json' -X POST -d '{}' http://localhost:5000/action/dayahead-optim
Now I tried to launch the day ahead optim form the UI and something is being logged.
2023-08-02 16:39:18,461 - web_server - INFO - Setting up needed data
2023-08-02 16:39:19,220 - web_server - INFO - Retrieving weather forecast data using method = scrapper
2023-08-02 16:39:32,282 - web_server - INFO - Retrieving data from hass for load forecast using method = naive
2023-08-02 16:39:32,352 - web_server - INFO - Retrieve hass get data method initiated...
2023-08-02 16:40:31,486 - web_server - INFO - Launching the emhass webserver at: http://0.0.0.0:5000
2023-08-02 16:40:31,487 - web_server - INFO - Home Assistant data fetch will be performed using url: http://supervisor/core/api
2023-08-02 16:40:31,488 - web_server - INFO - The data path is: /share
2023-08-02 16:40:31,514 - web_server - INFO - Using core emhass version: 0.4.14
waitress INFO Serving on http://0.0.0.0:5000
I let you know what happens, then I try with your updated command
This command was accepted but the message I got from the terminal is
curl: (52) Empty reply from the server
and the log while running this was
2023-08-02 16:45:41,709 - web_server - INFO - Setting up needed data
2023-08-02 16:45:42,034 - web_server - INFO - Retrieving weather forecast data using method = scrapper
2023-08-02 16:45:49,377 - web_server - INFO - Retrieving data from hass for load forecast using method = naive
2023-08-02 16:45:49,408 - web_server - INFO - Retrieve hass get data method initiated...
2023-08-02 16:46:49,311 - web_server - INFO - Launching the emhass webserver at: http://0.0.0.0:5000
2023-08-02 16:46:49,312 - web_server - INFO - Home Assistant data fetch will be performed using url: http://supervisor/core/api
2023-08-02 16:46:49,312 - web_server - INFO - The data path is: /share
2023-08-02 16:46:49,330 - web_server - INFO - Using core emhass version: 0.4.14
waitress INFO Serving on http://0.0.0.0:5000
Edit:
I’m using COIN_CMD as solver
Edit2:
Debug logging doesn’t give more details.
I get the Empty reply in the terminal when the log shows:
2023-08-02 16:58:05,212 - web_server - INFO - Retrieve hass get data method initiated...
I tried to reinstall the component, use the defauls and just pass the PV and load variables, invoke the command playing a bit with https, localhost, 0.0.0.0:5000, homeassistat.local:5000, change the resolver to GLPK but no luck.
The best I can get is using
curl -i -H 'Content-Type:application/json' -X POST -d '{}' http://localhost:5000/action/dayahead-optim
and still the results is always the log I previously posted and an empty reply error in the Terminal.
PS, if useful:
when I use https in the curl command I get nothing in the log and an SSL error in the Terminal
Running this curl command won’t return anything of any significance in your terminal session. It should update the graph in the UI though. What does the graph look like after running the day ahead optimisation?
Hello Robert,
That’s the problem.
Nothing, no charts.
This is the log after starting the add-on, launching the day-ahead command and then checking the front-end for any charts. Also the log confirms the data container is still empty.
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-08-05 14:01:54,505 - web_server - INFO - Launching the emhass webserver at: http://0.0.0.0:5000
2023-08-05 14:01:54,511 - web_server - INFO - Home Assistant data fetch will be performed using url: http://supervisor/core/api
2023-08-05 14:01:54,511 - web_server - INFO - The data path is: /share
2023-08-05 14:01:54,530 - web_server - INFO - Using core emhass version: 0.4.14
waitress INFO Serving on http://0.0.0.0:5000
2023-08-05 14:01:57,557 - web_server - INFO - Setting up needed data
2023-08-05 14:01:57,979 - web_server - INFO - Retrieving weather forecast data using method = scrapper
2023-08-05 14:02:08,291 - web_server - INFO - Retrieving data from hass for load forecast using method = naive
2023-08-05 14:02:08,298 - web_server - INFO - Retrieve hass get data method initiated...
2023-08-05 14:03:54,921 - web_server - INFO - Launching the emhass webserver at: http://0.0.0.0:5000
2023-08-05 14:03:54,922 - web_server - INFO - Home Assistant data fetch will be performed using url: http://supervisor/core/api
2023-08-05 14:03:54,922 - web_server - INFO - The data path is: /share
2023-08-05 14:03:54,942 - web_server - INFO - Using core emhass version: 0.4.14
waitress INFO Serving on http://0.0.0.0:5000
2023-08-05 14:03:55,599 - web_server - INFO - EMHASS server online, serving index.html...
2023-08-05 14:03:55,637 - web_server - WARNING - The data container dictionary is empty... Please launch an optimization task
What’s your configuration?
hass_url: empty
long_lived_token: empty
costfun: profit
logging_level: INFO
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_XXXXX_production_w
sensor_power_load_no_var_loads: sensor.house_power_consumption_less_deferrables
number_of_deferrable_loads: 1
list_nominal_power_of_deferrable_loads:
- nominal_power_of_deferrable_loads: 1300
list_operating_hours_of_each_deferrable_load:
- operating_hours_of_each_deferrable_load: 2
list_peak_hours_periods_start_hours:
- peak_hours_periods_start_hours: "10:00"
list_peak_hours_periods_end_hours:
- peak_hours_periods_end_hours: "16:00"
list_treat_deferrable_load_as_semi_cont:
- treat_deferrable_load_as_semi_cont: true
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: 21
list_surface_azimuth:
- surface_azimuth: 350
list_modules_per_string:
- modules_per_string: 17
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