support for charging stations with multuple connectors?

[scruysberghs]

Hi,

I'm trying to use a charging station that has 2 connectors to charge 2 EV's at the same time. I see it is supported in the ocpp.set_charge_rate service (conn_id 0 is charging station, conn_id 1 for first connector and conn_id 2 for second connector). This means I can set the charging speed for both connectors individually and can confirm this works. Now for the sensors that are created by the integration I don't see any support for this. Also only one slider and set of switches to control charging in the UI. Is full support for multiple sockets (or even multiple charging stations) somewhere on the roadmap for this OCPP HA integration/addon?

Regards
Steven

[drc38]

It's not something I intend to work on, but it shouldn't be difficult to add if you want to create a PR for it.

[drc38]

The scripts folder sets up the Dev environment, including HA provided by https://github.com/MatthewFlamm/pytest-homeassistant-custom-component

[scruysberghs]

Ah, I see. So the dev container is indeed supposed to clone in the ha repo. On my Ubuntu dev machine something goes wrong with this. I've also tried using the oncleben31 cookiecutter that is linked in MatthewFlamm's repo to create a new custom component and that one fails to set up the environment in the devcontainter as well on my machine. Looks like the project is no longer maintained. Have you used it successfully recently with a clean clone of your repo?

The logs indicate it is trying to do git clone -q git://github.com/home-assistant/home-assistant.git and times out instead of cloning [email protected]:home-assistant/core.git

[drc38]

The cookie cutter dev container is sunset. This repo has been updated with the new container/scripts etc

[drc38]

Have you merged the updates from main that changed the dev setup into your repo?

[scruysberghs]

with a clean check-out of the repo I had a (different) problem as well. There was a message that the pytest-homeassistant-custom-component version that was pinned in requirements.txt is not supported on python 3.11. Made a small PR that upgrades the devcontainer to use python 3.12 and bumped pytest-homeassistant-custom-component to the lastest version "0.13.148"

[jhaarden]

Hi! Did you have any success with this work, @scruysberghs?

It looks like the most recent version of this component still does not have support for multi-connector chargers, so I started to work on it some days ago. I have had fairly good success with adding transaction ID and metrics for individual connectors, but now I am a bit stuck on one thing - I would like to add an infix in the entity names (e.g., connector1_) when there are multiple connectors, while keeping the names as-is for all HA entities when the charger has only one connector. This is both for backwards compatibility, but also because it doesn't make sense to have a sensor named e.g., sensor.charger_connector1_current_export when there is only one connector available.

It seems that, to be able to achieve this, we need to do some of what is today done in post_connect() already in the middle of the config flow. I am thinking specifically about the call to ChargePoint.get_number_of_connectors(). However, this could also be useful for querying what measurands the charger supports before showing the config flow page where the user should select which measurands the charger should report.

@drc38: are there technical reasons that would prevent us from awaiting a boot notification in the config flow and perform some GetConfiguration calls to the charger, to provide correct information in the config flow? I have read the code back and forth quite some times now, but I suppose that there may be quirks with some specific chargers which would prevent this.

[drc38]

I don't think it's possible in post_connect as the HA sensors have already been created/setup (unless you add extra code just for creating the new connector sensors).

My suggestion would be to add the number of connectors to the charger config flow for manual input. Then if > 1 enumerate relevant sensors eg sensor.charger_current_export + '_' + n-1 or similar to be backwards compatible

Post_connect could use GetConfiguration to check the manual entry matches and issue warning if there's a mismatch.

[drc38]

Re-read your message and see you're suggesting trying to do so in the config flow. I still can't see that working as the creation of the server side representation of the chargepoint (1.6 or 2.0.1) comes after the config flow.

[jhaarden]

Re-read your message and see you're suggesting trying to do so in the config flow. I still can't see that working as the creation of the server side representation of the chargepoint (1.6 or 2.0.1) comes after the config flow.

I understand. It means that major rework would be needed to support a more dynamic config flow based on information from the charger itself.

My suggestion would be to add the number of connectors to the charger config flow for manual input. Then if > 1 enumerate relevant sensors eg sensor.charger_current_export + '_' + n-1 or similar to be backwards compatible

Yes, I will go with this solution, at least for the first PR. Shouldn't be too difficult.

[drc38]

A staged approach sounds good, I'm not familiar with more advanced config flows but it would be useful if a dynamic setup can be done.