OCPP and Octopus

Integrations OpenEVSE
1

I understand that OpenEVSE may be suitable to use with Octopus Intelligent tariff.

Has there been any move towards integration?

Regards

Ian

1 Like
2

I am also interested in this :slight_smile:

John

3

I did try reaching out to Octopus to get info on this but didn’t really get anything useful, if anyone has any details on what is needed would be great to know.

4

I have a contact at Octopus. I will try and find out what would be needed their end to enable integration. It could potentially be a money saver!

1 Like
5

This should help:

https://developer.octopus.energy/docs/api/#example-usage

6

That is for the API, what you would use for the Agile tariff. As far as I understand the Intelligent tariff uses OCPP to allow Octopus to control when the car charges, vs what you would do with Go or Agile where the EVSE controls when to charge.

I would expect there to be some details of the OCPP servers, what to send as the ID, etc, maybe some certification or validation process.

1 Like
7

Hi

Sorry it took me a while to contact Octopus.

Reply was

Hi there - thanks for raising this Ian. OCPP as an integration route is on the roadmap but might be some time before fully integrated / supported. Will let you know as we build this out.

1 Like
8

I believe that for Intelligent Octopus to work as designed, something needs to somehow poll the battery level of the connected vehicle. It’s more than just tracking cheap half-hourly electricity tariffs that you can do with ‘Agile Octopus’ tariff.
OpenEVSE doesn’t have the powerline networking hardware to support directly querying the connected vehicle via ISO 15118, nor for that matter, do many EVs, nor for that matter do most AC charge points, so the workaround for this as used by companies like Ohme is for the ohme (cloud) backend to log into a vehicle manufacturer’s remote polling API as the end user, and query the SoC of the vehicle, in the hope that it’s querying the same vehicle as is connected to the EVSE.
Of course, that requires the vehicle manufacturers to be happy with that arrangement.
Ditto for where Octopus Energy connects to the vehicle manufacturers’ polling API as the end user (they can then use any EVSE, since where possible they can suspend, slow or stop the charging remotely).
OF course, that requires the vehicle manufacturers to have actually implemented a suitable API, (i.e. not Stellantis, whose remote API doesn’t allow remote signals to slow, suspend or stop charging), so for those not-quite-compliant vehicles, they have to control both the vehicle to get the SoC and the EVSE that they think it may be connected to. It seems to be to be a very experimental tariff.

1 Like
9

Sounds like complete chaos to make that work as well as it does!

10

The integration with the myenergi Zappi charger doesn’t do any polling of the EV’s SoC. Instead you select a percentage of charge you want to be added to the car and they calculate the amount of charge to be added based on the battery size of the vehicle you have selected in your Intelligent Octopus profile, so exactly the same approach could be applied to EVSE I believe, without need for any integration with manufacturers’ APIs.

11

AFAIK no Level 2 (AC) EVSE has power line LIN communication to be able to read SoC, and not every vehicle supports this during AC charging so Octopus need to rely on vehicle APIs to get SoC. It’s such a shame that SoC communication was not built into the J1772 protocol.

2 Likes