Implement OCPP protocol V1.6

[glynhudson]

Open Charge Point Protocol: http://www.openchargealliance.org/protocols/ocpp/ocpp-16/

Allow OpenEVSE to integrate easily with other charging networks.

Spec attached: ocpp-1.6_edition_2.pdf OCPP_1.6_JSON_Specification.pdf

Wiki page: https://github.com/OpenEVSE/openevse_wifi_server/wiki/Open-Charge-Point-Protocol

[chris1howell]

Here is a white paper about integrating OCPP with OpenADR (Demand Response) both would fit in well with EmonCMS energy monitoring to create Smart Charging with open protocols. using openadr with ocpp.pdf

[DrFrankReade]

This is a great idea, but is the ESP8266 powerful enough to get the job done? Or is this a good job for the Raspberry Pi Zero W or an ESP32?

[glynhudson]

Yes, I think your right. OCPP is a hefty API. More horsepower will be required, also needed for https://github.com/OpenEVSE/ESP8266_WiFi_v2.x/issues/152

My preference would be RaspberryPi, possibly a zero or A+

I'm not too familiar with ESP32, how much more powerful is it? My feeling is that full embedded will probably be required for hefty web API's. The challenge is to make a smooth user setup experience. We have done this to some extent with OpenEnergyMonitor handing off WiFi AP to STA on a RaspberryPi: https://blog.openenergymonitor.org/2017/06/emonpi-network-setup-wizard/

[DrFrankReade]

I have friends who swear by the ESP32, and it's an awesome chip for sure, but code for a Pi, being (likely) linux, is going to be a LOT more portable than the code for an ESP32. So, there's nothing I love more than designing PCBs - Shall I take a stab at a board to mate the OpenEVSE to a Pi Zero? With level shifters and transient protection? My only concern is powering the Pi. I'm not sure if the OpenEVSE's power supply has the oomph to power it, certainly not from the 5V rail, but maybe the 12V rail through a buck converter. I'll look in to it.

[glynhudson]

It defiantly need it's own power supply.

That's a very kind offer. However, I'm not sure we need a PCB since the openevse controller can just talk to the Pi via serial. A wire to the GPIO serial pin is all that's needed.

@chris1howell @lincomatic @jeremypoulter do you have any thoughts?

[chris1howell]

I really like the OrangePi Zero. It is nice and small and has both WiFi and Ethernet.

OpenEVSE serial is 5v as long as the pins on whatever SBC we connect to are 5v tolerant we are okay. Otherwise we need a level shifter.

We will absolutely need external power unless we beef up the PS on a future version.

On Apr 4, 2018 6:36 PM, "Glyn Hudson" notifications@github.com<mailto:notifications@github.com> wrote:

It defiantly need it's own power supply.

That's a very kind offer. However, I'm not sure we need a PCB since the openevse controller can just talk to the Pi via serial. A wire to the GPIO serial pin is all that's needed.

@chris1howellhttps://github.com/chris1howell @lincomatichttps://github.com/lincomatic @jeremypoulterhttps://github.com/jeremypoulter do you have any thoughts?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/OpenEVSE/ESP8266_WiFi_v2.x/issues/114#issuecomment-378795496, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ABvYH7NJafENlsygQWDSS5CiBdnEaS0Bks5tlXU2gaJpZM4QDASN.

[jeremypoulter]

I think an ESP32 port should be fairly easy. Just need a few hours to have a look as far as I can tell all the required libraries are supposed.

For the Pi/Orange Pi/basically any PC with a serial port I kind of had in mind that the Simulator could be relatively easily modified to work with the OpenEVSE directly. I have a few ideas on how to do this.

I am nearly done with the time zone issues, it may be an idea to look at porting to something with a bit more power.

On 5 Apr 2018 04:15, "Chris Howell" notifications@github.com wrote:

I really like the OrangePi Zero. It is nice and small and has both WiFi and Ethernet.

OpenEVSE serial is 5v as long as the pins on whatever SBC we connect to are 5v tolerant we are okay. Otherwise we need a level shifter.

We will absolutely need external power unless we beef up the PS on a future version.

On Apr 4, 2018 6:36 PM, "Glyn Hudson" <notifications@github.com<mailto: notifications@github.com>> wrote:

It defiantly need it's own power supply.

That's a very kind offer. However, I'm not sure we need a PCB since the openevse controller can just talk to the Pi via serial. A wire to the GPIO serial pin is all that's needed.

@chris1howellhttps://github.com/chris1howell @lincomatic< https://github.com/lincomatic> @jeremypoulter< https://github.com/jeremypoulter> do you have any thoughts?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub< https://github.com/OpenEVSE/ESP8266_WiFi_v2.x/issues/114#issuecomment-378795496>, or mute the thread< https://github.com/notifications/unsubscribe-auth/ABvYH7NJafENlsygQWDSS5CiBdnEaS0Bks5tlXU2gaJpZM4QDASN>.

