Garo Entity Pro with load balancer

[munterkalmsteiner]

Describe the bug Garo Entity Pro with load balancer (Garo Entity Balance) do not register correctly with the central system. The balancer serves as a dynamic load manager and is configured to connect to the central system. The setup is described here on page 44 onwards.

In OCPP (v0.5.0), only the load balancer registers. No connectors are reported. Charging can be initiated (in the logs I can see the command is accepted), but charging does not start.

On the status page of the load balancer, I can see that the connection to the CSMS is established. On the charger, the connection is not established (status: pending).

In the logs, I can only see traces of the load balancer (Garo-LI):

2024-01-11 18:39:41.915 INFO (MainThread) [ocpp] GaroLI-4C3B6C039860: send [2,"cd0a4bd5-7538-43c3-9eef-f65ca80a7e8e","GetConfiguration",{"key":["SupportedFeatureProfiles"]}]
2024-01-11 18:39:41.955 INFO (MainThread) [ocpp] GaroLI-4C3B6C039860: receive message [3,"cd0a4bd5-7538-43c3-9eef-f65ca80a7e8e",{"configurationKey":[{"key":"SupportedFeatureProfiles","readonly":true,"value":"Core,FirmwareManagement,LocalAuthListManagement,SmartCharging,RemoteTrigger"}]}]
2024-01-11 18:39:41.956 INFO (MainThread) [ocpp] GaroLI-4C3B6C039860: send [2,"1bc53b39-b413-4976-8960-cd986c81ecab","GetConfiguration",{"key":["NumberOfConnectors"]}]
2024-01-11 18:39:42.184 INFO (MainThread) [ocpp] GaroLI-4C3B6C039860: receive message [3,"1bc53b39-b413-4976-8960-cd986c81ecab",{"configurationKey":[{"key":"NumberOfConnectors","readonly":true,"value":"0"}]}]

Expected behavior I've managed to setup the load balancer and charger successfully with SteVe by creating a chargepoint with the chargebox ID of the charger. I can also create a chargepoint for the balancer, and interact with it (get diagnostics for example).

Is the lack of being able to specify the chargebox ID a fundamental limitation of the plugin, compared to SteVe, or is there a workaround for that?

[munterkalmsteiner]

Ok, here is the fix (or workaround). Check the ID when the chargepoint connects to the central station and compare it to the configured value (api.py, line 231):

if cp_id == self.cpid:                                                                                                                                                            
    if self.cpid not in self.charge_points:                                                                                                                                            
        _LOGGER.info(f"Charger {cp_id} connected to {self.host}:{self.port}.")                                                                                                    
        charge_point = ChargePoint(cp_id, websocket, self.hass, self.entry, self)                                                                                                 
        self.charge_points[self.cpid] = charge_point                                                                                                                              
        await charge_point.start()                                                                                                                                                           
    else: 
        ...

It is important to set the correct value, i.e. the ID of the charger, for Charge point identity when setting up the component.

[Jerker74]

I have seen the same bug as you describe above and I started to ananlyse the logs. You're several steps ahead of me so I'll try to jump ahead and see if I can implement your solution in my system too.

[Jerker74]

It's the first if-statement you added which made the second if-statement conditional if I understand correctly? But what about the "Charge point identity" , I thought that parameter was just for the internal naming in HA? But you tell me to set it to GaroCS-xxxxxx when installing the integration?

[munterkalmsteiner]

Yes, it is just the first statement. self.cpid will actually be set to the value one specifies in the Charge point identity configuration option. If you look at some lines above in the code (Line 229) you will find the code that extracts the charge point id from the websocket path. The last segment is the charge point id which is, if you don't specify anything else in the Garo app, the serial number on the inside of the charging station.

[munterkalmsteiner]

I would submit a patch for this, but I think there needs to be a cleaner, more general solution. IMO, the main problem is that the code seems in some parts supporting more than 1 charge point, but the configuration allows only one. Hence, if you have a the Garo load balancer, which manages the communication to the central station, you have suddenly two "charge points" that compete with connecting to the charge station. This is visible with frequent reconnects. Most of the time the load balancer is connected, some times I saw values from the charger.

