Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

First time user configuration comments #48

Open
HACS-bank opened this issue Sep 2, 2023 · 18 comments
Open

First time user configuration comments #48

HACS-bank opened this issue Sep 2, 2023 · 18 comments
Labels
enhancement New feature or request

Comments

@HACS-bank
Copy link

Having just downloaded emhass as an addin under HAOS, now is the best time to note the difficulties I found with getting started. These are little details in what looks like an important tool for improving renewable energy efficiency and these comments are meant to be helpful!

  1. It is not clear how much configuration is required - new users want to see something quickly, so may skip config steps. It seems like sensors from HASS are important but they are not at the top of the config UI.
  2. Documentation mentions using solcast instead of inverter/pv panel details but this is not structured as an option in config ui.
  3. It is not obvious how much the PV system details matter - is it just the total system size / maximum output, or why does this need to be so detailed? Many PV owners will not know what modules they have 😀. [Would it be possible to learn the PV system max power from HASS?]
  4. Documentation suggests that on first load, there should be a graph in the Web UI. I didn't see any graph, not sure if this means I have made an error or if the documentation should be updated. I'm using my phone to configure, so maybe the graph is hidden on small screens.
  5. In config UI, the list of peak cost times is in amongst load items which must also be a list. It would be more understandable if these things were separated. The example config has two of each, it might help to have three loads and two peak periods.
  6. Logs show error due to "variable used before defined" (pf_day) if the JSON returned from HASS is empty. For new users this is hard to understand. Since several items are fetched from HASS, it would be helpful to have better error messages around what is wrong with the config/what is fetched OK and what failed, and some suggestions in the documentation on how to fix it.
  7. The minimum power used by the home is required, but that is not a standard item in HASS. More instructions about how to set that up would be helpful to users with limited experience.
  8. Thank you for your hard work making this and sharing it!
@HACS-bank
Copy link
Author

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-09-02 16:24:13,313 - web_server - INFO - Launching the emhass webserver at: http://0.0.0.0:5000 2023-09-02 16:24:13,313 - web_server - INFO - Home Assistant data fetch will be performed using url: http://supervisor/core/api 2023-09-02 16:24:13,313 - web_server - INFO - The data path is: /share 2023-09-02 16:24:13,315 - web_server - INFO - Using core emhass version: 0.4.15 waitress INFO Serving on http://0.0.0.0:5000 2023-09-02 16:27:34,893 - web_server - INFO - EMHASS server online, serving index.html... 2023-09-02 16:27:34,901 - web_server - WARNING - The data container dictionary is empty... Please launch an optimization task 2023-09-02 16:27:49,427 - web_server - INFO - EMHASS server online, serving index.html... 2023-09-02 16:27:49,435 - web_server - WARNING - The data container dictionary is empty... Please launch an optimization task 2023-09-02 16:27:53,162 - web_server - INFO - Setting up needed data 2023-09-02 16:27:53,220 - web_server - INFO - Retrieve hass get data method initiated... 2023-09-02 16:27:53,233 - web_server - ERROR - The retrieved JSON is empty, check that correct day or variable names are passed 2023-09-02 16:27:53,233 - 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-09-02 16:27:53,233 - web_server - ERROR - Exception on /action/perfect-optim [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 174, 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 78, in set_input_data_dict 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

@HACS-bank
Copy link
Author

Changing log level to DEBUG doesn't seem to produce any additional information.

@HACS-bank
Copy link
Author

HACS-bank commented Sep 2, 2023

hass_url: empty
long_lived_token: empty
costfun: cost
logging_level: DEBUG
optimization_time_step: 30
historic_days_to_retrieve: 2
method_ts_round: nearest
set_total_pv_sell: false
lp_solver: COIN_CMD
lp_solver_path: /usr/bin/cbc
set_nocharge_from_grid: true
set_nodischarge_to_grid: true
set_battery_dynamic: false
battery_dynamic_max: 0.9
battery_dynamic_min: -0.9
load_forecast_method: naive
sensor_power_photovoltaics: sensor.fronius_pv_generation
sensor_power_load_no_var_loads: input_number.power_load_no_var_loads
number_of_deferrable_loads: 2
list_nominal_power_of_deferrable_loads:

  • nominal_power_of_deferrable_loads: 3000
  • nominal_power_of_deferrable_loads: 750
    list_operating_hours_of_each_deferrable_load:
  • operating_hours_of_each_deferrable_load: 5
  • operating_hours_of_each_deferrable_load: 8
    list_peak_hours_periods_start_hours:
  • peak_hours_periods_start_hours: "04:30"
    list_peak_hours_periods_end_hours:
  • peak_hours_periods_end_hours: "01:30"
    list_treat_deferrable_load_as_semi_cont:
  • treat_deferrable_load_as_semi_cont: true
  • treat_deferrable_load_as_semi_cont: true
    load_peak_hours_cost: 0.35
    load_offpeak_hours_cost: 0.065
    photovoltaic_production_sell_price: 0
    maximum_power_from_grid: 9000
    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: 45
    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: false
    battery_discharge_power_max: 1000
    battery_charge_power_max: 1000
    battery_discharge_efficiency: 0.95
    battery_charge_efficiency: 0.95
    battery_nominal_energy_capacity: 5000
    battery_minimum_state_of_charge: 0.3
    battery_maximum_state_of_charge: 0.9
    battery_target_state_of_charge: 0.6