— You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub https://github.com/OpenEVSE/ESP8266_WiFi_v2.x/issues/114#issuecomment-378808580, or mute the thread https://github.com/notifications/unsubscribe-auth/AF1WgD0_uBVJOncM-u0CsATjbmu3PjlKks5tlYxGgaJpZM4QDASN .

[DrFrankReade]

Hello -

One could also simply plug a USB FTDI adapter in the Pi and go that way, but the pile of hardware is starting to look really ugly, which is why I advocate for a purpose built board.

On the matter of serial between the OpenEVSE and a Pi, or ESP of any variety, level shifting is absolutely needed. Although a simple voltage divider will suffice for getting data from OpenEVSE to a 3.3V device, a proper level shifting is required to get the data up to 5V for the OpenEVSE to read any of these devices. There's a dozen ways to do this, but I'm personally a big fan of using optoisolators because of the dual purpose that they'd be serving in this role. While it might work to directly connect it, reliability often ends up suffering.

Another reason I like a board is to be able to power the Pi from a more robust connector than the micro USB, and the possibility of powering it with a higher voltage, maybe even the 220 lines (The MeanWell IRM-10-5 comes to mind) without having to incorporate a wall wart somewhere. I see the whole shootin' match to look like a raspberry pi zero W stacked and screwed to a board with 220V in and 5V serial out (and maybe a couple LEDS)

[chris1howell]

I am pretty sure the Atmega 328p will handle 3.3v tx levels even at 5v.

On Apr 5, 2018 1:10 PM, "Andy Baker" notifications@github.com<mailto:notifications@github.com> wrote:

Hello -

One could also simply plug a USB FTDI adapter in the Pi and go that way, but the pile of hardware is starting to look really ugly, which is why I advocate for a purpose built board.

On the matter of serial between the OpenEVSE and a Pi, or ESP of any variety, level shifting is absolutely needed. Although a simple voltage divider will suffice for getting data from OpenEVSE to a 3.3V device, a proper level shifting is required to get the data up to 5V for the OpenEVSE to read any of these devices. There's a dozen ways to do this, but I'm personally a big fan of using optoisolators because of the dual purpose that they'd be serving in this role. While it might work to directly connect it, reliability often ends up suffering.

Another reason I like a board is to be able to power the Pi from a more robust connector than the micro USB, and the possibility of powering it with a higher voltage, maybe even the 220 lines (The MeanWell IRM-10-5 comes to mind) without having to incorporate a wall wart somewhere. I see the whole shootin' match to look like a raspberry pi zero W stacked and screwed to a board with 220V in and 5V serial out (and maybe a couple LEDS)

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/OpenEVSE/ESP8266_WiFi_v2.x/issues/114#issuecomment-379061368, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ABvYHzUHUHCIcmKdya8b_ebrfxxDdIpsks5tlnozgaJpZM4QDASN.

[DrFrankReade]

Hello,

It's true, the ATMEGA328P can in fact handle 3.3V as a logic "high" but since the "high" on the atmel is defined as VCC * 0.6 (that's 3V), there's not much room for power supply droop or noise, The adafruit boards work because they have shifters built in.

Andy

[davehun]

A board with more CPU grunt and connectivity would help for other reasons. A Board with BT and wifi would allow getting the state of charge via ODBC i.e. a leafspy type device. I haven't had a good experince getting the state of charge via the Nissan API (other cars may be better).

[glynhudson]

Having been involved in installing a few OpenEVSE units with WiFi in customer locations I'm convinced of the importance of having a wired Ethernet option. In some locations WiFi is tricky and can be unreliable when the unit is mounted externally.

I'm keen to stick with an embedded solution rather than move to a full linux stack e.g RaspberryPi. I feel that an embedded solution e.g. ESP32 will be more reliable and better suited to the working environment inside an openEVSE enclosure e.g wide temperature range etc.

I've found that it's possible to get a board with an ESP32 with integrated Etherned which to me seems to perfect solution: https://www.olimex.com/Products/IoT/ESP32-GATEWAY/open-source-hardware

ESP32 will enable secure HTTPS connections and give us plenty of space for growth.

What do you think @jeremypoulter @chris1howell @lincomatic?

[jeremypoulter]

Oh, that looks like a nice board. I have started on a port to ESP32, unfortunately (or fortunately depending on your POV) I need to implement propper SSL certificates.

Honestly thought I don't think there is any advantage, from a hardware POV, in using the ESP32 over a Pi (or similar). Certainly for large scale, remote management applications I would be more inclined to go for the latter.

In essence I think there are good use cases for each of the platforms.

On Thu, 12 Apr 2018, 16:56 Glyn Hudson, notifications@github.com wrote:

Having been involved in installing a few OpenEVSE units with WiFi in customer locations I'm convinced of the importance of having a wired Ethernet option. In some locations WiFi is tricky and can be unreliable when the unit is mounted externally.

I'm keen to stick with an embedded solution rather than move to a full linux stack e.g RaspberryPi. I feel that an embedded solution e.g. ESP32 will be more reliable and better suited to the working environment inside an openEVSE enclosure e.g wide temperature range etc.

