EMHASS: An Energy Management for Home Assistant

Tesla HACS uses the API call for charging.

You can extend the history for only certain entities so the current database is more than sufficient.

I am between load forecasters at the moment;

        "load_power_forecast": {{
          ([states('sensor.power_load_no_var_loads')|int] +
          states('sensor.hvac_power_forecast') | from_json | map('multiply', 1000) | list 
          )| tojson 
        }}, 

My HVAC was my dominant load over summer so I was just using that as the default and slipping in power_load_no_var_loads as the first element to give me the now value.

I was using the Tesla Custom integration from HACS which provides you direct controls, but that is broken at the moment due to API changes.

I am having great success with the new Teslemetery integration (HACS version has leading features) to provide full control over powerwall.

@markpurcell I have a similar automation for my Tesla. However the Tesla Wall Charger still indicates the it is using 800w despite setting the car to 0 amps. It goes down to 4w if I stop the car charging. Does your car draw any power from the charger when you set it to 0 amps?

Iā€™m running Tesla HTTP Proxy to get my Tesla Custom Integration working

1 Like

Ok thanks but now itā€™s like Iā€™m having a hard time knowing how to add it to my code can anyone help me?

####EMHASS######################################################################
publish_data: 'curl -i -H "Content-Type:application/json" -X POST -d ''{}'' http://localhost:5000/action/publish-data'
##
dayahead_optim: 'curl -i -H ''Content-Type: application/json'' -X POST -d ''{
  "load_cost_forecast":{{((state_attr(''sensor.nordpool_kwh_se3_sek_3_10_025'', ''raw_today'') | map(attribute=''value'') | list  + state_attr(''sensor.nordpool_kwh_se3_sek_3_10_025'', ''raw_tomorrow'') | map(attribute=''value'') | list))[now().hour:][:24] }},
  "prod_price_forecast":{{((state_attr(''sensor.nordpool_moms'', ''raw_today'') | map(attribute=''value'') | list  + state_attr(''sensor.nordpool_moms'', ''raw_tomorrow'') | map(attribute=''value'') | list))[now().hour:][:24] }},
  "prediction_horizon":{{min(24, (((state_attr(''sensor.nordpool_moms'', ''raw_today'')|map(attribute=''value'')|list + state_attr(''sensor.nordpool_moms'', ''raw_tomorrow'') | map(attribute=''value'')| list)[now().hour:][:48]|list|length)))}},
  "pv_power_forecast":{{([states(''sensor.solcast_pv_forecast_power_now'')|int(0)] + state_attr(''sensor.solcast_pv_forecast_forecast_today'', ''detailedHourly'')|selectattr(''period_start'',''gt'',utcnow()) | map(attribute=''pv_estimate'')|map(''multiply'',1000)|map(''int'')|list + state_attr(''sensor.solcast_pv_forecast_forecast_tomorrow'', ''detailedHourly'')|selectattr(''period_start'',''gt'',utcnow()) | map(attribute=''pv_estimate'')|map(''multiply'',1000)|map(''int'')|list)| tojson}},
  "delta_forecast":2 
  }'' http://localhost:5000/action/dayahead-optim'
##
mpc: 'curl -i -H ''Content-Type: application/json'' -X POST -d ''{
  "load_cost_forecast":{{((state_attr(''sensor.nordpool_kwh_se3_sek_3_10_025'', ''raw_today'') | map(attribute=''value'') | list  + state_attr(''sensor.nordpool_kwh_se3_sek_3_10_025'', ''raw_tomorrow'') | map(attribute=''value'') | list))[now().hour:][:24] }},
  "prod_price_forecast":{{((state_attr(''sensor.nordpool_moms'', ''raw_today'') | map(attribute=''value'') | list  + state_attr(''sensor.nordpool_moms'', ''raw_tomorrow'') | map(attribute=''value'') | list))[now().hour:][:24] }},
  "prediction_horizon":{{min(24, (((state_attr(''sensor.nordpool_moms'', ''raw_today'')|map(attribute=''value'')|list + state_attr(''sensor.nordpool_moms'', ''raw_tomorrow'') | map(attribute=''value'')| list)[now().hour:][:48]|list|length)))}},
  "pv_power_forecast":{{([states(''sensor.solcast_pv_forecast_power_now'')|int(0)] + state_attr(''sensor.solcast_pv_forecast_forecast_today'', ''detailedHourly'')|selectattr(''period_start'',''gt'',utcnow()) | map(attribute=''pv_estimate'')|map(''multiply'',1000)|map(''int'')|list + state_attr(''sensor.solcast_pv_forecast_forecast_tomorrow'', ''detailedHourly'')|selectattr(''period_start'',''gt'',utcnow()) | map(attribute=''pv_estimate'')|map(''multiply'',1000)|map(''int'')|list)| tojson}},
  "delta_forecast":2
  }'' http://localhost:5000/action/naive-mpc-optim'
