DIY smart grid: EV (Tesla) charging on excess solar power production

I’m not too smart… but i’m trying to follow the steps to install the tesla smart charging automations… I’m running into 2 problems.

  1. the configs keep returning this error “Configuration errors
    Error loading /config/configuration.yaml: mapping values are not allowed here
    in “/config/packages/charging.yaml”, line 230, column 75”

It seems to point at some html style attribute style="word-wrap: break-word;" If i remove it, it just goes to the next style attribute. Anyone know what is going wrong here?

Thanks!

just for everyone else. It’s a EOL issue. Just download the script, put it onto home assistant untouched and use the built in editor to make the changes described (i.e. amps voltage etc…)

As much as some might appreciate reading about your struggles in getting this to work, it isn’t contributing very much to the topic. :wink: All issues (and possible solutions) related to the installation and usage of the Tesla Smart Charging scripts (which are not created nor maintained by me) can be posted to the Github page maintained by @dazboj.

This kind of charging control will fail to work properly (using @dazboj’s script, my manual scripting logic or otherwise) as long as your inverter cannot be controlled from inside Home Assistant. Having the sensors available is part of the solution, but not enough. You will need the automation logic to control setting the inverter to charge or supply power in all the cases you described. Are you able to control the inverter (for instance, override it’s settings to NOT CHARGE in case it normally would)?

Yes, I am able to control everything related to Huawei, Luna 200 and Smart meter, the screen shots I’ve posted are not the only ones.
Anyway I solved my problem with Tesla charging from battery.

As you can see, I can control the charge and discharge rate and I made an automation which sets the discharge rate of the Luna2000 battery to 0W when Tesla Wall Connector contactor is closed. I used Wall’s connector entity because it is local integrated and the reaction time is very fast. In fact I used 2 simple automations:

  • Tesla not charge - Luna start discharge:

alias: Tesla not charge - Luna start discharge
description: “”
trigger:

  • platform: state
    entity_id:
    • binary_sensor.tesla_wall_connector_contactor_closed
      from: “on”
      to: “off”
      condition:
      action:
  • device_id: afceccda489d678f829bc132a3d44b38
    domain: number
    entity_id: 1c85d565399e79049baade789b4b8271
    type: set_value
    value: 2500
    mode: single

Tesla charge - Luna stop discharge:

alias: Tesla charge - Luna stop discharge
description: “”
trigger:

  • platform: state
    entity_id:
    • binary_sensor.tesla_wall_connector_contactor_closed
      from: “off”
      to: “on”
      condition:
  • condition: state
    entity_id: device_tracker.tesla_location_tracker
    state: home
    action:
  • device_id: afceccda489d678f829bc132a3d44b38
    domain: number
    entity_id: 1c85d565399e79049baade789b4b8271
    type: set_value
    value: 0
    mode: single

Basicaly as long as the Wall connector is closed for charging which is controlled by the Tesla smart charging automation, I disable the battery capability of discharging.
If there is not enough juice from the sun + house consumption to charge Tesla, then anyway Tesla smart charging will disable charging, therefore the Wall connector will disengage the charging contactor and the “Tesla not charge - Luna start discharge” automation will run.

  • for “Tesla charge - Luna stop discharge” automation I used the location tracker condition.

Thank you very much for answering.

1 Like

Good to hear that it’s working out for you. I can’t really read what the automation says (I would recommend using the correct formatting in the post editor), but at first glance it looks like a general way I would go about it. For my personal preference I would use an input boolean (for instance, setting this to on when the car is plugged in AND in need of charge AND at home). This way you can re-use the boolean state elsewhere in different use case automations or even override the boolean status (setting the boolean differently, as opposed to a binary sensor state). If for any means and purposes you would still need or want a binary sensor, you could derive that from the input boolean state. Usefull use-cases for an override could be that your car is low on charge and you need to ‘repurpose’ the juice from the LUNA to the car, or you could implement a minimum car charge (e.g. 20%) before the charger rate limiting starts working.