Solution: Controlling OCPP charger through Home Assistant REST API

[mfuchs1984]

Intro

Motivation

In several discussions and issues, people had problems controlling their OCPP chargers through EVCC. In those cases, spec violations of chargers turned out to be the reason. On the other hand, some people claimed that their chargers are controllable through the Home Assistant custom OCPP integration. So just for the pleasure of learning something, I created a custom charger boilerplate to integrate such chargers through the Home Assistant REST API.

Main differences

The main differences between the EVCC OCPP integration and the Home Assistant integration are

1. The Home Assistant integration always starts and stops transactions to start and stop charging, while evcc expects the charger to start a transaction automatically (except when remotestart: true is configured) and stops charging by setting the current limit to 0.
2. The Home Assistant integration uses "chargingProfileKind": "Relative" while evcc uses "chargingProfileKind": "Absolute"
3. The Home Assistant integration uses "chargingProfilePurpose":"ChargePointMaxProfile" and in case of rejection falls back to "chargingProfilePurpose":"TxDefaultProfile" while evcc uses "chargingProfilePurpose":"TxDefaultProfile"

Among others, these differences might explain why some chargers work in Home Assistant but fail in EVCC (and maybe the other way around).

Prerequisites

1. You need a Home Assistant installation
2. Your need to have the custom OCPP integration https://github.com/lbbrhzn/ocpp/blob/main/README.md running with a connected OCPP charger
3. The Home Assistant REST API needs to be activated (just add api: to your Home Assistant configuration.yaml, see https://www.home-assistant.io/integrations/api/)
4. You need a "Long-Lived Access Token". This bearer token can be created under your profile in the security tab https://www.home-assistant.io/docs/authentication/#your-account-profile.

Add the charger to your evcc.yaml

Custom charger boilerplate

Add the following declaration to your evcc.yaml.

• Replace <CHARGER_NAME> with a charger name of your choice.
• Replace <HOME_ASSISTANT_IP> with the IP of your Home Assistant instance
• Replace <YOUR_BEARER_TOKEN> with the generated "Long-Lived Access Token"
• If your charger entities in Home Assistant are not named with the prefix charger_ (example charger_status_connector), change the prefix so it matches your installation

chargers:
  - name: <CHARGER_NAME>
    type: custom
    status:
      source: http
      uri: http://<HOME_ASSISTANT_IP>:8123/api/states/sensor.charger_status_connector
      jq: if .state == "Available" or .state == "Unavailable" then "A" elif .state == "Preparing" or .state == "SuspendedEVSE" or .state == "SuspendedEV" or .state == "Finishing" then "B" elif .state == "Charging" then "C" else "" end
      auth:
        type: bearer
        password: <YOUR_BEARER_TOKEN>
    enabled:
      source: http
      uri: http://<HOME_ASSISTANT_IP>:8123/api/states/switch.charger_charge_control
      jq: .state == "on"
      auth:
        type: bearer
        password: <YOUR_BEARER_TOKEN>
    enable:
      source: http
      uri: http://<HOME_ASSISTANT_IP>:8123/api/services/switch/{{if .enable}}turn_on{{else}}turn_off{{end}}
      method: POST
      body: "{\"entity_id\": \"switch.charger_charge_control\"}"
      auth:
        type: bearer
        password: <YOUR_BEARER_TOKEN>
    maxcurrent:
      source: http
      uri: http://<HOME_ASSISTANT_IP>:8123/api/services/number/set_value
      method: POST
      body: "{\"entity_id\": \"number.charger_maximum_current\", \"value\": \"${maxcurrent}\"}"
      auth:
        type: bearer
        password: <YOUR_BEARER_TOKEN>

Optional custom charger meter boilerplate

Optionally, add the following meter configuration to your evcc.yaml. In case no meter entities are available, evcc is able to run without it. It will then take the set current as charge current as a fallback. If single meters like power, energy, currents or voltages are not available, just remove the corresponding section. Units may also differ, so changing or adding might be necessary.

• Replace <CHARGE_METER_NAME> with a charger name of your choice.
• Replace <HOME_ASSISTANT_IP> with the IP of your Home Assistant instance
• Replace <YOUR_BEARER_TOKEN> with the generated "Long-Lived Access Token"
• If your charger entities in Home Assistant are not named with the prefix charger_ (example charger_status_connector), change the prefix so it matches your installation

meters:
  - name: <CHARGE_METER_NAME>
    type: custom
    power: 
      source: http
      uri: http://<HOME_ASSISTANT_IP>:8123/api/states/sensor.charger_power_active_import
      jq: .state
      scale: 1000
      auth:
        type: bearer
        password: <YOUR_BEARER_TOKEN>
    energy: 
      source: http
      uri: http://<HOME_ASSISTANT_IP>:8123/api/states/sensor.charger_energy_active_import_register
      jq: .state
      auth:
        type: bearer
        password: <YOUR_BEARER_TOKEN>
    currents:
      - source: http
        uri: http://<HOME_ASSISTANT_IP>:8123/api/states/sensor.charger_current_import
        jq: .attributes.L1
        auth:
          type: bearer
          password: <YOUR_BEARER_TOKEN>
      - source: http
        uri: http://<HOME_ASSISTANT_IP>:8123/api/states/sensor.charger_current_import
        jq: .attributes.L2
        auth:
          type: bearer
          password: <YOUR_BEARER_TOKEN>
      - source: http
        uri: http://<HOME_ASSISTANT_IP>:8123/api/states/sensor.charger_current_import
        jq: .attributes.L3
        auth:
          type: bearer
          password: <YOUR_BEARER_TOKEN>
    voltages:
      - source: http
        uri: http://<HOME_ASSISTANT_IP>:8123/api/states/sensor.charger_voltage
        jq: .attributes.L1
        auth:
          type: bearer
          password: <YOUR_BEARER_TOKEN>
      - source: http
        uri: http://<HOME_ASSISTANT_IP>:8123/api/states/sensor.charger_voltage
        jq: .attributes.L2
        auth:
          type: bearer
          password: <YOUR_BEARER_TOKEN>
      - source: http
        uri: http://<HOME_ASSISTANT_IP>:8123/api/states/sensor.charger_voltage
        jq: .attributes.L3
        auth:
          type: bearer
          password: <YOUR_BEARER_TOKEN>

Add charger to loadpoints

In case meters are available, use

loadpoints:
  - title: <your_charger_title>
    charger: <CHARGER_NAME>
    mode: <your_mode>
    meter: <CHARGE_METER_NAME>

otherwise

loadpoints:
  - title: <your_charger_title>
    charger: <CHARGER_NAME>
    mode: <your_mode>

@andig if this helps a couple of people, I could try to create Home Assistant OCPP API adapter templates.

[andig]

Main differences

@premultiply can we fix these?

I could try to create Home Assistant OCPP API adapter templates.

@mfuchs1984 sure!

[scruysberghs]

I just tried it with a charging station that wouldn't work with the evcc ocpp implementation but does work with the one in Home Assistant (enovates/chargewell station). Working well.
Only thing I had to change were the Voltages attributes for the meter. They are not called L1 etc but L1-N etc in my setup.

So I changed

    voltages:
      - source: http
        uri: http://<HOME_ASSISTANT_IP>:8123/api/states/sensor.charger_voltage
        jq: .attributes.L1
        auth:
          type: bearer
          password: <YOUR_BEARER_TOKEN>`

to read the L1-N attribute instead : jq: .attributes.L1-N

Other than that, worked fine.

Also, if you run evcc as an add-on you can use http://homeassistant:8123 to make the api calls, no need to use fill in the ip adress <HOME_ASSISTANT_IP>. "homeassistant" resolves from within an add-on container.

[mfuchs1984]

Nice to hear :) How the the measurand entities are called depends on how the charger reports them. According the the OCPP specs, L1 and L1-N are valid.