I've found that it's possible to get a board with an ESP32 with integrated Etherned which to me seems to perfect solution: https://www.olimex.com/Products/IoT/ESP32-GATEWAY/open-source-hardware

ESP32 will enable secure HTTPS connections and give us plenty of space for growth.

What do you think @jeremypoulter https://github.com/jeremypoulter @chris1howell https://github.com/chris1howell @lincomatic https://github.com/lincomatic?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/OpenEVSE/ESP8266_WiFi_v2.x/issues/114#issuecomment-380855431, or mute the thread https://github.com/notifications/unsubscribe-auth/AF1WgIpqSey7p6PMX3-cD6NPmpb2mr66ks5tn3klgaJpZM4QDASN .

[DrFrankReade]

I agree that wired ethernet is always better if it can be pulled off. Wifi is problematic in dense areas, even if the signal looks "good"

I will again make the case for a Pi (or other Linux device) since there are TONS of them, and portability of code will (practically) never be an issue. Run it on a Pi, an Intel Edison, a PC, an Arduino Yun, etc.. and there are linux distributions that are lightweight and boot quickly. On the other hand, if for some reason they stop making ESP32s, then that's just that. There are also infinite peripheral options on the Pi and fantastic community support (the ESP has a good community too) Imagine it... (for a PowerWheels EVSE) http://www.frank-buss.de/raspberrypi/epaper/energy-monitor-display.jpg

[chris1howell]

I like the OpenWRT based GL-iNet devices https://store.gl-inet.com/products/gl-ar150-mini-smart-router?variant=3047587807259 https://www.aliexpress.com/item/50Pcs-Pack-GL-iNet-6416-Atheros-AR9331-802-11n-150Mbps-Wireless-Mini-WiFi-Router-OPENWRT-OPENVPN/32861193451.html

and the Orange Pi Zero http://www.orangepi.org/orangepizero/

[chris1howell]

OCPP 2.0 is out. OCPP-2.0.zip

[DrFrankReade]

Somebody's been working on this... http://ibeyonde.com/wordpress/ocpp-compliant-openevse/

[glynhudson]

Interesting, I will try and make contact. Thanks for the link. Sadly it doesn't look like they will be very open-source with their implementation.

[DrFrankReade]

The big question here is if a Docker or Raspberry Pi image exists with a nice beautiful OCPP server with a web interface for people to use (no of course not) Or if it's python from the command line. I wish I was smarter and could make these things. Some of these interfaces that people are making are so damn nice (The PiHole comes to mind, even EMONPI is pretty slick)

[jeremypoulter]

There are a few Node JS implementations that could be useful in conjunction with OpenEVSE/ESP8266_WiFi_v2.x#183.

• https://www.npmjs.com/package/ocpp-js

[Precisionsflyg]

I would also like to see OCPP support, but more importantly a lightweight OCPP server on RPi. I'm weighing my options right now, and the EmonEVSE looks like a good fit, but since I would like to also put a few up at work, it's missing an easy way to keep track of energy usage. It's also missing an RFID reader, to be able to track who uses which charger - but thats another problem... ;-)

[jeremypoulter]

Thanks for showing your interest.

The Node.JS library looked like it had a fairly light weight server, may meet your needs.

RFID is an interesting idea, obviously there is a bunch of business logic here and we would need the right split to allow folks to integrate to whatever access control/charging (money) system the have in the backend. You should raise a ticket for that so we don't go too off topic here.

[chris1howell]

I agree, we need 3 components...

OCPP 2.0 client OCPP 2.0 Server to log to database User Interface for Energy Monitoring and Control (maybe OCPP UI plugin for EmonCMS?)

On Wed, May 30, 2018 at 2:01 AM, Joakim Mårtensson notifications@github.com<mailto:notifications@github.com> wrote:

I would also like to see OCPP support, but more importantly a lightweight OCPP server on RPi. I'm weighing my options right now, and the EmonEVSE looks like a good fit, but since I would like to also put a few up at work, it's missing an easy way to keep track of energy usage. It's also missing an RFID reader, to be able to track who uses which charger - but thats another problem... ;-)

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/OpenEVSE/ESP8266_WiFi_v2.x/issues/114#issuecomment-393086032, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ABvYH_lfct9KB8b1IoGTz54jtRQ4-kLrks5t3l_rgaJpZM4QDASN.

[chris1howell]

Unfortunately, the Node.JS libraryhttps://www.npmjs.com/package/ocpp-js is a bit outdated. It is based on version 1.5 SOAP. Version 1.6 has been out for quite a while and uses SOAP or JSON. Version 2.0 was recently released.

On the server side I think SteVe is a better option. It already supports OCPP 1.6 JSON. https://github.com/RWTH-i5-IDSG/steve

On Wed, May 30, 2018 at 8:55 AM, chris1howell . chris1howell@msn.com<mailto:chris1howell@msn.com> wrote: I agree, we need 3 components...

OCPP 2.0 client OCPP 2.0 Server to log to database User Interface for Energy Monitoring and Control (maybe OCPP UI plugin for EmonCMS?)

