Hi Andy, did you get any further with this? I'm trying to do the same.
Do you know what what Model, Vendor & firmware version Wallbox send, as it may be as simple as recompiling the firmware.
Alternatively I was going to try and reach out to an existing Wallbox owner, and try and reverse engineer the protocol.
Hi Stuart,
I dont unfortunately, I had the same thinking of it perhaps being the model/vendor information. I dont know what is sent and been searching the web to see if anyone has recorded the information being sent.
I found the above information from a Home Assistant page for OCPP, I tried in Octopus to set the Wallbox which meant Octopus give you the details to put into Wallbox for OCPP connections, but when I did that it still didn't activate, so may be as you mentioned either the Model/Vendor information sent over or perhaps the Metrics information missing something. I dont have an OCPP receiver so haven't tested what openevse actually sends.
It looks like there are several fields that could be being checked - https://github.com/mobilityhouse/ocpp/blob/ae716a1507d708d83743d1132587cbb03522cda7/ocpp/v16/call.py#L192
This looks like an OCPP receiver you could try connecting a Wallbox to https://github.com/mobilityhouse/ocpp/blob/master/examples/v16/central_system.py
The protocol is quite simple, and I have written a proxy to intercept the messages from an OCPP client (the Charger) and the server (Octopus). I can see/log the messages.
When my OpenEVSE charger connects to Octopus, Octopus disconnects after the first packet is sent. So I need to know what data it is looking for.
I need someone with Wallbox Pulsar to temporarily connect to me, to see whats going on, or obtain a Wallbox myself.
I know someone with a Wallbox so if I can persuade them to switch off the sync with Octopus and point it to another OCPP server to see what it is sending I will let you know. The issue is they aren't very technical and may not want to risk disconnecting from Octopus as they had issues the first time they were setting it up.
I assume the OCPP receiver you mention above would need to be ran on a server somewhere, if I can work out how to set it up I may use that. I used to be technical but moved out of that side, so if it can run as a docker image or in HA I should be able to work it out, I will let you know, but if someone else manages to do similar please post in here.
I may struggle to recompile the openevse firmware myself without good instructions but can give it a go, but I am sure if we can get the information in here someone in the forum could do it and confirm if it works with the data :)
There must be something in that first packet then that tells Octopus if it should trust the charger or not outside of the ID details you put in that they give you to authenticate in the app.
Are you able to see what is in the first packet being sent from Openevse, does it include information about the charger, i.e. what make and model it is?
If you have details of the proxy, I can see if I can get the person I know to disconnect and point it through the proxy if I can run it here, that way I can capture the first packet and see what the Wallbox they have is sending. Theirs is an old Wallbox, not sure on the specific model, but it is currently connected to Octopus and sending the information over to them.
Every message I send here, has to be reviewed, and it's taking days. If you email me at stuart@logicethos.com I have a solution.
I have identified two issues so far. One is the secure websocket is failing. I created a pull request for that https://github.com/OpenEVSE/openevse_esp32_firmware/pull/1011
The second, is more operational. I have got as far as registering my test setup with my Octopus account, but it's not starting the charging sequence.
Andy Barron
I am looking at how to integrate with octopus energy who I have seen plenty of people looking to integrate with and got thinking that as they support the wallbox devices using OCPP there may be a hack way of integrating Openevse.
In essence I was looking to see if anyone has already tried this and if it worked already, but if not if there was a way of telling octopus that the device I am connecting is a wallbox, get the OCPP details from them and then plumb them into my Openevse device and get Openevse to emulate a wallbox so octopus would not see any difference and we could integrate very quickly using this method while they continue focusing on integrating the cars instead of supporting the chargers?
I did find this on another website which shows what seems to be the details Wallbox sends to OCPP, I wasn’t sure if there is any charger specific information I would need to replicate to tell octopus the Openevse was a wallbox through OCPP?
Useful Entities for Wallbox Pulsar Plus
Metrics
Energy Active Import RegisterorEnergy Session(they give the same readings)Power Active Import(instantaneous charging power)Current Offered(maximum charging current available)Voltage(single phase models only, doesn’t work on 3-phase)Frequency(single phase models only, doesn’t work on 3-phase)Time Session(elapsed time from start of charging session)