IMO, the solution would be to rewrite the configuration logic to create either a charge station or charge point device. That would allow one to create one charge station and as many charge points as needed, and configure them as needed.

[Jerker74]

I'm a quite experienced developer (since the 80-ties) but a newbie on networking and HA integrations, so please excuse my questions. Hopefully I'll learn quickly... :) I show you my log:

2024-01-12 16:17:14.203 INFO (MainThread) [custom_components.ocpp] Charger websocket path=/GaroLI-xxxxxxx 2024-01-12 16:17:14.203 INFO (MainThread) [custom_components.ocpp] Charger GaroLI-xxxxxxx disconnected from 0.0.0.0:9000.

To me this looks like the DLM is trying to connect to HA but these id's don't match. According to Garo support the CsmsUrl should be configured in the DLM and no changes in the charger. Do you agree?

But even if I give the HA device the same id name as my charger the system needs to get that info from somewhere else in the connection process, right? Is it propagated via the DLM? For my understanding HA needs to connect the id name to the network address.

[munterkalmsteiner]

Yeah, looks like the load balancer connects (I don't see a connection failure in your logs, though). Here is my config. Charger: both GaroRemoteCsmsUrl and GaroCsmsUrl are empty. Balancer: GaroRemoteCsmsUrl is ws://ip:port (where ocpp on HA runs), GaroCsmsUrl is empty.

The DLM propagates the data of the charger to HA. If you change the code as I did (restart home assistant after the change) and set the Charge point identity to GaroCS-$SerialnumberOfCharger, then you should see the charger connect to HA.

[munterkalmsteiner]

Important: load balancing still works with the above configuration in the Garo app. If you configure the charger with the Csms endpoint, then it will connect to HA (if you don't set a Csms URL in the balancer), but then no load balancing happens.

[Jerker74]

I don't get this to work. It's either the charger OR the dlm that's visible in my HA. They are not cooperative. And when I see one of them the other is not operating. I have made some factory resets and started all over again but no change. Could it be an network issue?

[munterkalmsteiner]

What are your ocpp connection settings on the DLM and charger?

Sent via BlackBerry Hub+ Inbox for Androidhttp://play.google.com/store/apps/details?id=com.blackberry.hub From: @. Sent: 14 January 2024 10:13 To: @. Reply to: @. Cc: @.; @.*** Subject: Re: [lbbrhzn/ocpp] Garo Entity Pro with load balancer (Issue #1043)

I don't get this to work. It's either the charger OR the dlm that's visible in my HA. They are not cooperative. And when I see one of them the other is not operating.

— Reply to this email directly, view it on GitHubhttps://github.com/lbbrhzn/ocpp/issues/1043#issuecomment-1890894003, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AAFP6NDIV3XCMSLTOSEKSVTYOOOVFAVCNFSM6AAAAABBW4QHRSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQOJQHA4TIMBQGM. You are receiving this because you authored the thread.Message ID: @.***>

[Jerker74]

Charger: (see below images too) CsmsUrl: empty DeviceId: empty RemoteCsmsUrl: empty

DLM: CsmsUrl: empty DeviceId: empty RemoteCsmsUrl: ws://homeassistant.local:9000

[munterkalmsteiner]

The Garo settings look fine. Instead of homeassistant.local, add the actual IP address of the box on which HA is running, just to exclude that as source of the problem. I assume that, when you make changes to the DLM/charger, you connect to them directly as instructed in the text when you click on "Offline" in the screenshots above. Otherwise, the settings are not applied to the devices.

Paste here also lines 230-240 of your api.py in the ocpp custom component. When you configured the occp integration, did you change the default "charger" identifier to "GaroCS-$YOUR_SERIAL_NUMBER"?

[Jerker74]

• I have replaced with IP address
• Yes, I use the QR code for offline configuration, it says it's connected and I can reboot. Though the tag "reboot required" is still there.
• I did change the DLM to be the master now but it makes no difference.

[munterkalmsteiner]

Two things: 1) I assume you have restarted HA after changing the code 2) I can see that in your lastbalanseringsgrupp, the charger is the master (crown symbol). This is incorrect. Check that in the DLM the config GaroConnectionGroupMaster is checked and in the charger unchecked.