##
forecast_model_fit: curl -i -H "Content-Type:application/json" -X POST -d '{}' http://localhost:5000/action/forecast-model-fit
####END#########################################################################

Ok Tesla HACS :+1:

Interesting using HVAC to represent consumption history. If it can be that approximate I might make something up. Perhaps an average of a weeks load no var.

Thanks

Another strategy I have been using is a FIFO buffer of 48 elements that moves one to the left every 30 minutes.

Yes I still see ~ 400 W with the Tesla Wall connector Even if I set 0A, Iā€™m on three phase.

Interestingly with the Universal Wall Connector when I set 0 A it stops drawing power.

It is a challenge as I donā€™t want to switch the master control on and off continuously.

The Charge on Solar option from Tesla does also stop the power draw, but those endpoints arenā€™t (yet) controlled by the API. CoS seems to be good for this at the end and start of the day as well as overnight as it prevents the phantom draw.

You can add it to MPC before delta_forecast

 "soc_init": {{ max(0,states('sensor.energy_site_percentage_charged')|int(0))/100 }},
 "soc_final": {{ max(100,states('sensor.gateway_battery')|int(0))/100 }},

Replace the sensor entities with your values.

Tnx, will try it

@GeoDerp
Iā€™m not sure if this issue is really fixed. Sometimes I have this error again. Today again:

    raise ValueError(
ValueError: Length mismatch: Expected axis has 0 elements, new values have 23 elements

I only have this part in my log. Where can I access the full log?

Can someone explain if I have understood this setting correctly? did it mean how fast per in my case a 60 minute session the battery is charged?

battery_target_state_of_charge: 0.2

Thanks Mark.
Iā€™ve updated my EV charging deferrable automation to turn off charging when its 0w and to turn it back on when its >0w (in addition to setting the charging amps)

1 Like

I understand the line with the value for soc_init, but what does soc_final contain for you, or what is in the entity ā€œsensor.gateway_batteryā€™ā€?

Hello,

I am recently having issues while running the rest command automation.

I am having this configuration regarding rest_command for day ahead optimization:

  dayahead_optim_rest:
    url: http://localhost:5000/action/dayahead-optim
    method: POST
    content_type: "application/json"
    payload: >-
      {
        "prediction_horizon": {{
        min(48, state_attr('sensor.entsoe_prices_forecast_30', 'prices')|length |int) | tojson 
        }},
        "pv_power_forecast": {{ 
        (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
        }}, 
        "load_cost_forecast": {{
        state_attr('sensor.entsoe_prices_forecast_30', 'prices') |tojson 
        }},
        "num_def_loads": 1,
        "def_total_hours": [4],
        "P_deferrable_nom":  [2500],
        "treat_def_as_semi_cont": [0],
        "set_def_constant": [1]
      } 

Running the curl command manually in terminal works fine.

But running in automation mode , I see following entry in log file:

2024-03-29 22:44:10.342 ERROR (MainThread) [homeassistant.helpers.script.websocket_api_script] websocket_api script: Error executing script. Error for call_service at pos 1: Timeout when calling resource 'http://localhost:5000/action/dayahead-optim'

Any pointers anyone?

Thank you!

That is the value you want the battery at the end of the optimisation, ie the end of the 24 hours.

Do some experimentation, I have played around with setting it to zero, so the battery is planned on being fully discharged, or the same as the init value. Currently Iā€™m using 100 % so the plan is always to have a full battery in 24 hours.

Copy the rest command into the developer tools template to see what it is being expanded to.

Hello, just a heads-up to the community there may still be a bug with the time change; check your log.
Iā€™ve already reported it on github.

Can someone explain if I have understood this setting correctly? did it mean how fast per in my case a 60 minute session the battery is charged?

battery_target_state_of_charge: 0.2

Donā€™t know if itā€™s allowed in the forum but I bump my question

This is the desired status of charge of your battery at the end of the horizon (typically 24 h) you are optimizing.