Author: neil

Disclaimer: This is an academic exercise. While this method works, it’s using an unsupported charger and Octopus may not like that. I’m not responsible for you following this guide and getting charged peak rate for charging, being kicked off the tariff completely, or Greg Jackson kicking your door in. You have been warned.

The Easee One charger is a really well designed and manufactured piece of kit, but despite Easee having a concept of an “operator”, and supporting OCPP for as long as I’ve owned one, it seems Easee can’t fill out a simple form. As a result, they remain one of the few chargers that aren’t supported by the Octopus Intelligent Go tariff.

The Intelligent Go tariff is one of the best tariffs for UK EV drivers, offering very low overnight rates ( 7p at the time of writing ) for 6 hours, and for the entire house not just the EV. Also at the time of writing, if you need more time to charge your EV, then Octopus gives a lower rate for the entire time your car needs to charge, with the whole house accessing that low rate too. This means that you can potentially charge your EV from empty to full in an single night at a very low cost. Note Octopus are threatening to change this, but currently this is still a compelling reason to be on Intelligent Octopus.

Octopus can do this because at the point you sign up, they enrol your MPAN into a flex arrangement, curtailing the charging of your car when the grid is stressed, but also charging your car outside of the low rate period when energy is abundant. They use the flex credits they get from this to blend a cheaper low rate for the whole house. The snag is that they need to be able to control your EV’s charging, either by controlling your vehicle ( preferred by Octopus ) or by controlling your charger ( next best option for Octopus ).

While many EV chargepoints are supported, Easee isn’t. This means that if your vehicle also isn’t supported then you can’t use the Intelligent Octopus tariff. However… Easee have recently enabled “local OCPP”, meaning you can provision your Easee charger to communicate with a provider using the standards-based OCPP protocol, and Octopus does support OCPP with specific charger models.

But there’s a catch…

In order to do this, we need to use the Easee Developer API, and there’s a handy GUI onto it. We can use this API to provision OCPP onto the Easee charger.

All we then need to do is find a suitable charger to masquerade as, and the Wallbox charger seems to be the only fit, given it uses OCPP to communicate with Octopus and doesn’t require any other credentials such as Oauth to set it up. All we need to do is enrol into Octopus Intelligent Go using a Wallbox, noting down the info and provisioning that into the Easee.

The problem is two fold:

1. When we get credentials from Octopus, they provide a UUID-like Chargepoint ID such as 00000000-000A-A000-ABCD-000000012345. Easee seems to have followed the OCPP standard to the letter and enforced a 25 character limit on the Chargepoint ID. The result is that if we provision an Octopus Chargepoint ID into the Easee API then it rejects the request with a 400 response.
2. Easee allow OCPP endpoints using either unsecure as ws:// URLs, or securely using wss:// URLs. However they only accept secure endpoints IF you also provision with the certificate in the request, and they test the certificate when they establish the connection, all very acceptible. However, they also check the CN of the certificate with the URL we are connecting to. Octopus require the connection to be made to “ocpp.octopus.energy” however the CN of the certificate is a different Kraken endpoint, with “ocpp.octopus.energy” provided in a SAN record of the certificate, meaning Easee rejects the connection attempt.

This all sounds bad, and it is if we try to connect directly, so game over? Not so fast…

What we can do is to connect via a reverse proxy! We can do this because the Chargepoint ID is not actually used in the majority of OCPP messages, it’s only used during login and as part of the connection URL. So if we use a reverse proxy to sit in the middle of the connection between the Easee charger and Octopus’s OCPP server, the proxy is just transforming the URL. What we do need to do however is to set up a proxy to convert one URL into another while supporting WebSocket connection upgrading and handling the authentication with Octopus.

While the younger crowd would probably use Nginx to do this, I used Apache given it’s what I had lying around and also what I know. What we’ll do is set up an Apache virtual host to act as a proxy, it will then accept a connection unsecured from the Easee and then proxy the connection to the OCPP server at Octopus. This also has a positive bonus of allowing us to inspect the traffic going back and forth using Wireshark.

Piecing it all together

Before we start, Local OCPP disables schedules on the Easee and that option will be greyed out in the app, but if you have any existing schedules then they will still appear in the app and you can’t amend them. To stop things looking strange, remove any existing schedules on the charger before enabling Local OCPP.

Firstly, let’s sign up to Octopus Intelligent Go. We head to the website and input our car and say we have a Wallbox:

It’s going to then redirect us to the app, which will in turn give us some Wallbox credentials, I’m going to the these as an example:

• Octopus Chargepoint ID: 00000000-000A-A000-ABCD-000000012345
• Octopus Password: xxxyyyzzz
• Easee charger serial UK123456

Let’s move over to Apache. I’m assuming we already have a working Apache setup on the local LAN to the Easee, and this Apache setup has the mod_proxy and SSL modules enabled.

