pail23 / energy-assistant-backend

MIT License
2 stars 1 forks source link

I'm very interested to try this out. #70

Closed gieljnssns closed 10 months ago

gieljnssns commented 11 months ago

I'm very interested to try this out. Can you give an example for the energy_assistant.yaml file?

pail23 commented 11 months ago

I have update the energy_assistant.yaml.dist file. This should give you a good basis for using Energy Assistant as a Home Assistant Addon. I will work on some documentation. In case you would like to use this as stand alone in a docker container, you would need to add

homeassistant:
  url: https://homeassistant.example.net
  token: "your long lived home assistant token"

to your config file.

Please bear in mind: This is still in it's early days. Expect things not to run smooth. I'm curious to learn how it's going and I'm happy to receive PRs.

gieljnssns commented 11 months ago

Thanks for the info. Does grid_supply_power need to be positive or negative for exporting?

pail23 commented 11 months ago

grid_supply_power < 0: import energy from the grid

gieljnssns commented 11 months ago

My home-assistant sensor is < 0 export to the grid. Can I use some scale_factor: -1

pail23 commented 11 months ago

No, this is at the moment only possible for the energy sensor (not power). What you can do is create a template entity in home assistant

gieljnssns commented 11 months ago

For energy assistant we need to provide more sensors then for emhass only. For the emhass configuration we need to provide days_to_retrieve: x Is x only for the sensors used by emhass? Or also for the other sensors used by energy assistant? I ask this because I have other recorder settings for those sensors.

gieljnssns commented 11 months ago

No, this is at the moment only possible for the energy sensor (not power)

Emhass hass this setting load_negative: False

pail23 commented 11 months ago

days_to_retrieve and load_negative are for emhass only. Adding an option to invert or scale power as well is a good idea. It's in the backlog.

gieljnssns commented 11 months ago

What is the difference between type: homeassistant and type: power-state-device?

pail23 commented 11 months ago

I have added some documentation here. Does this clarify the point?

gieljnssns commented 11 months ago

Thanks for the clarification...

gieljnssns commented 11 months ago

I can't get it to work energy_assistant.yaml

home:
  name: "Nummer 79"
  solar_power: sensor.emhass_huidige_opbrengst
  solar_energy: sensor.opbrengst_kwh
  grid_supply_power: sensor.huidig_fluvius
  imported_energy: sensor.grid_consumption_kwh
  exported_energy: sensor.grid_production_kwh
  devices:
    - name: Wasmachien
      id: dff35eb8-ff9f-4009-b217-f416ffd1e73c
      type: homeassistant
      power: sensor.wasmachien_vermogen
      energy: sensor.wasmachien_kwh
      store_sessions: true
      # manufacturer: Miele
      # model: Adora TS WP
    - name: Droogkast
      id: 75203c88-216f-4712-8a94-80513793f7e1
      type: homeassistant
      power: sensor.droogkast_vermogen
      energy: sensor.droogkast_kwh
      store_sessions: true
      # manufacturer: Miele
      # model: Adora TS WP
    - name: Afwasmachien
      id: 3abcf4d9-5434-4675-bb84-eb7f3afc252d
      type: homeassistant
      power: sensor.afwasmachien_vermogen
      energy: sensor.afwasmachien_kwh
      store_sessions: true
      # manufacturer: Miele
      # model: Adora TS WP
    - name: Warmtepompboiler
      id: 19442b42-7c3c-4692-ace6-61384d62fb70
      type: homeassistant
      power: sensor.warmtepompboiler_huidig_verbruik
      energy: sensor.warmtepompboiler_kwh
      store_sessions: true
      # manufacturer: Masser
      # model: M1
    - name: Warmtepomp
      id: cccdd0c5-b07e-468a-ad4e-6d0c8baf2956
      type: homeassistant
      power: sensor.warmtepomp_huidig_verbruik
      energy: sensor.warmtepomp_kwh
      store_sessions: true
      # manufacturer: Masser
      # model: M2