@davidusb-geek
Copy link
Owner

Thank you for your comments, they are really constructive and should improve and ease the user experience with this add-on. There is a lot of room for improvements and those points that you noticed are just a bunch of them.
If I find the time I will try to provide answers and updates to the documentation to improve this.
But at the same contributions and pull requests are wanted with all this. Feel free to clone this code and provide your own improvements even if it just for the documentation or for things like you comment on the order of parameters in the configuration.

On your error and the error message the text where the df_day error appears is just the traceback from Python and there is noting I can do about this message being explicit or not.
The message that comes from my code in your case is this:

2023-09-02 16:27:53,233 - 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) 

So for this type of error there two things are the most common source of error. Check those and feel free to reply if you find any other issues.

@purcell-lab
Copy link
Contributor

Could I suggest there are a lot of advanced settings details in the add-on configuration page, that is quite confusing for first time users. I help a few people set up EMHASS for the first time and the biggest issue is the initial setup.

Could I recommend a simplification of the initial add-on setup for a basic configuration, advanced settings could still be available via the YAML interface and then even more advanced settings can be available via the command line/ curl/ REST interface.

The EMHASS kWp model is a lot easier to set up than the pvlib interface, so I would suggest that the add-on configuration page switch to the kWp model as most people know what their system is. 5 kWp seems to be a standard configuration here as well, so could be a good default. Similarly for the battery, there are detailed settings that could be hidden in YAML, with the most important being battery capacity (Wh).

power_load(_no_var_loads) could I also make a suggestion regarding the no_vars component of power load. The need for no_var_loads is problematic for many users as they need to create a template sensor (which is non trivial for many first time users) and then they have to wait two days for history which again raises the barriers to entry for first time users.

I actually calculate my power_load_no_var_loads differently, by using the deferrable forecasts in place of the actual values:

    - name: power_load_no_var_loads
      unit_of_measurement: W
      device_class: power
      state_class: measurement 
      unique_id: 9e2d02cb-2ac4-4eb2-9f57-c4c158c145e7
      state: >-
        {{states('sensor.home_energy_gateway_load_power')|int(0)
        - states('sensor.p_deferrable0')|int(0) 
        - states('sensor.p_deferrable1')|int(0)
        - states('sensor.p_deferrable2')|int(0) 
        - states('sensor.p_deferrable3')|int(0)
        - states('sensor.p_deferrable4')|int(0)
        - states('sensor.p_deferrable5')|int(0)
        }}

EMHASS could calculate this internally as it know what each of the deferrable load forecasts are and the user would only need to supply their current load sensor, which is generally available from solar / battery monitoring already so they don't need to await two days. A YAML option could be available for exiting users or those who wanted to calculate using the traditional calculations for power_load_no_var_loads.

My suggestions:

ADD-ON User interface configuration:
Solar PV: kWp (default 5000)
Home Assistant sensor for PV power production
Home Assistant sensor for load power*
Cost Function: Profit/ Cost/ Self-Consumption
Number of deferrable loads/ power/ hours (default 2)
Peak hours Start/ End (default 1600-2000)
peak cost of electricity (default 0.1907)
non-peak cost of electricity (default 0.1419)
export price (default 0.065)
battery option switch
battery capacity Wh (default 5000)

Hidden in YAML configuration:
Home Assistant URL
Long Lived Access Token
logger level
time step
history days
timestamp rounding
PV production to sell
Linear programming solver
Power dynamic limiting condition and values
Load forecast model
semi continuous variable loads
maximum power from grid
pvlib parameters; module/ inverter/ tilt/ azimuth/ modules per string/ string per inverter
battery discharge/ charge power/ efficiency
minimum/ maximum/ desired SOC
network ports

