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". EVCC allows to optionally use relative profiles since Ocpp: add optional support for profileKind "relative" #22139
3. The Home Assistant integration uses "chargingProfilePurpose":"ChargePointMaxProfile" and in case of rejection falls back to "chargingProfilePurpose":"TxDefaultProfile" while evcc uses "chargingProfilePurpose":"TxDefaultProfile". See https://github.com/lbbrhzn/ocpp/wiki/Charge_automation#adjusting-the-charge-current and The right way to adjust charge current with a slider lbbrhzn/ocpp#1566 for more recommendations on the profiles and how to influence which type is used.

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.

[mfuchs1984]

Don't need to my Wallbox just doesn't work with the modbus template

So you don't think it could be fixed?

So my orignal question remains, do I add this config as a template in the doc?

Templates are not just about docs. To make this a generic template for a home assistant ocpp charger, some work is needed to expose certain things as template variables.

[andig]

Why can‘t we just use the evcc ocpp integration?

[jeremycoppey]

So you don't think it could be fixed?

Does my charger support Modbus? The internet and documentation is very confusing about it.
It works perfectly with the OCPP integration in HASS, (I understand that the EVCC community would like to see it working.)
So for me the solution where I expose it via hass API is perfect

Templates are not just about docs. To make this a generic template for a home assistant ocpp charger, some work is needed to expose certain things as template variables.

Willing to learn and to contribute.

[jeremycoppey]

Why can‘t we just use the evcc ocpp integration?

I will try that again with the generic one (https://docs.evcc.io/en/docs/devices/chargers#ocpp-16j-compatible), but it failed with some errors in the log,
I will set it up again and create a new Issue.

[jeremycoppey]

#23459 the issue i encounter with the generic OCPP template

[DanCherciu]

I have a Wallbox Pulsar Max which is working heratic using the evcc template, so I am thinking to give a try to your solution, but I am concerned that I read that also the OCPP add-on is not working well with my charger. What do you think using instead the standard Wallbox integration and adapt your custom charger accordingly? Wouldn't be more stable? Could be that the API call to wall-box may involve a too hifh delay making evcc unable to optimize the solar surplus?

[mfuchs1984]

concerned that I read that also the OCPP add-on is not working well with my charger.

At least the docs of the home assistant ocpp integration says it's working https://home-assistant-ocpp.readthedocs.io/en/latest/supported-devices.html#wallbox-pulsar-copper-sb

What do you think using instead the standard Wallbox integration and adapt your custom charger accordingly?

I don't understand what exactly you mean, what API should the custom charger use? To my knowledge, the only way is ocpp which is not well implemented by wallbox.com.

[DanCherciu]

You are right that in the docs says it's working but I read some recent discussion of the integration github where from I understood that there are some issues (like is not starting and it is necessary an workaround with an automation). My suggestion is related to install the official Wallbox add-on based on Wallbox cloud and its API and give up to OCPP. But my concern is related about how fast the wallbox cloud may offer data.

Anyway, I will give a try but I hust install the HA OCPP add-on and I did not figure yet why the charging is not starting and from Preparing is going directlly to SuspendedEV.

[premultiply]

The Home Assistant integration uses "chargingProfileKind": "Relative" while evcc uses "chargingProfileKind": "Absolute"

@mfuchs1984 this is outdated. Optional support for "relative" was added.

[premultiply]

The Home Assistant integration uses "chargingProfilePurpose":"ChargePointMaxProfile"

"ChargePointMaxProfile" is incorrect, as it addresses the entire charging station (sum), rather than a single connector.
This will fail immediately on any charging station with more than one connector.

[DanCherciu]

Sorry to seem a bit off topic, but I'm a beginner in using Pulsar Max on OCPP, but I decided to choose this charger because it is supported by evcc, at least in the documentation. To use the solar surplus, I tried using evcc and the native Pulsar Max template, but I have a problem with a random current mismatch (measured 32A, expected 6A) and refuse disable. To solve the problem, I'm thinking of using evcc by integrating the OCPP HA add-on, but I'm afraid that being a firmware issue, I'll be wasting my time. Can you give me your opinion, if you have experience with this major problem? Thanks in advance! 🙏🏻

[mfuchs1984]

@DanCherciu evcc has some means to address a couple of issues with wrong measurands and you could also try to use relative profiles.

You should create an extra discussion with an evcc ocpp trace log that shows the problem.