emhass:
  retrieve_hass_conf:
    - freq: 30 # The time step to resample retrieved data from hass in minutes
    - days_to_retrieve: 3 # We will retrieve data from now and up to days_to_retrieve days
    - load_negative: False # Set to True if the retrived load variable is negative by convention
    - set_zero_min: True # A special treatment for a minimum value saturation to zero. Values below zero are replaced by nans
    - method_ts_round: "first" # Set the method for timestamp rounding, options are: first, last and nearest

  optim_conf:
    - set_use_battery: False # consider a battery storage
    - delta_forecast: 1 # days
    - weather_forecast_method: "scrapper" # options are 'scrapper' and 'csv'
    - load_forecast_method: "naive" # options are 'csv' to load a custom load forecast from a CSV file or 'naive' for a persistance model
    - load_cost_forecast_method: "hp_hc_periods" # options are 'hp_hc_periods' for peak and non-peak hours contracts and 'csv' to load custom cost from CSV file
    - list_hp_periods: # list of different tariff periods (only needed if load_cost_forecast_method='hp_hc_periods')
        - period_hp_1:
            - start: "02:54"
            - end: "15:24"
        - period_hp_2:
            - start: "17:24"
            - end: "20:24"
    - load_cost_hp: 0.1907 # peak hours load cost in €/kWh (only needed if load_cost_forecast_method='hp_hc_periods')
    - load_cost_hc: 0.1419 # non-peak hours load cost in €/kWh (only needed if load_cost_forecast_method='hp_hc_periods')
    - prod_price_forecast_method: "constant" # options are 'constant' for constant fixed value or 'csv' to load custom price forecast from a CSV file
    - prod_sell_price: 0.065 # power production selling price in €/kWh (only needed if prod_price_forecast_method='constant')
    - set_total_pv_sell: False # consider that all PV power is injected to the grid (self-consumption with total sell)
    - lp_solver: "PULP_CBC_CMD" # set the name of the linear programming solver that will be used
    - lp_solver_path: "empty" # set the path to the LP solver
    - set_nocharge_from_grid: False # avoid battery charging from the grid
    - set_nodischarge_to_grid: True # avoid battery discharging to the grid
    - set_battery_dynamic: False # add a constraint to limit the dynamic of the battery power in power per time unit
    - battery_dynamic_max: 0.9 # maximum dynamic positive power variation in percentage of battery maximum power
    - battery_dynamic_min: -0.9 # minimum dynamic negative power variation in percentage of battery maximum power

  plant_conf:
    - P_grid_max: 9000 # The maximum power that can be supplied by the utility grid in Watts
    - module_model: # The PV module model
        - "CSUN_Eurasia_Energy_Systems_Industry_and_Trade_CSUN295_60M"
    - inverter_model: # The PV inverter model
        - "Fronius_International_GmbH__Fronius_Primo_5_0_1_208_240__240V_"
    - surface_tilt: # The tilt angle of your solar panels
        - 30
    - surface_azimuth: # The azimuth angle of your PV installation
        - 205
    - modules_per_string: # The number of modules per string
        - 16
    - strings_per_inverter: # The number of used strings per inverter
        - 1
    - Pd_max: 1000 # If your system has a battery (set_use_battery=True), the maximum discharge power in Watts
    - Pc_max: 1000 # If your system has a battery (set_use_battery=True), the maximum charge power in Watts
    - eta_disch: 0.95 # If your system has a battery (set_use_battery=True), the discharge efficiency
    - eta_ch: 0.95 # If your system has a battery (set_use_battery=True), the charge efficiency
    - Enom: 5000 # If your system has a battery (set_use_battery=True), the total capacity of the battery stack in Wh
    - SOCmin: 0.3 # If your system has a battery (set_use_battery=True), the minimun allowable battery state of charge
    - SOCmax: 0.9 # If your system has a battery (set_use_battery=True), the minimun allowable battery state of charge
    - SOCtarget: 0.6 # If your system has a battery (set_use_battery=True), the desired battery state of charge at the end of each optimization cycle

Errors in addon