On the WEB UI, I recommend removing the ML forecaster buttons as advanced users can access this via the Curl payloads.

@lyricnz
Copy link

lyricnz commented Sep 13, 2023

Echoing the OP comments:

  • UI for first-time users is way too complex, too much configuration and knowledge required. Suggest there should be a "simple mode"
  • Help text refers to a "list of integers" when it seems to mean a list of elements with the same key "This is a value between 0 and 90. Defaults to 30. This parameter can be a list of integers to enable the simulation..."
  • Doesn't seem possible to save config without deferrable loads (sometimes we just want to view/predict; or just manage battery charge/discharge)
  • Help text around the use of "empty" (a literal string) vs "" (literally an empty string) in HA url/token is unclear
  • why does cost use Euros/kWh (I'm not in europe)

@davidusb-geek
Copy link
Owner

These are very nice ideas for improvement.
Right now I'm struggling to find free time to work on this. But I will do in the future.
In the mean time:

... contributions and pull requests are wanted with all this. Feel free to clone this code and provide your own improvements even if it just for the documentation or for things like you comment on the order of parameters in the configuration.

@davidusb-geek davidusb-geek added the enhancement New feature or request label Oct 15, 2023
@GeoDerp
Copy link
Contributor

GeoDerp commented Jan 23, 2024

A stop gap may be to create a page in EMHASS doc's (Foulder) and/or modify the DOCS.md to help explain each parameter/setup step by step. Maybe include some basic copy and past configuration yaml examples for common implementations.

In terms of modifying the parameter names and descriptions to more understandable. You my like to look at modifying the config_emhass.yaml & en.yaml files respectively. They should be relatively easy to understand. May want to fork, edit these files, and perform a pull request to help out.

Hidden in YAML configuration:

Let me know if this is possible, and i will (given spear time) integrate this feature and create a pull request.

Alternatively, once all the parameters have been pulled in on EMHASS, if someone could create a order of (required & optional) or (most likely to least likely) and post it here. Either I, or another person, could update the configuration file.

Edit: on second thought it may be good to create an enhancement request (or make) to homeassistant to support drop down selects in addon configuration files.

@Deztak
Copy link

Deztak commented Feb 11, 2024

This was very similar to my experience. I have no deferrable loads, but, the error message just says "0 is not a valid input" and the lists all of the variable in the config, so I had no idea what the cause was.

@bf8392
Copy link

bf8392 commented Feb 14, 2024

Hi =) I'm a first time user, and I run into the same problems as mentioned above...I do not get it to run sadly...
However I really love the project, and if I can be of any Help, tell me =) Things that I would suggest:

  1. It is not clear how EMHASS fetches it's data for me...I run the Addon, and I always get df_day error, without knowing why
  2. Some configuration variables seem to be named similliar, but have a different name in the docs. Not all config variables are clear to me
  3. That's rather an enchancement; I don't like that the addon is accessible from outside home assitant. It would be cool to have an option that let it just use with the internal reverse proxy...especially as there is no auth on the addon
  4. I wanted to use the addon to set a dynamic boiler temperature...I think it's capable of doing it, but I don't know how...can we include a sample config for that? Woulkd also be cool for electric cars =).
  5. The variables def_total_hours; def_start_timestep; def_end_timestep make no sense to me... I don't konw what is the effect of them...
  6. It's not clear, which setting applies to which defferable load. They are all in a list with same names....(does each first item match together for example?)

anyhow the project is amazing =). I hope I get it to run sometime =). Thanks for this Addon =)

@davidusb-geek
Copy link
Owner

  1. It is not clear how EMHASS fetches it's data for me...I run the Addon, and I always get df_day error, without knowing why

Sure there is room for improvement but there are many reasons for which that error could be obtained.
The current logger message treats the most common case. So if you have a better idea please share.
There are mainly these reasons: bad sensor name passed, not enough history data or simply bad configured URL and token for data retrieving.
Data is retrieved using the HA API https://developers.home-assistant.io/docs/api/rest 2
We are using the /api/history/period/ GET endpoint.

  1. Some configuration variables seem to be named similliar, but have a different name in the docs. Not all config variables are clear to me

The add-on documentation seems pretty clear to me. But could you please elaborate, what are those variables with similar names?

  1. That's rather an enchancement; I don't like that the addon is accessible from outside home assitant. It would be cool to have an option that let it just use with the internal reverse proxy...especially as there is no auth on the addon

