It looks fine, discovery found connector. The missing channel error is my fault. I’ve added missing XML descriptor, next build (3.0.0-pr-91-2024080y.xxxxxx-2) should contain it.
Gave it a shot now the channels are populated. But still no values the wallbox is in a ocpp connecting state. I tried scanning to see if it finds it still nothing . Logs dont show anything special any ideea?
If wallbox is stuck in connecting state then possibly binding does not satisfy defined protocol. I gonna check a handshake procedure in ocpp docs to see if binding should send something back.
I had it working at some point. My guess is some that my Grizzl-E charger is the source of my issues. Here is my repo : GitHub - gyzod/ocpp2mqtt: OCPP <==> MQTT Gateway
@splatch what is connectorIO ?
Not sure in which context you ask, it is:
- limited company I owe
- EU trademark owned my self-employed business
- github repos contain its open source code
- this is the largest set of third-party addons for OH
1 Like
dear @splatch, dear all: I have Easee Charge-boxes and would be willing to cooperate for some testing. I have 3 boxes and only need two of them, so I could do testing with the 3rd.
The Easee boxes have a local-API for a local OCPP 1.6j server:
Hello Wolfgang,
I have a PR with some changes to tune up OCPP binding: First push of more advanced version of OCPP binding. by splatch · Pull Request #91 · ConnectorIO/connectorio-addons · GitHub, however its still based on OH 3.0.0. Which version do you aim?
I would also be very interested in the OCPP binding. I have now Alfen Eve charger with Modbus. I’m now running OH4.3.5 but will upgrade to OH5 later in July.
Hi Łukasz!
I run OH 4.3, the current stable version. With OH5 imminent, it is perhaps better to leave out OH4.
I’ve used up all my raspberries, but for testing purposes I could always create another virtual machine (debian 12) and install OH3.
Give a try to this build:
https://repository.connectorio.cloud/service/rest/repository/browse/co7io-public-snapshots/org/connectorio/addons/org.connectorio.addons.kar.ocpp/4.3.0-pr-105-SNAPSHOT/
Later on there might be more builds, so keep in mind that number after 4.3.0-pr-105 is date stamp. 20250703 means build from 3rd July 2025.
which ocpp server do you recommend? (for debian)
Binding includes ocpp server, so charging stations connect directly to openHAB.
2 Likes
I have been away for almost 2 weeks and will be back at home after 1.5weeks so I can make tests then.
Hey @splatch. I’ve been travelling a lot over the past few months - about 60% of my time away from home 
, but I meant to tell you that I also tested this a couple of months back. On my system, it connected ok, but I wasn’t able to leave it running as my charger can’t be controlled by the app once OCPP is running…
I meant to ask you how you’d planned to add support to set the charge current and enable/disable charging. If this is something that can be added so we have 2 way comms with the charger, then I’d be able to set something up so my partner can use this instead of the app while I’m away and we’d be able to get more time on this…
I’m at home until the end of the month so can reasonably easily run tests…
There are several profiles in OCPP spec which define channels/parameters which can be controlled by OCPP server. Effectively we would need to make sure that certain values are being written back to charger when OH channel is signaled. This is entirely doable, as we can just use websocket connection launched by charger.
I had a read up on the profiles a while back but have mostly forgotten what I learnt 
. \
Currently, the binding doesn’t do anything useful as such (for me). The charger connects OK from memory, but no information is exchanged. The charger doesn’t proactively send any status, so
I had started to add a thread in the ConnectorThingHandler to periodically read back the status of the connection, but I hit issues with this. Looking at what I did at the time, the chargerReference is not available in the ThingHandler, so it doesn’t seem possible to send to the charger to request this, and I was trying to work out how best to make this available…
Maybe I need to try and remind myself how it all works. I’m slowly winding down with my NZ job now so “only” have one full time job from next week and have a week or so before I go back to the UK for another 3 week stint there 
.
AFAIR ConnectorThingHandler was able to receive some data from simulator, but it could be that with real charger we missed the initialization sequence needed to enable data exchange.
Hi @splatch, @chris and @Sulla ,
Is it planned to update this binding to current openHAB? I’m happy to help as I’m running openHAB 5.0 and have an OCPP charger at home.
Hello,
I recently merged PR with adjustments discussed earlier to all branches. Give a try to one of these KARs: https://repository.connectorio.cloud/#browse/browse:co7io-public-snapshots:org%2Fconnectorio%2Faddons%2Forg.connectorio.addons.kar.ocpp%2F5.0.0-SNAPSHOT
.. you can use also earlier OH releases, functionality wise they are all the same.