[Jerker74]

1. Yes, multiple times.
2. I saw that and changed it after taking the screenshots but before sending the message. Makes no difference.
3. I also tried to put the server address on the local CsmsUrl instead of the remote (that's what Garo support said). Makes no difference.

I'm considering sending this crap back and ask for another brand. I'm done for today. 😑

[munterkalmsteiner]

Hm... yes, the setup was quite a pain but works now (for me). How I finally found out the issue with HA, I tried out SteVe. Maybe worth a try so you can make sure it is the charger's problem and not your OCPP endpoint. I assume DLM/charger are working fine with the Garo Csms endpoint? If yes, then the problem is likely in your network or HA configuration.

[Jerker74]

I'm not sure it has. The current to the car has always been lower than I expected it to be with a 20A fuse. But yesterday I made a reset and I got it up to 18A charging, controlled and seen via the Garo app but during the night it blow the fuse so there is something rotten in the state of Denmark. I will talk to my electrician which installed it.

Many thanks for your support! 😊

Den sön 14 jan. 2024 13:10Michael Unterkalmsteiner @.***> skrev:

Hm... yes, the setup was quite a pain but works now (for me). How I finally found out the issue with HA, I tried out SteVe https://github.com/steve-community/steve. Maybe worth a try so you can make sure it is the charger's problem and not your OCPP endpoint. I assume DLM/charger are working fine with the Garo Csms endpoint? If yes, then the problem is likely in your network or HA configuration.

— Reply to this email directly, view it on GitHub https://github.com/lbbrhzn/ocpp/issues/1043#issuecomment-1890934668, or unsubscribe https://github.com/notifications/unsubscribe-auth/AVWY2XSV3TURYQQMMUL6RJLYOPDNBAVCNFSM6AAAAABBW4QHRSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQOJQHEZTINRWHA . You are receiving this because you commented.Message ID: @.***>

[munterkalmsteiner]

Hm, what car do you have? I think AC charging is limited to 16A usually. The car won't take more.

[Jerker74]

Hyundai Kona 2019. This car only has single phase AC (and DC). In my other charger I can go up to 7,6kW single phase without any problems. That should equal 32A.

Den sön 14 jan. 2024 13:21Michael Unterkalmsteiner @.***> skrev:

Hm, what car do you have? I think AC charging is limited to 16A usually. The car won't take more.

— Reply to this email directly, view it on GitHub https://github.com/lbbrhzn/ocpp/issues/1043#issuecomment-1890937051, or unsubscribe https://github.com/notifications/unsubscribe-auth/AVWY2XV7V64H6HHZJJLDJGLYOPETBAVCNFSM6AAAAABBW4QHRSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQOJQHEZTOMBVGE . You are receiving this because you commented.Message ID: @.***>

[munterkalmsteiner]

Ah, I see. Well, if the setup using the Garo Csms endpoint does not work, then you have indeed an installation problem. You can get that setting back by clicking the circled arrow besides the setting GaroRemoteCsmsUrl.

[Jerker74]

Hi again,

I'm on my way. I can connect to the system now but there is a communication issues somewhere. With short intervals it disconnects and reconnects again. Anyone else seen this?

And some logs...

2024-02-15 14:56:51.226 INFO (MainThread) [custom_components.ocpp] Websocket Subprotocol matched: ocpp1.6 2024-02-15 14:56:51.226 INFO (MainThread) [custom_components.ocpp] Charger websocket path=/GaroCS-43A09B2076B80 2024-02-15 14:56:51.226 INFO (MainThread) [custom_components.ocpp] Charger GaroCS-43A09B2076B80 reconnected to 0.0.0.0:9000. 2024-02-15 14:56:51.227 DEBUG (MainThread) [custom_components.ocpp] Reconnect websocket to GaroLI-4C3B6C05D340 2024-02-15 14:56:51.227 DEBUG (MainThread) [custom_components.ocpp] Closing websocket to 'GaroLI-4C3B6C05D340' 2024-02-15 14:56:51.257 DEBUG (MainThread) [custom_components.ocpp] Closing websocket to 'GaroLI-4C3B6C05D340' 2024-02-15 14:57:12.318 INFO (MainThread) [custom_components.ocpp] Websocket Subprotocol matched: ocpp1.6 2024-02-15 14:57:12.319 INFO (MainThread) [custom_components.ocpp] Charger websocket path=/GaroLI-4C3B6C05D340 2024-02-15 14:57:12.319 INFO (MainThread) [custom_components.ocpp] Charger GaroLI-4C3B6C05D340 reconnected to 0.0.0.0:9000. 2024-02-15 14:57:12.319 DEBUG (MainThread) [custom_components.ocpp] Reconnect websocket to GaroLI-4C3B6C05D340 2024-02-15 14:57:32.336 DEBUG (MainThread) [custom_components.ocpp] Connection latency from 'central' to 'GaroLI-4C3B6C05D340': ping=0.0 ms, pong=15.0 ms 2024-02-15 14:57:52.348 DEBUG (MainThread) [custom_components.ocpp] Connection latency from 'central' to 'GaroLI-4C3B6C05D340': ping=0.0 ms, pong=10.0 ms 2024-02-15 14:57:55.462 INFO (MainThread) [custom_components.ocpp] Websocket Subprotocol matched: ocpp1.6 2024-02-15 14:57:55.462 INFO (MainThread) [custom_components.ocpp] Charger websocket path=/GaroCS-43A09B2076B80 2024-02-15 14:57:55.463 INFO (MainThread) [custom_components.ocpp] Charger GaroCS-43A09B2076B80 reconnected to 0.0.0.0:9000. 2024-02-15 14:57:55.463 DEBUG (MainThread) [custom_components.ocpp] Reconnect websocket to GaroLI-4C3B6C05D340 2024-02-15 14:57:55.463 DEBUG (MainThread) [custom_components.ocpp] Closing websocket to 'GaroLI-4C3B6C05D340' 2024-02-15 14:57:55.492 DEBUG (MainThread) [custom_components.ocpp] Closing websocket to 'GaroLI-4C3B6C05D340' 2024-02-15 14:58:10.552 INFO (MainThread) [custom_components.ocpp] Websocket Subprotocol matched: ocpp1.6 2024-02-15 14:58:10.552 INFO (MainThread) [custom_components.ocpp] Charger websocket path=/GaroLI-4C3B6C05D340 2024-02-15 14:58:10.552 INFO (MainThread) [custom_components.ocpp] Charger GaroLI-4C3B6C05D340 reconnected to 0.0.0.0:9000. 2024-02-15 14:58:10.552 DEBUG (MainThread) [custom_components.ocpp] Reconnect websocket to GaroLI-4C3B6C05D340 2024-02-15 14:58:30.561 DEBUG (MainThread) [custom_components.ocpp] Connection latency from 'central' to 'GaroLI-4C3B6C05D340': ping=1.0 ms, pong=6.0 ms

[munterkalmsteiner]

@Jerker74 You want the charger connect to the central station, not the load balancer. Currently, the code allows only one ocpp client to connect, so both the load balancer and the charger try to connect, which causes havoc. Here is the work around that fixes this. I'm working on a more permanent fix, but that will take some time.

[Jerker74]

I have solved the connection. :)

I added extra logging in the api.py file to really make sure all strings were correct and correctly compared. Of course they were not. Now I've learned that you can't change the charger id afterwards even though it looks like that in the HA GUI. The ID change in the GUI does not change the ID in the configuration under the hood.

I reinstalled the OCPP integration with EXACTLY the same charger id's as logged when the the charger tried to connect the socket. After an hour I'm still correctly connected.

Now I just need to get it to charge. The CS flashes as it is waiting for a time schedule. Any ideas of how to control the charger?

[munterkalmsteiner]

In the ocpp integration there are controls: charge control. Just switch it on and the charger should start. I'm using this integration to optimize charging when electricity prices are low. Works like a charm (with Tibber).

[Jerker74]

Hi,

Yes I've seen that but I get suspendedEVSE as response and I'm investigating why.

[github-actions[bot]]

Stale issue message