On Wed, May 30, 2018 at 2:01 AM, Joakim Mårtensson notifications@github.com<mailto:notifications@github.com> wrote:

I would also like to see OCPP support, but more importantly a lightweight OCPP server on RPi. I'm weighing my options right now, and the EmonEVSE looks like a good fit, but since I would like to also put a few up at work, it's missing an easy way to keep track of energy usage. It's also missing an RFID reader, to be able to track who uses which charger - but thats another problem... ;-)

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/OpenEVSE/ESP8266_WiFi_v2.x/issues/114#issuecomment-393086032, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ABvYH_lfct9KB8b1IoGTz54jtRQ4-kLrks5t3l_rgaJpZM4QDASN.

[chris1howell]

I have a OCPP server up and running that can do OCPP 1.2, 1.5 and 1.6 SOAP and JSON. it is based on SteVE. https://github.com/RWTH-i5-IDSG/steve

You guys are welcome to check it out and test it with the OCPP client.

http://energy.openevse.com:8080/steve/manager/home

to hit the server via 1.6 JSON

ws://energy.openevse.com:8080/http://energy.openevse.com:8080//steve/websocket/CentralSystemService/

Have fun...

[cid:ii_jhtlg9xt0_163b2d92645a6827]

[https://plus.google.com/u/0/_/focus/photos/public/AIbEiAIAAABECMGOguW5qIypjQEiC3ZjYXJkX3Bob3RvKigxZTg5ODZmN2Q5MmViYTJiNDllMzU0NGVlZjliOGUwNWU2MzAzZDE0MAEAR3UQiVgVxBDxezvT7W2qShM1Jw?sz=24] Click here to Reply or Forward

90.55 GB (88%) of 102 GB used Managehttps://www.google.com/settings/u/0/storage?hl=en Termshttps://www.google.com/intl/en/policies/terms/ - Privacyhttps://www.google.com/intl/en/policies/privacy/ Last account activity: 3 minutes ago Details

Page 1 of 21

On Wed, May 30, 2018 at 9:08 AM, chris1howell . chris1howell@msn.com<mailto:chris1howell@msn.com> wrote: Unfortunately, the Node.JS libraryhttps://www.npmjs.com/package/ocpp-js is a bit outdated. It is based on version 1.5 SOAP. Version 1.6 has been out for quite a while and uses SOAP or JSON. Version 2.0 was recently released.

On the server side I think SteVe is a better option. It already supports OCPP 1.6 JSON. https://github.com/RWTH-i5-IDSG/steve

On Wed, May 30, 2018 at 8:55 AM, chris1howell . chris1howell@msn.com<mailto:chris1howell@msn.com> wrote: I agree, we need 3 components...

OCPP 2.0 client OCPP 2.0 Server to log to database User Interface for Energy Monitoring and Control (maybe OCPP UI plugin for EmonCMS?)

On Wed, May 30, 2018 at 2:01 AM, Joakim Mårtensson notifications@github.com<mailto:notifications@github.com> wrote:

I would also like to see OCPP support, but more importantly a lightweight OCPP server on RPi. I'm weighing my options right now, and the EmonEVSE looks like a good fit, but since I would like to also put a few up at work, it's missing an easy way to keep track of energy usage. It's also missing an RFID reader, to be able to track who uses which charger - but thats another problem... ;-)

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/OpenEVSE/ESP8266_WiFi_v2.x/issues/114#issuecomment-393086032, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ABvYH_lfct9KB8b1IoGTz54jtRQ4-kLrks5t3l_rgaJpZM4QDASN.

[chris1howell]

I have a OCPP server up and running that can do OCPP 1.2, 1.5 and 1.6 SOAP and JSON. it is based on SteVE. https://github.com/RWTH-i5-IDSG/steve

You guys are welcome to check it out and test it with the OCPP client.

http://energy.openevse.com:8080/steve/manager/home

to hit the server via 1.6 JSON

ws://energy.openevse.com:8080//steve/websocket/CentralSystemService/

Have fun...

[chris1howell]

I have been trying to figure out how to get enough processing, memory, power and connectivity into the charging station to support OCPP... but what if this is the wrong approach? We already have full control over MQTT.

What if we built an external device on a LINUX Single board Computer that could act as a WiFi extender/access point for one or many charging stations and also support OCPP to MQTT? This model could also extend to a cloud based MQTT Server that does all the OCPP Magic on a server.

[dnear1]

Like a Ras Pi W Zero?

On Sun, Jun 10, 2018 at 9:22 AM Chris Howell notifications@github.com wrote:

I have been trying to figure out how to get enough processing, memory, power and connectivity into the charging station to support OCPP... but what if this is the wrong approach? We already have full control over MQTT.

What if we built an external device on a LINUX Single board Computer that could act as a WiFi extender/access point for one or many charging stations and also support OCPP to MQTT? This model could also extend to a cloud based MQTT Server that does all the OCPP Magic on a server.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/OpenEVSE/ESP8266_WiFi_v2.x/issues/114#issuecomment-396053092, or mute the thread https://github.com/notifications/unsubscribe-auth/AFQgtYu2cCLlrNJBVWMzczPP2y3b5gRWks5t7SuVgaJpZM4QDASN .

-- Daniel Near dan.e.near@gmail.com

[chris1howell]

Ras Pi W Zero would work for MQTT to OCPP.

A board with WiFi, Ethernet and USB like the Ras Pi 3 or Orange Pi Zero could also act as a WiFi Access Point and connect via WiFi, Ethernet or cellular 3G/4G.

[chris1howell]

Here is an OCPP implementation that looks pretty promising. There is an example for a client.

https://github.com/NewMotion/ocpp

[DrFrankReade]

Hello,

My personal feeling is that all of the bridges to bridges will make for far too many points of failure, plus a lot of stuff to set up. MQTT is awesome, but it's another layer. A pi or other SBC attached directly to the OpenEVSE (well... via a level shifter) seems like the fewest moving parts. OCPP is also the future, and moving forward, OCPP is going to be on virtually every commercial machine, and every network that survives the next 5 years is going to support it.

There can be plenty of debate about the benefits or pitfalls of moving the I2C display over to the Pi (or any display) and the freeing up of resources on the atmega. It may even make the little power supply happier, although the change in the brownout voltage fuse a few months ago seems to have really ended squirrely powerups. With the added mountain of high speed GPIO, any number of displays could be added, and by moving it over to Linux, the project is far more accessible to the community. Not that there isn't a HUGE ESP community, because there is.

The interface could benefit too. The ESP interface works fine, and doesn't of course needs any bells and whistles, but having easier access to schedules, graphs, etc, would be pretty great, and you don't have to hook up emoncms if you don't want to. As far as OCPP, I guess it could be implemented with the client and the server running on the Pi together for stand-alone setups.

Also, imagine the delight of just editing the HTML files and trying them out immediately!

[jippej]

Hi,

just some thoughts from my side, please ignore if I am totally wrong here.

very interesting topic in respect to OCPP and where to implement what. I noticed that main idea here is that existing hardware needs to be expanded for implementing the OCPP client. I have been professionally involved in managing to setup an OCPP server to connect to many different chargers. conclusion was that not the complete client protocol is implemented and only needed/supported features are implemented in most OCPP capable chargers. As I am not to software savy, I was wondering if it was not possible to implement a leghtweight/custom made OCPP2.0 on the ESP32 with the Arduino JSON library for example (OCPP 2.0 only supports JSON)? As said during our testing we found that many instructions we sent to the chargers just replied back "not supported".

[chris1howell]

Success from LINUX OCPP Example Client https://github.com/NewMotion/ocpp

Connected OCPP 1.6 registered and validated RFID tag.

[chris1howell]

@jippej I do not think you are totally wrong... Basic functions such as Boot Notification, Heartbeat and status are not very complex. I think it is possible to get some functionality on the ESP8266 as the ESP8266 does support websockets. This is the JSON for Boot Notification.

{"chargePointVendor":"OpenEVSE","chargePointModel":"Advanced v5","chargePointSerialNumber":"0002089","firmwareVersion":"4.8.0","meterType":"Internal"}`

Here is a full session with Boot Notification, Status and even a RFID tag authorization.

[INFO ] 2018-06-12 07:31:32,012 de.rwth.idsg.steve.ocpp.ws.ocpp16.Ocpp16WebSocketEndpoint - New connection established: JettyWebSocketSession[id=67f8a1b7, uri=ws://127.0.0.1:8080/steve/websocket/CentralSystemService/0002098]

[INFO ] 2018-06-12 07:31:32,350 de.rwth.idsg.steve.ocpp.ws.ocpp16.Ocpp16WebSocketEndpoint - [chargeBoxId=0002098, sessionId=67f8a1b7] Received message: [2,"0","BootNotification",{"chargePointVendor":"OpenEVSE","chargePointModel":"Advanced v5","chargePointSerialNumber":"0002089","firmwareVersion":"4.8.0","meterType":"Internal"}]

[INFO ] 2018-06-12 07:31:32,351 de.rwth.idsg.steve.service.CentralSystemService16_Service - The chargebox '0002098' is registered and its boot acknowledged.

[INFO ] 2018-06-12 07:31:32,356 de.rwth.idsg.steve.ocpp.ws.pipeline.Sender - [chargeBoxId=0002098, sessionId=67f8a1b7] Sending message: [3,"0",{"status":"Accepted","currentTime":"2018-06-12T14:31:32.351Z","interval":14400}]

[INFO ] 2018-06-12 07:31:32,443 de.rwth.idsg.steve.ocpp.ws.ocpp16.Ocpp16WebSocketEndpoint - [chargeBoxId=0002098, sessionId=67f8a1b7] Received message: [2,"1","Heartbeat",{}]

[INFO ] 2018-06-12 07:31:32,446 de.rwth.idsg.steve.ocpp.ws.pipeline.Sender - [chargeBoxId=0002098, sessionId=67f8a1b7] Sending message: [3,"1",{"currentTime":"2018-06-12T14:31:32.444Z"}]

[INFO ] 2018-06-12 07:31:32,470 de.rwth.idsg.steve.ocpp.ws.ocpp16.Ocpp16WebSocketEndpoint - [chargeBoxId=0002098, sessionId=67f8a1b7] Received message: [2,"2","StatusNotification",{"connectorId":0,"status":"Available","errorCode":"NoError"}]

[INFO ] 2018-06-12 07:31:32,476 de.rwth.idsg.steve.ocpp.ws.pipeline.Sender - [chargeBoxId=0002098, sessionId=67f8a1b7] Sending message: [3,"2",{}]

[INFO ] 2018-06-12 07:31:32,483 de.rwth.idsg.steve.ocpp.ws.ocpp16.Ocpp16WebSocketEndpoint - [chargeBoxId=0002098, sessionId=67f8a1b7] Received message: [2,"3","Authorize",{"idTag":"12345678"}]

[INFO ] 2018-06-12 07:31:32,485 de.rwth.idsg.steve.ocpp.ws.pipeline.Sender - [chargeBoxId=0002098, sessionId=67f8a1b7] Sending message: [3,"3",{"idTagInfo":{"status":"Accepted","expiryDate":"2020-05-01T07:30:00.000Z","parentIdTag":"10025"}}]

[WARN ] 2018-06-12 07:32:02,359 de.rwth.idsg.steve.ocpp.ws.ocpp16.Ocpp16WebSocketEndpoint - [id=67f8a1b7] Connection was closed, status: CloseStatus[code=1000, reason=null]

[chuck-h]

Worth checking out BCIT project here: http://files.mgrid-bcit.ca/download/evid.php

They have written open source C language clients bridging Clipper Creek and Schneider to OCPP.

[chuck-h]

Regarding @glynhudson @DrFrankReade comments on Wifi connectivity issues, has anyone considered HomePlug (powerline ethernet)? I understand this is the network layer used for ISO 15118 Plug and Charge between EVSE and vehicle, so it must be pretty tolerant to the noise levels in this environment. Advantage over wired ethernet is simplified wiring installation.

[DrFrankReade]

Hello,

So as I understand it, HomePlug greenPHY actually runs over the pilot signal for DC charging, but I'm not sure of the exact details, or if it's available during AC charging, because that line is supposed to have a PWM signal for "available current" running over it during regular use. Maybe they superimpose data packets during the high or low sections of the wave? Or maybe it's just off limits. But it's a thing for sure.

On Tue, Dec 4, 2018 at 2:37 PM chuck-h notifications@github.com wrote:

Regarding @glynhudson https://github.com/glynhudson @DrFrankReade https://github.com/DrFrankReade comments on Wifi connectivity issues, has anyone considered HomePlug (powerline ethernet)? I understand this is the network layer used for ISO 15118 Plug and Charge between EVSE and vehicle, so it must be pretty tolerant to the noise levels in this environment. Advantage over wired ethernet is simplified wiring installation.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/OpenEVSE/ESP8266_WiFi_v2.x/issues/114#issuecomment-444286365, or mute the thread https://github.com/notifications/unsubscribe-auth/AJ9L8JwYieFAWNVdt3X62tsN3L3ZiftDks5u1vkygaJpZM4QDASN .

-- W: andy@twobitcircus.com TW: @TwoBitCircus http://twitter.com/twobitcircus | LI: TwoBitCircus http://www.linkedin.com/company/two-bit-circus

TWO BIT CIRCUS Engineering Entertainment Inventors | Developers | Performers

[glynhudson]

Hi @chuck-h, thanks for your comments. Powerline Ethernet is a good suggestion. It would certainly add hardware cost but maybe this cost would be lower than the individual Ethernet installation cost. Interesting idea.

@DrFrankReade I'm pretty sure during AC charging the pilot signal is only used to carry the PWM J1772 pilot signal. It's a real shame that SOC data is not available to the EVSE during AC charging. This would be very useful for EVSE smart scheduling.

[lincomatic]

1) Yes, during AC charging, the pilot is reserved for the PWM advertised current only. You're not allowed to superimpose any signal on top of it.

2) Why do we need to make a special adapter for Powerline Ethernet? Can't users just buy and external Powerline Ethernet adapter (assuming that the EVSE has wired Ethernet)

[chuck-h]

Re: "during AC charging, the pilot is reserved for the PWM advertised current only" Are you certain of this? I have not read the actual ISO 15118 standards but I am pretty sure they anticipate communications continuing during charge. Since HomePlug frequency spectrum is 2 – 28 MHz there is no technical challenge in avoiding interference with the PWM pilot.

[lincomatic]

@chuck-h and @DrFrankReade, Sorry if I'm misunderstanding what you guys are proposing, please correct me if I am misinterpreting your train of thought.

My understanding of HomePlug GreenPHY is that it's an AC powerline standard. As such, what does it have to do w/ our PWM pilot? The most logical thing to do would be to transmit the data over the AC power lines, not the pilot. As for ISO 15118, you are probably talking about new EVSE hardware design, not something we would retrofit into the current OpenEVSE. And again, it seems to be unnecessary complexity, IMHO. Networking and EVSE issues should be handled separately, because the EVSE is a safety device, and as such, we shouldn't be modifying it for communication purposes. The current WiFi implementation is an example of a safe, compartmentalized approach.. put all the logic into an external controller, and call into the EVSE just for whatever data it needs. This way, we don't risk introducing safety bugs into the EVSE when we change anything related to external communication. Ethernet adapters are cheap, and can easily be attached to the ESP8266 hardware. An end user could then take the RJ11 jack, and connect that to an adapter for Powerline Ethernet, or whatever other kind of interface they like.. optical, RF, etc. A modular approach, IMHO, is the most cost effective, because it doesn't force users to pay for hardware they don't need, and it's also the best use of the limited time that us volunteers have to spend on this open source product.

[chuck-h]

@lincomatic is correct that however ISO 15118 uses HomePlug on the pilot line, it is irrelevant to this thread.

The HomePlug usage which is on-topic is to establish network communications with the EVSE. This can certainly be ordinary HPAV modules (no need for GP GreenPhy) like https://www.amazon.com/TP-Link-Powerline-ethernet-Adapter-TL-PA4010KIT/dp/B00AWRUICG.

The main discussion here seems to center on running OCPP1.6J bridge software on an ESP8266 or other embedded processor co-located with the EVSE.

Another plausible approach to consider would be to run native OpenEVSE serial over UDP or TCP to a separate processor which runs the bridge software. At the EVSE end, an off-the-shelf module like https://www.digikey.com/product-detail/en/netburner-inc/SBL2E-100IR/528-1016-ND/2521663 would work (again, watch the 3.3V signal levels), with a short ethernet jumper to an HPAV adapter. Is there a cheaper off-the-shelf solution?

[chuck-h]

@chris1howell FYI I have a forked version of Steve that publishes ampere and kWh data to emoncms. (In fact there is some experimental data from a commercial OCPP1.6J EVSE at http://data.openevse.com/emoncms/vis/auto?feedid=12001 and http://data.openevse.com/emoncms/vis/auto?feedid=12043 .) Fork is at https://github.com/chuck-h/steve

[glynhudson]

As of July 2019 it's mandatory for all charging points installed under the OLEV grant in the UK to have the following smart features. This makes implementing OCPP V1.6 over https a top priority for us. The OLEV grant is up to £500 towards the cost of the EVSE + installation, therefore is very significant.

We're already halfway there to meeting this spec since we have the ability to monitor and record energy consumption.

@jeremypoulter

[DrFrankReade]

That's an amazing subsidy - I worry how the "or an equivalent" part will be interpreted, giving $$ to a company to support a closed standard, the peril being that if said provider goes out of business, the hardware is orphaned, but I digress.

So what happens now? Does a Raspberry Pi Zero piggyback on a new OpenEVSE board with a beefy 5V buck converter and only a 12V power supply? Or the other way around? A 5V board and PSU with a little 12V boost converter to run the pilot and close 12V relays? The price point on the dual voltage supplies is hard to swallow, and I can't find much that's got a heavy 5V rail, it's usually just the 12V that has the amperage. In looking at all the claptrap in my charger at home, an OpenEVSE, an LCD/RTC board, an ESP, a 12>5V external buck converter, and at one point an external level shifter, it's a little busy in there. Plus of course the current transformers and a contactor. More digressing.

Also IEEE 1901, but at this point I need to read up a lot more before I put in any more of my two cents. I do know that ESPs are getting easier to use every day, but being able to put an image on an SD card and pop it in is pretty damn sweet rather than dragging a laptop out to an EVSE, plugging in a serial cord, pressing the reset and upload, or an OTA update that always risks stranding the device.

A pi / SBC will allow for the giant bloated style of web interface that people have come to love, and they're so damn stinking cheap, not to mention having all of the foreseeable horsepower to do encryption, logging, and so on.

¯_(ツ)_/¯

[jeremypoulter]

I have been looking at this with a view to (first) integrating in to the Node.JS. My first thoughts were to do a small bridge with a suitably mature library that could run on the same device that the openevse_wifi_server is running on. However after looking at some simulators ([1], [2], [3]) the actual protocol bit looks fairly simple.

What looks much more complex is the actual integration., What does it actually mean to add OCPP support to OpevEVSE, as in what is the mapping of the OCPP stuff to OpenEVSE stuff?

It would be helpful if someone with one domain knowledge could provide some guidance.

I presume the initial goal is still to implement 1.6 for the OLEV grant (and not go for 2,0 right now)?

SteVe has already been mentioned her, but are there any other OCPP servers that we should be testing compatibility with?

Also, re the OLEV grant requirements, I think a case can be made that we already meet those requirements. OCPP is just a recommendation:

..., or an equivalent

gives you the opportunity to use something else.

The cyber security bit is more of a problem, the current ESP8266 version is not so great so that is more the failing point for the OLEV grant IMHO. Also on that point:

... any communications are exchanged in a secure manner ...

I assume they actually just mean over the network and it would not be expected that the serial comms also be secure? This also kind of implies that unencrypted comms are not allowed? Kind of makes having a local web UI a a bit challenging. So the more important question is, what do you have to do/show/present to prove your device meets those 'requirements'?

[TechOverflow]

The 1.6 specification directly says that a VPN tunnel to the backend is secure enough (network level security). This would only require a router between the device and the server that is capable of making a (secure) VPN tunnel to the server and routes all traffic. I'm surprised they require it considering there's no harm that can be done to a homeowner's wallbox. There is no private data in the messages, there is no way to "steal a charge" without physical access. Even with physical access, the damage would be miniscule and not worth the effort to spoof a session. Afaik, ocpp2.0 may enable communication of tariff info, in the distant future there may be ways to send payment info, although I have my doubts. Either way, the applicant can (and should) reference the 1.6 standard's security recommendations.

I can make a logic overview explaining the software to hardware implementation if there's interest.

[wbitholedotbe]

It is not about stealing or hijacking the data. It is about Tampering the data. Changing values... If you want to submit your charge session and kwh from your taxes this is mandatory.

Op wo 20 feb. 2019 om 02:53 schreef TechOverflow notifications@github.com:

The 1.6 specification directly says that a VPN tunnel to the backend is secure enough (network level security). This would only require a router between the device and the server that is capable of making a (secure) VPN tunnel to the server and routes all traffic. I'm surprised they require it considering there's no harm that can be done to a homeowner's wallbox. There is no private data in the messages, there is no way to "steal a charge" without physical access. Even with physical access, the damage would be miniscule and not worth the effort to spoof a session. Afaik, ocpp2.0 may enable communication of tariff info, in the distant future there may be ways to send payment info, although I have my doubts. Either way, the applicant can (and should) reference the 1.6 standard's security recommendations.

I can make a logic overview explaining the software to hardware implementation if there's interest.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/OpenEVSE/ESP8266_WiFi_v2.x/issues/114#issuecomment-465387098, or mute the thread https://github.com/notifications/unsubscribe-auth/AHiI34uTU-i83zRJi2IWL6uPzxegi_5Zks5vPKqRgaJpZM4QDASN .

[DrFrankReade]

I'd argue it's about protecting the grid from attack in the future - Imagine on a hot sweltering day when normally all EV charging is postponed, a bad actor instantly activates as many units at full current as possible, or changing the pilot signal to full amperage regardless of the EVSE physical capacity. This is a requirement to take very seriously.

On Wed, Feb 20, 2019 at 5:45 AM wbitholedotbe notifications@github.com wrote:

It is not about stealing or hijacking the data. It is about Tampering the data. Changing values... If you want to submit your charge session and kwh from your taxes this is mandatory.

Op wo 20 feb. 2019 om 02:53 schreef TechOverflow <notifications@github.com

:

The 1.6 specification directly says that a VPN tunnel to the backend is secure enough (network level security). This would only require a router between the device and the server that is capable of making a (secure) VPN tunnel to the server and routes all traffic. I'm surprised they require it considering there's no harm that can be done to a homeowner's wallbox. There is no private data in the messages, there is no way to "steal a charge" without physical access. Even with physical access, the damage would be miniscule and not worth the effort to spoof a session. Afaik, ocpp2.0 may enable communication of tariff info, in the distant future there may be ways to send payment info, although I have my doubts. Either way, the applicant can (and should) reference the 1.6 standard's security recommendations.

I can make a logic overview explaining the software to hardware implementation if there's interest.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub < https://github.com/OpenEVSE/ESP8266_WiFi_v2.x/issues/114#issuecomment-465387098 , or mute the thread < https://github.com/notifications/unsubscribe-auth/AHiI34uTU-i83zRJi2IWL6uPzxegi_5Zks5vPKqRgaJpZM4QDASN

.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/OpenEVSE/ESP8266_WiFi_v2.x/issues/114#issuecomment-465579524, or mute the thread https://github.com/notifications/unsubscribe-auth/AJ9L8JlYmKW44_wQUrKO6O21FJLW9MQ4ks5vPVF9gaJpZM4QDASN .

-- W: andy@twobitcircus.com TW: @TwoBitCircus http://twitter.com/twobitcircus | LI: TwoBitCircus http://www.linkedin.com/company/two-bit-circus

TWO BIT CIRCUS Engineering Entertainment Inventors | Developers | Performers

[beaylott]

As part of our work with @glynhudson on a new project we will be implementing an OCPP server on a pi in order to translate requests from an upstream control server using a different protocol. This is more like a home energy management system topology (as it is with the emonpi). The standard doesnt actually seem very well suited to domestic EVSE context which makes the UK govs decision a bit weird. Is anyone aware of a lightweight implementation of the server which might be appropriate for this context?