I don't understand the problem here... This is working as any other add-on that leverages an API isn't it?

  1. That's rather an enchancement; I don't like that the addon is accessible from outside home assitant. It would be cool to have an option that let it just use with the internal reverse proxy...especially as there is no auth on the addon

Again this seems clear fro the add-on documentation and translations.
You can contribute with the translations file to improve variables descriptions.
All contributions are very much welcomed.

  1. It's not clear, which setting applies to which defferable load. They are all in a list with same names....(does each first item match together for example?)

The first element of the list applies to first deferrable load, the second element of the list applies to second deferrable load, and so on...

@GeoDerp
Copy link
Contributor

GeoDerp commented Feb 15, 2024

Q1 Answer?

It is not clear how EMHASS fetches it's data for me...I run the Addon, and I always get df_day error, without knowing why

This is something I would like to improve. May have a look at this issue this evening.

Q2 Answer?

Some configuration variables seem to be named similliar, but have a different name in the docs. Not all config variables are clear to me

I think I know the confusion here.
FIrst there are 4 areas of information for emhass: addon readme, emhass readme, emhass wiki and the emhass docs
I think what @davidusb-geek is stating, is that the addon readme should be correct.

For why the variables are off in the other information sources. The variable names have been changed in the addon options/config to make it more understandable to the user. The associations between the emhass addon and emhass can be found where they merge in the build_params function in utils.py. here is a more simpler version of it:

PR from davidusb-geek/emhass#181

        # create associations list
        # _conf, key, options key, 'options key in list'
        ...
        # variables in retrieve_hass_conf
        associations.append(['retrieve_hass_conf', 'freq', 'optimization_time_step'])
        associations.append(['retrieve_hass_conf', 'days_to_retrieve', 'historic_days_to_retrieve'])
        associations.append(['retrieve_hass_conf', 'var_PV', 'sensor_power_photovoltaics'])
        associations.append(['retrieve_hass_conf', 'var_load', 'sensor_power_load_no_var_loads'])
        associations.append(['retrieve_hass_conf', 'load_negative', 'load_negative'])
        associations.append(['retrieve_hass_conf', 'set_zero_min', 'set_zero_min'])
        associations.append(['retrieve_hass_conf', 'method_ts_round', 'method_ts_round'])
        # variables in params_secrets
        associations.append(['params_secrets', 'solcast_api_key', 'optional_solcast_api_key'])
        associations.append(['params_secrets', 'solcast_rooftop_id', 'optional_solcast_rooftop_id'])
        associations.append(['params_secrets', 'solar_forecast_kwp', 'optional_solar_forecast_kwp'])
        associations.append(['params_secrets', 'time_zone', 'time_zone'])
        associations.append(['params_secrets', 'lat', 'Latitude'])
        associations.append(['params_secrets', 'lon', 'Longitude'])
        associations.append(['params_secrets', 'alt', 'Altitude'])
        #  variables in optim_conf
        associations.append(['optim_conf', 'set_use_battery', 'set_use_battery'])
        associations.append(['optim_conf', 'num_def_loads', 'number_of_deferrable_loads'])
        associations.append(['optim_conf', 'P_deferrable_nom', 'list_nominal_power_of_deferrable_loads', 'nominal_power_of_deferrable_loads'])
        associations.append(['optim_conf', 'def_total_hours', 'list_operating_hours_of_each_deferrable_load', 'operating_hours_of_each_deferrable_load'])
        associations.append(['optim_conf', 'treat_def_as_semi_cont', 'list_treat_deferrable_load_as_semi_cont', 'treat_deferrable_load_as_semi_cont'])
        associations.append(['optim_conf', 'set_def_constant', 'list_set_deferrable_load_single_constant', 'set_deferrable_load_single_constant'])
        associations.append(['optim_conf', 'weather_forecast_method', 'weather_forecast_method'])
        associations.append(['optim_conf', 'load_forecast_method', 'load_forecast_method'])
        associations.append(['optim_conf', 'delta_forecast', 'delta_forecast_daily'])
        associations.append(['optim_conf', 'load_cost_forecast_method', 'load_cost_forecast_method'])
        associations.append(['optim_conf', 'load_cost_hp', 'load_peak_hours_cost'])
        associations.append(['optim_conf', 'load_cost_hc', 'load_offpeak_hours_cost'])
        associations.append(['optim_conf', 'prod_price_forecast_method', 'production_price_forecast_method'])
        associations.append(['optim_conf', 'prod_sell_price', 'photovoltaic_production_sell_price'])
        associations.append(['optim_conf', 'set_total_pv_sell', 'set_total_pv_sell'])
        associations.append(['optim_conf', 'lp_solver', 'lp_solver'])
        associations.append(['optim_conf', 'lp_solver_path', 'lp_solver_path'])
        associations.append(['optim_conf', 'set_nocharge_from_grid', 'set_nocharge_from_grid'])
        associations.append(['optim_conf', 'set_nodischarge_to_grid', 'set_nodischarge_to_grid'])
        associations.append(['optim_conf', 'set_battery_dynamic', 'set_battery_dynamic'])
        associations.append(['optim_conf', 'battery_dynamic_max', 'battery_dynamic_max'])
        associations.append(['optim_conf', 'battery_dynamic_min', 'battery_dynamic_min'])
        associations.append(['optim_conf', 'weight_battery_discharge', 'weight_battery_discharge'])
        associations.append(['optim_conf', 'weight_battery_charge', 'weight_battery_charge'])
        associations.append(['optim_conf', 'def_start_timestep', 'list_start_timesteps_of_each_deferrable_load', 'start_timesteps_of_each_deferrable_load'])
        associations.append(['optim_conf', 'def_end_timestep', 'list_end_timesteps_of_each_deferrable_load', 'end_timesteps_of_each_deferrable_load'])
        # variables in plant_conf
        associations.append(['plant_conf', 'P_grid_max', 'maximum_power_from_grid'])
        associations.append(['plant_conf', 'module_model', 'list_pv_module_model', 'pv_module_model' ])
        associations.append(['plant_conf', 'inverter_model', 'list_pv_inverter_model', 'pv_inverter_model' ])
        associations.append(['plant_conf', 'surface_tilt', 'list_surface_tilt', 'surface_tilt' ])
        associations.append(['plant_conf', 'surface_azimuth', 'list_surface_azimuth', 'surface_azimuth'])
        associations.append(['plant_conf', 'modules_per_string','list_modules_per_string', 'modules_per_string'])
        associations.append(['plant_conf', 'strings_per_inverter', 'list_strings_per_inverter', 'strings_per_inverter'])
        associations.append(['plant_conf', 'Pd_max', 'battery_discharge_power_max'])
        associations.append(['plant_conf', 'Pc_max', 'battery_charge_power_max'])
        associations.append(['plant_conf', 'eta_disch', 'battery_discharge_efficiency'])
        associations.append(['plant_conf', 'eta_ch', 'battery_charge_efficiency'])
        associations.append(['plant_conf', 'Enom', 'battery_nominal_energy_capacity'])
        associations.append(['plant_conf', 'SOCmin', 'battery_minimum_state_of_charge'])
        associations.append(['plant_conf', 'SOCmax', 'battery_maximum_state_of_charge'])
        associations.append(['plant_conf', 'SOCtarget', 'battery_target_state_of_charge'])