INFO  [alembic.runtime.migration] Context impl SQLiteImpl.
INFO  [alembic.runtime.migration] Will assume non-transactional DDL.
INFO  [alembic.runtime.migration] Running upgrade  -> 0bf7066b6d6c, First commit.
INFO  [alembic.runtime.migration] Running upgrade 0bf7066b6d6c -> d43efed24fbc, Drop date column
INFO  [alembic.runtime.migration] Running upgrade d43efed24fbc -> efac279d8401, create device table
INFO  [alembic.runtime.migration] Running upgrade efac279d8401 -> b6020d5b13fc, create session log table
INFO  [alembic.runtime.migration] Running upgrade b6020d5b13fc -> 81f94b4136ee, Added power_mode
INFO:     Started server process [9]
INFO:     Waiting for application startup.
2023-10-07 16:45:01.437 INFO (MainThread) [root] Hello from Energy Assistant
2023-10-07 16:45:01.438 INFO (MainThread) [root] config_file=/config/energy_assistant.yaml
2023-10-07 16:45:01.438 INFO (MainThread) [root] log_level=debug
2023-10-07 16:45:01.442 INFO (MainThread) [root] Loading config file /config/energy_assistant.yaml
2023-10-07 16:45:01.453 INFO (MainThread) [root] suvervisor token detected. len=112
2023-10-07 16:45:01.498 INFO (MainThread) [root] pinging homeassistant api succeeeded. Status code = 200
2023-10-07 16:45:01.498 INFO (MainThread) [root] Using http://supervisor/core to connect
2023-10-07 16:45:01.690 INFO (MainThread) [root] Initialization completed
2023-10-07 16:45:01.693 INFO (MainThread) [apscheduler.scheduler] Adding job tentatively -- it will be properly scheduled when the scheduler starts
2023-10-07 16:45:01.694 INFO (MainThread) [apscheduler.scheduler] Added job "daily_optimize" to job store "default"
2023-10-07 16:45:01.694 INFO (MainThread) [apscheduler.scheduler] Scheduler started
2023-10-07 16:45:01.694 INFO (MainThread) [energy_assistant] Setting up needed data
2023-10-07 16:45:01.696 INFO (MainThread) [energy_assistant] Retrieve hass get data method initiated...
2023-10-07 16:45:01.839 ERROR (MainThread) [energy_assistant] The retrieved JSON is empty, check that correct day or variable names are passed
2023-10-07 16:45:01.840 ERROR (MainThread) [energy_assistant] 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-10-07 16:45:01.840 ERROR (MainThread) [root] Optimization failed
Traceback (most recent call last):
  File "/app/app/main.py", line 415, in optimize
    optimizer.forecast_model_fit()
  File "/app/app/EmhassOptimizer.py", line 357, in forecast_model_fit
    self._retrieve_hass.get_data(days_list, var_list)
  File "/app/emhass/retrieve_hass.py", line 145, in get_data
    self.df_final = pd.concat([self.df_final, df_day], axis=0)
                                              ^^^^^^
UnboundLocalError: cannot access local variable 'df_day' where it is not associated with a value
INFO:     Application startup complete.
INFO:     Uvicorn running on http://0.0.0.0:5000 (Press CTRL+C to quit)
2023-10-07 16:45:31.783 ERROR (MainThread) [root] error during sending refresh
Traceback (most recent call last):
  File "/app/app/main.py", line 67, in async_handle_state_update
    state_repository.read_states()
  File "/app/app/devices/__init__.py", line 298, in read_states
    repository.read_states()
    ^^^^^^^^^^^^^^^^^^^^^^
AttributeError: 'NoneType' object has no attribute 'read_states'
pail23 commented 11 months ago

The first error message from emhass is related to the fact, that the history of sensor.power_load_no_var_loads is not long enough. This entity is used by Energy Assistant to store the the non variable load (ie all power consumption which is not managed by Energy Assistant). Emhass reads this variable as well. This error will go away once the system is running for more than days_to_retrieve days (in your case 3). This is not ideal and needs some refactoring.

The second error is a bug which I fix in the lastest version in the repository (not released yet).

Please get the latest changes from github and try again.

gieljnssns commented 11 months ago

Where do I define sensor.power_load_no_var_loads

pail23 commented 11 months ago

At the moment this entity name is hard coded. Once Energy Assistant is running properly, it will push this entity to Home Assistant. Emhass will then be able to consume this variable. Nevertheless, I should still be able to start Energy Assistant without having enough history data in Home Assistant. Maybe the forcasting part in Energy Assistant will not run properly, the rest should be fine. Once Energy Assistant is running for 3 days, this issue should be gone.