Templates and automations etc.

[JohanAlvedal]

Is it possible to create folders here on github where you can upload different examples of shellscripts, automations for different inverters, etc.?

[martinarva]

If anybody is interested i made flow for Deye inverter in node-red.

[JohanAlvedal]

I have made automations, scripts, etc. for Huawei with Luna200 battery. which is controlled with SOC and power forecast.

[davidusb-geek]

Great idea!
But I don't think that we can upload files to a folder. However we can do it directly in this discussion, I can see that when you add a comment there is an icon to attach a file to your comment, so can use that.
Another option is to upload your templates and examples directly as a code block in your comments.

[BDVGitHub]

Its possible to add images to the wiki page by drag and drop, maybe this also works for files?
https://github.blog/changelog/2022-02-14-upload-images-to-wiki-pages/

Or maybe create an templates folder like they did here https://github.com/gogs/gogs to upload scipts, automations, .... ?

[JohanAlvedal]

Here you will find my files that are suitable for Huawei and Luna2000 battery

https://github.com/JohanAlvedal/homeautomation/tree/main/Emhass

[RudolfRendier]

I like to suggest the following format for all shell_commands:

  emhass_perfect_optim: >
    curl -i -H "Content-Type:application/json" -X POST -d '{{payload}}' http://localhost:5000/action/perfect-optim

Mainly because they cannot be reloaded without restarting HA.

This also allows using an automation and variables to fill the payload:

id: bbb661ac-2094-4b06-ada2-f93f91ba3a7b
alias: "EMHASS: Dayahead optimization"

trigger:
  - platform: time
    at: "05:34:56"

variables:
  soc_min: 0.05
  soc_max: 1
  soc_init: >
    {{ states("sensor.soc_battery") | float(default=0) / 100.0 }}
  pd_max: 400
  pc_max: 350
  load_cost_forecast: >
    {% set now = now() %}
    {% set high = 0.26644 %}
    {% set low = 0.26402 %}
    {% set end_time = now + timedelta(hours=24) %}
    {% set data = namespace(tariffs=[]) %}
    {% for period_start in range(0, 48, 1) %}
      {% if (period_start >= 23 or period_start <= 7) or (now.weekday() >= 5 or end_time.weekday() <= 1) %}
        {% set tariff = low %}
      {% else %}
        {% set tariff = high %}
      {% endif %}
      {% set data.tariffs = data.tariffs + [tariff] %}
    {% endfor %}
    {{ data.tariffs[:48] }}

  pv_p_fc: >
    {% set today = state_attr('sensor.solcast_pv_forecast_forecast_today', 'detailedForecast') | selectattr('period_start', 'gt', utcnow()) | map(attribute='pv_estimate') | map('multiply',1000) | map('int') | list %}
    {% set tomorrow = state_attr('sensor.solcast_pv_forecast_forecast_tomorrow', 'detailedForecast') | map(attribute='pv_estimate') | map('multiply', 1000)| map('int') | list %}
    {{ today + tomorrow[:48] }}

action:
  - service: shell_command.emhass_dayahead_optim
    data:
      payload: >
        {"SOCmax": {{ soc_max }}, "SOCmin": {{ soc_min }}, "SOCtarget": {{ soc_init }}, "Pd_max": {{ pd_max }}, "Pc_max": {{ pc_max }}, "weather_forecast_cache_only": true, "pv_power_forecast": {{ pv_p_fc }}, "load_cost_forecast": {{ load_cost_forecast }} }
        

[JohanAlvedal]

Smart, now it's just a matter of figuring out how it should look.

[purcell-lab]

Mainly because they cannot be reloaded without restarting HA.

This is a great improvement and would also work well with the rest integration to have the payload specified in this fashion.

Not having to reboot HA every time a change is great for debugging and making quick changes.

[RudolfRendier]

I created a separate automation to publish_data, that can be given a prefix to publish with.

id: 893d1d98-c084-4f4c-b5b2-afa207c8fbb5
alias: "EMHASS: Publish data"
mode: queued
max_exceeded: silent

trigger:
  - platform: event
    event_type: emhass_update

# Give EMHASS some time to perform its calculations
action:
  - delay:
      seconds: 10

  - service: shell_command.emhass_publish_data
    data:
      payload: >
        {"publish_prefix": "{{ trigger.event.data.prefix }}"  }

Both my dayahead and MPC generate the event triggering the publish, with different prefixes.
Both the Dayahead and MPC publish without prefix, so the MPC overwrites the Dayahead, so that's what automations should follow.
The results from the dayahead are kept under prefix 'dh_' for reference.

  - event: emhass_update
    event_data:
      type: dayahead
      prefix: dh_

  - event: emhass_update
    event_data:
      type: dayahead
      prefix: ""

My MPC sometimes yields unfeasible results, so I have a guard to prevent publishing those results (for now):

  # Publish with prefix for model comparison
  - event: emhass_update
    event_data:
      type: mpc
      prefix: mpc_

  - delay:
      seconds: 20

  - condition: template
    value_template: "{{ is_state('sensor.mpc_optim_status', 'Unfeasible') }}"

  # Publish without prefix for automations to follow
  - event: emhass_update
    event_data:
      type: mpc
      prefix: ""

I have a battery optimization automation that uses the non-prefixed forecast. It doesn't care if the source is the dayahead or the MPC.

[RudolfRendier]

Home Assistant 2024.11 supports template blueprints, maybe EMHASS can benefit from those:

https://www.home-assistant.io/integrations/template/#using-blueprints

[BDVGitHub]

Great idea I've created an seperate discussion for this see #402