The next thing we need to do is to get a basic authentication header using the Chargepoint ID and password provided by Octopus. To do this, we take the Chargepoint ID followed by a colon followed by the password, e.g:

00000000-000A-A000-ABCD-000000012345:xxxyyyzzz

Then we just base64 it, If you’re lazy there’s tons of “Basic Auth Header” creators on the Internet. What we end up with is:

MDAwMDAwMDAtMDAwQS1BMDAwLUFCQ0QtMDAwMDAwMDEyMzQ1Onh4eHl5eXp6eg==

We can then create a virtual host in apache and restart / reload it:

<VirtualHost 192.168.0.10:80>
    SSLProxyEngine on
    ProxyPass /UK123456 https://ocpp.octopus.energy/00000000-000A-A000-ABCD-000000012345 upgrade=websocket timeout=3600
    ProxyPassReverse /UK123456 https://ocpp.octopus.energy/00000000-000A-A000-ABCD-000000012345
    RequestHeader set Authorization "Basic MDAwMDAwMDAtMDAwQS1BMDAwLUFCQ0QtMDAwMDAwMDEyMzQ1Onh4eHl5eXp6eg=="
</VirtualHost>

Note the pertinent bits of this are the translation between the Octopus OCPP endpoint using their DNS name and the Chargepoint ID they provided, and the Easee Serial number used in the conneciton from the Easee charger. The other thing we added here is the Authorization header Octopus are expecting using the Chargepoint ID and password they provided. This is all that’s needed to build the conduit between the Easee charger’s OCPP connection and Octopus’s OCPP servers. The other attribute we’re passing enables upgrading of the HTTP connection to a full blown websocket connection. I’ve added a long term connection timeout of 1 hour also, but don’t think this is actually necessary.

From what I understand, the only OCPP method which might contain the Chargepoint ID is a “reboot” message which isn’t used by Octopus for authorisation or billing. This is potentially the only thing that could give the game away but I doubt Octopus do anything with this message.

Next, we just need to provision the Easee. Using the Easee Developer website we can use the “Saves OCPP connection details for given charger” method. Be sure to specify a “websocketConnectionArgs” object using an insecure “ws://” url and with our server name BUT DO NOT add the Easee chargepoint suffix from the URL, Easee does this for us. We also need to select “DualProtocol” as the connectivity mode:

Or in curl-land:

curl --request POST \
     --url https://api.easee.com/local-ocpp/v1/connection-details/UK123456 \
     --header 'accept: application/json' \
     --header 'content-type: application/json' \
     --data '
{
  "websocketConnectionArgs": {
    "url": "ws://192.168.0.10:80"
  },
  "connectivityMode": "DualProtocol"
}
'

If you’re logged in to the Easee developer portal we can send the command from right there, and you “should” get a 200 response back with a template ID. What I have found is that you need to then use the “Applies given OCPP configuration version to specified charger” method along with your serial number and the template ID from the previous step to actually apply that to the charger:

After that, we should be able to plug our car in and go through the test charge. Now when we plug in, instead of the car charging right away we get something like this stating we’re “waiting for approval”:

Then, once Octopus wants to charge our car, we get the usual screen:

After a slot finishes we go right back to the “waiting for approval” screen. With IOG we get lots of slots, sometimes with gaps inbetween, in which case the Easee charger will start-stop-start-stop as required:

Conclusion

From my experience, everything works as well or as badly as the standard Wallbox integration, in fact the Easee works a little better as the WiFi implementation on Wallbox is flaky, losing the OCPP connection regularly whereas Easee if rock solid. I actually have a Wallbox which I have swapped between the Easee and Wallbox using the same credentials. Of late, Octopus seems to be far more random with charging slots, regularly changing the schedule and sometimes charging my car at the last minute halfway through a half hour period. I initially thought this was something to do with the Easee OCPP integration resetting the connection, but both looking at the OCPP going back and forth and moving back to the Wallbox, this seems to be normal behaviour.

What I’ve also experienced both with the Wallbox and with Easee is that Octopus seems to keep planning slots to give me my “amount to add” setting, ignoring what they have already charged during the session! For example if I select “30%” as the amount to add, then Octopus will plan aroud 4 hours of charging, but after I have received 4 hours of charging ahead of my low rate period, it will STILL give me another 4 hours of slots! In conclusion I think something is strange at Octopus and not with the Easee / Wallbox OCPP connection.

The other annoyance is that while the Easee is waiting for a charging slot to begin, the LED on the unit flashes. This can be quite distracting if your Easee unit is visible from the road or house. My feeling is that Easee expect the charging authorisation to be fairly quick whereas with IOG it can be as much as 12 hours between plugging in and the charge actually strating.

I’m not sure whether I will continue to use Easee or my Wallbox, both work identically but obviously Wallbox is the supported charger. I have two Easee units and an Equaliser though, so the Easee is better for me load balancing between two EVs and my 100a incoming fuse. Decisions decisions…