FYI. The addon parameters can be refereed to as option parameters as HA creates a options.json file of your parameters in the addon configuration page.

Q3 Answer?

That's rather an enchancement; I don't like that the addon is accessible from outside home assitant. It would be cool to have an option that let it just use with the internal reverse proxy...especially as there is no auth on the addon

The interface allows incoming 0.0.0.0:5000 to default making it accessible to the LAN. Yeah I have thought about this too. Maybe at some point we can setup a verible that switches from localhost to 0.0.0.0.

For future reference. That means setting a param.get('web_ui_url',"0.0.0.0") here: https://github.com/davidusb-geek/emhass/blob/f7e98416ae84e1e7989e0bd2f6b364b579a75da5/src/emhass/web_server.py#L176. And creating that param everywhere else (en.yaml,config.yaml,utils.py)

Q6 Answer?

It's not clear, which setting applies to which defferable load. They are all in a list with same names....(does each first item match together for example?)

You can thank Json formatting for that one. but the first in the list = the first defferable, and so on. They get converted to a array in emhass. the variable names is just for the json.

@GeoDerp
Copy link
Contributor

GeoDerp commented Feb 16, 2024

davidusb-geek/emhass#196 tries to fix Q1 😁

@bf8392
Copy link

bf8392 commented Feb 16, 2024

Hey great thanks! Sorry that it took me longer to answer...@GeoDerp for the cool question structure :-) it was exactly what I meant :-).

@davidusb-geek thanks for all the work! I love the approach of the addon!

@GeoDerp
Copy link
Contributor

GeoDerp commented Mar 7, 2024

For those who want to know the difference between EMHASS and EMHASS-Add-On:

There is a new page that could hopefully help the common questions: https://emhass.readthedocs.io/en/latest/differences.html

@vermut
Copy link

vermut commented Apr 28, 2024

Great work, but a pain to configure indeed. It took me several attempts to finally start getting results I understand. Looking for a PV model in some 10M item excel made me cry a bit. Of course my panels weren't there.

Now I returned again and I definitely see some nice improvements like direct solcast integration (providing API key). Still it doesn't fit me as I have 2 sets of PVs on both sides of the roof.

So my ideas:

  • definitely make the learning curve shallower. It would be enough I think if user populates some basics like lat lon number of watts per roof side and start getting some, even semi-effective, results back that make sense. After one gets hooked one will read the docs :)
  • more specific suggestion - right now EMHASS needs raw massaged data from multiple sources. HASS itself is full of modules that already providing this data. It would be really cool if EMHASS just understands Nordpool integration (and knows that it's per hour); SolCast integration (and knows that it's per 30 minutes). If would distribute the load from @davidusb-geek to maintainers of those integrations.

This is how my emhass package file looks like:

rest_command:
  emhass_dayahead_optim:
    url: "http://5b918bf2-emhass:5000/action/dayahead-optim"
    method: POST
    headers:
      Content-Type: 'application/json'
    payload: >
      {% set load_forecasts = (state_attr('sensor.enefit_st_incoming', 'today') + state_attr('sensor.enefit_st_incoming', 'tomorrow'))[now().hour:][:24] %}
      {% set doubled_load_forecasts = namespace(all=[]) %}
      {% for forecast in load_forecasts %}
        {% set doubled_load_forecasts.all = doubled_load_forecasts.all + [forecast, forecast] %}
      {% endfor %}
      
      {% set prod_price_forecasts = (state_attr('sensor.enefitst_outgoing', 'today') + state_attr('sensor.enefitst_outgoing', 'tomorrow'))[now().hour:][:24] %}
      {% set doubled_prod_price_forecasts = namespace(all=[]) %}
      {% for forecast in prod_price_forecasts %}
        {% set doubled_prod_price_forecasts.all = doubled_prod_price_forecasts.all + [forecast, forecast] %}
      {% endfor %}
      
      {% set pv_forecast =
        (
          state_attr('sensor.solcast_pv_forecast_forecast_today', 'detailedForecast') 
          | sort(attribute='period_start')  
          | map(attribute='pv_estimate')  
          | map('float', 0)
          | map('multiply', 1000) 
          | list
      
          +
      
          state_attr('sensor.solcast_pv_forecast_forecast_tomorrow', 'detailedForecast') 
          | sort(attribute='period_start')  
          | map(attribute='pv_estimate')  
          | map('float', 0)
          | map('multiply', 1000) 
          | list
      
        )[:48]
      %}
      
      {
      "load_cost_forecast": {{ doubled_load_forecasts.all         | to_json }},
      "prod_price_forecast": {{ doubled_prod_price_forecasts.all  | to_json }},
      "pv_power_forecast": {{ pv_forecast                         | to_json }}
      }
  
  
  
  

  emhass_publish_data:
    url: "http://5b918bf2-emhass:5000/action/publish-data"
    method: POST
    headers:
      Content-Type: 'application/json'
    payload: '{}'

Just look at that Voodoo templates. I still don't know why I should add .all when populating lists. But it's not working without it. How I found it? Just reading page after page of people sharing configs. And this is HomeAssistant that almost plug and play now.

And I still didn't get to fun parts like ML. Because I need enough history for that and I just created the "load_no_var" sensor.

@nicolas-sora
Copy link

nicolas-sora commented Aug 17, 2024

Besides what everyone is writing, I also will say I got no deferrable loads so not sure what I should do there AND my inverter does not show at all, in fact Victron does not show at all when I would assume it's a well known brand...
For reference it's a Victron Multiplus II 48/5000/70-50 and I'm not even sure if it's relevant

It's also asking me for my panels incline and azimuth but not my latitude/long which would tell whether my incline is optimal and if my azimuth is correct given I'm in the southern hemisphere

@purcell-lab
Copy link
Contributor

Victron Multiplus II 48/5000/70-50

This guide should assist:

https://community.home-assistant.io/t/victron-integrated-with-ha-and-emhass-my-single-guide/449530?u=markpurcell

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

9 participants