OpenEVSE EV Charging station with Emoncms WiFi Integration

glyn.hudson · 8 December 2016 17:31

This thread is to document my progress building and testing an OpenEVSE electric car charging station.

Update: Build has now been documented in a blog post

Update #2: OpenEnergyMonitor and proud to announce that we are now the UK / Europe reseller for OpenEVSE charging stations, see OpenEnergyMonitor Online Shop.

OpenEVSE supply open-hardware charging stations and use a WiFi ESP8266 and Emoncms to monitor energy dispensed and other charging statistics e.g. temperature.

Ful disclosure: @chris1howell from openEVSE has provided me with a P50D level 2 unit with Wifi kit to build and test charging with a Nissan Leaf EV.

There is a lot of overlap between our emonESP firmware (WiFi Emoncms link) and the firmware running on the ESP8266 inside the openEVSE. @TrystanLea based the inital emonESP development on the OpenEVSE firmware, since then a few of the emonESP developments we have worked on have filtered down into the OpenEVSE code.

I will update this post with more info and my experiences with the OpenEVSE kit once I get it up and running. Here is the build process so far:

glyn.hudson · 10 December 2016 00:32

Finished the build this evening, fitted ESP8266 WiFi module and tested with a power up. So far so good, but it did make my jump when the big relay did a self test, it makes quite a ‘clunk’!

I also tested posting to the openEVSE version of Emoncms Emoncms - user login

Woop, woop! Up and running charging Nissan Leaf @ 6Kw

Now exploring web interface…and posting to emoncms.

ebsol · 10 December 2016 11:53

Are you going to be linking the OpenEVSE and your OpenEnergyMonitor in some way, so that the charging rate can be balanced with spare solar energy?
This is something I am wanting to do with my setup.
As I understand it, the charger can be controlled in real time during charging to set the charging current from 6 to 32 amps in 1 amp steps.

glyn.hudson · 11 December 2016 00:56

Yup, that’s the plan

Do you also have an openEVSE? I’ve been very impressed with the hardware and firmware so far.

Have you been controlling the charge current via RAPi commands? I have been testing RAPI commands via the web interface, I seem to be able to issue the command but not receive a response. Do you need to be actively charging to RAPI commands to work?

ebsol · 11 December 2016 11:41

[quote=“glyn.hudson, post:4, topic:2439, full:true”]
Do you also have an openEVSE?[/quote]
Yup, Here’s mine:

I’ve only got as far as assembling and testing it on the bench. I am hoping to find some time over the xmas break to do some playing with communications etc. In the meantime, I will be watching your posts with great interest.

p.s. obviously that cable from an old iron is only being used for bench testing the unit, not charging.

mastrogippo · 14 December 2016 09:22

Here’s my setup. I ditched the evse ESP firmware and rewritten it to push data to MQTT and adjust the power to follow a virtual feed that represents the spare power (hence my bug report Adding a node with MQTT problem - #5 by Jon )

cab123 · 14 December 2016 10:56

Hi all, i have had a similar system last year (openEVSE + ESP-12 with RAPI) and i can confirm it work great. Since i developed my own evse with native MQTT i moved in a different direction.

If any of you are actively developing MQTT integration in a EVSE please consider my node-red implementation to automatically control the charge of the car here-> Diverting Solar to Charge an Electric Car - #45 by cab123
If you don’t agree with the implementation let me know i think we can make that part almost “plug and play”. We just need to agree on the messages sent to to the MQTT broker to drive the Node-Red logic correctly.

glyn.hudson · 14 December 2016 17:13

Yes, I think MQTT is the best way forward. MQTT keeps all the doors open to interoperability between systems. I use MQTT extensively on my home setup.

IMO the next step is to add MQTT support to the ESP in openEVSE and allow control of functions such as controlling charge rate from MQTT then as you have done have a nodeRED flow to control the diversion of solarPV. It would also be possible to use emoncms to publish to MQTT. However, for this application I think using nodeRED gives more flexibility.

cab123 · 14 December 2016 17:27

Right now my node-red implementation requires only the selected amps and working mode. The actual amps used for the adjustments come from a direction-aware energy monitor placed on the main circuit.

As a first approach and to avoid heavy development on the openEVSE ESP code, would you be able to add a new value from the ESP and route it to MQTT?

That value would be the selected Amps, it would appear in emoncms as a input but routed to a MQTT topic.

Is the ESP always posting to emoncms? Or posts only if the car is charging?

glyn.hudson · 16 December 2016 00:47

@cab123 I have taken a look at your EV charge controller thread. I really like what you have done with MQTT. I am going to try and do the same using OpenEVSE

The OpenEVSE ESP8266 posts to emoncms (well http://data.openevse.org Emoncms instance by default) all the time.

OpenEVSE has the ability to control the charging current via RAPI commands, see example of using the openEVSE web interface (running from an ESP8266) to reduce the charge rate to 13A. The graph on the left shows the current being drawn by the EVSE reducing as a result of the RAPI command `$SC 13’

Do you agree if the RAPI commands could be set via MQTT it would make openEVSE very flexible and easy to integrate with nodeRED control algorithms? This would not be too difficult to add.

How about this as an idea for a possible MQTT topic structure:

topic to set current: openevse/control/current
topic to read current current openevse/status/current

cab123 · 16 December 2016 11:02

Hi Glyn, i really appreciate your feedback, having a look at someone else’s code is always hard so thanks for the opportunity.

Let’s do this step-by-step.

1. My EVSE connects and it’s host name that is used for mDNS service is the MQTT topic:

post:   evse/cab123EVSE/from
listen: evse/cab123EVSE/to

2. NodeRED listens to this topics:

evse/+/from/#

“evse” is the base MQTT configured on my EVSE and is used to separate traffic for easier debugging.
“+” is any name of the EVSE.
“from” is hard coded. It represents messages coming from the EVSE

So with this info i’m able to reply to any EVSE that talks with me. Because the reply topic is simply swapping “from” to “to”

evse/+/to

Now to port this idea to OpenEVSE:

OpenEVSE posts data to emoncms
emoncms posts data to MQTT, topic evse/glynEVSE/from
NodeRED need to send a message to the EVSE.

How?

Q1. In order to do do this without MQTT’ing OpenEVSE we need to know it’s IP address or mDNS host when we want to reply
Q2. Also we need to diferentiate OpenEVSE (RAPI) from the other EVSE’s so NodeRED takes additional step and builds the correpondent RAPI call

We could use the normal reply channel evse/glynEVSE/to and develop a new function that parses the message and sends a RAPI call. However, the original message need reachability information (Q1) and a flag indicating it is a OpenEVSE EVSE (Q2).

Something along these lines:

[{“id”:“987b588a.29ddd”,“type”:“mqtt in”,“z”:“2ad08bfd.22919c”,“name”:“Control OpenEVSE”,“topic”:“evse/+/to/#”,“qos”:“2”,“broker”:“858bdb7c.9c0948”,“x”:152.5,“y”:1201,“wires”:[[“7913113c.e62b6”]]},{“id”:“7913113c.e62b6”,“type”:“function”,“z”:“2ad08bfd.22919c”,“name”:“”,“func”:“// D[0] = "OpenEVSE"\n// D[1] = 192.168.1.1\n// D[2] = A\n// D[3] = 16\n\nvar D = msg.payload.split(","); // split incoming message\n\nif(D[0] != "OpenEVSE") return[null];\n\nvar rapi;\n\nif(D[2] == "A") {\n rapi = "$SC";\n if(parseInt(D[3]) == 6) { rapi += D[3] + "*10"; }\n if(parseInt(D[3]) == 7) { rapi += D[3] + "*11"; }\n if(parseInt(D[3]) == 8) { rapi += D[3] + "*12"; }\n if(parseInt(D[3]) == 9) { rapi += D[3] + "*13"; }\n if(parseInt(D[3]) == 10) { rapi += D[3] + "*3B"; }\n if(parseInt(D[3]) == 11) { rapi += D[3] + "*3C"; }\n if(parseInt(D[3]) == 12) { rapi += D[3] + "*3D"; }\n if(parseInt(D[3]) == 13) { rapi += D[3] + "*3E"; }\n if(parseInt(D[3]) == 14) { rapi += D[3] + "*3F"; }\n if(parseInt(D[3]) == 15) { rapi += D[3] + "*40"; }\n if(parseInt(D[3]) == 16) { rapi += D[3] + "*41"; }\n if(parseInt(D[3]) == 17) { rapi += D[3] + "*42"; }\n if(parseInt(D[3]) == 18) { rapi += D[3] + "*43"; }\n if(parseInt(D[3]) == 19) { rapi += D[3] + "*44"; }\n if(parseInt(D[3]) == 20) { rapi += D[3] + "*3C"; }\n if(parseInt(D[3]) == 21) { rapi += D[3] + "*3D"; }\n if(parseInt(D[3]) == 22) { rapi += D[3] + "*3E"; }\n if(parseInt(D[3]) == 23) { rapi += D[3] + "*3F"; }\n if(parseInt(D[3]) == 24) { rapi += D[3] + "*40"; }\n if(parseInt(D[3]) == 25) { rapi += D[3] + "*41"; }\n if(parseInt(D[3]) == 26) { rapi += D[3] + "*42"; }\n if(parseInt(D[3]) == 27) { rapi += D[3] + "*43"; }\n if(parseInt(D[3]) == 28) { rapi += D[3] + "*44"; }\n if(parseInt(D[3]) == 29) { rapi += D[3] + "*45"; }\n if(parseInt(D[3]) == 30) { rapi += D[3] + "*3D"; }\n if(parseInt(D[3]) == 31) { rapi += D[3] + "*3E"; }\n if(parseInt(D[3]) == 32) { rapi += D[3] + "*3F"; }\n}\n\nmsg.url = "http://" + D[1];\nmsg.payload = "r?rapi=" + rapi;\nmsg.method = "GET";\nmsg.headers = "text/html";\n\nreturn msg;”,“outputs”:“1”,“noerr”:0,“x”:368.5,“y”:1241,“wires”:[[“e02ecb6b.2bbd58”]]},{“id”:“e02ecb6b.2bbd58”,“type”:“debug”,“z”:“2ad08bfd.22919c”,“name”:“”,“active”:true,“console”:“false”,“complete”:“true”,“x”:553.5,“y”:1200,“wires”:},{“id”:“858bdb7c.9c0948”,“type”:“mqtt-broker”,“z”:“2ad08bfd.22919c”,“broker”:“192.168.20.240”,“port”:“1883”,“clientid”:“”,“usetls”:false,“verifyservercert”:true,“compatmode”:true,“keepalive”:“60”,“cleansession”:true,“willTopic”:“”,“willQos”:“0”,“willRetain”:null,“willPayload”:“”,“birthTopic”:“”,“birthQos”:“0”,“birthRetain”:null,“birthPayload”:“”}]

You can test by posting to MQTT:

mosquitto_pub -t evse/glynEVSE/to -m “OpenEVSE,192.168.20.1,A,18”

This would be really flexible since it easily accomodates more RAPI messages.

Let me know what you think

ebsol · 16 December 2016 12:14

Hi @glyn.hudson and @cab123. I won’t pretend to understand any of what you just said, but it sounds exiting
What part of the system would be making the intelligent decisions?
For example, you would not want to stop/start a charge every time there is a passing cloud.
Also would it be possible to sub-divide the surplus solar power to multiple items, such as say 25% to emersion heater, 75% to EVSE?

cab123 · 16 December 2016 12:58

Ahh that’s a really nice question. As the system is now they will compete for their share of the surplus, meaning the first process that gets the energy will make the others starve. But actually it can work.

Feeding EV’s is a completely different history than routing surplus to heating. The first is rough and the second is precise.

Maybe if the EV errors below the maximum available surplus, the resistor diverter can take the rest with great accuracy and achieve zero exporting. However the controller logic still needs to be aware of both.

sean_fosberry · 16 December 2016 20:34

Evening all. I experimented with variable rate charging in the summer of 2015 with my Leaf. I do own an OpenEVSE (since 2014) but I didn’t use that I used a Virdian EPC and an arduino based board made by another forum member driven by inputs from OpenEnergyMonitor / Emonms over RF.

Some finding that may be interesting for others :

The leaf will support charging from 6 amps up in 1 amp steps. It switches almost instantly when the EVSE changes the max available current.
The leaf will also support charging ‘pause’. When the sun goes in you can command the car to stop pulling current by switching the available current to zero. At this point the leaf charging lights stop flashing and the 3rd light on the dash flashes. (you can also test this with an OOTB OpenEVSE, when charging press the button and it pauses, press again and it continues.)
I only have 12 x 250w (3kW) of solar installed currently. Its surprising how little time in the day I have enough ‘true surplus’ to charge only from solar. With a base load in the house of 2-300w, even a minimum charge of 6A means I need over 1700w from the PV to be in the clear. On a good summers day I am only above this threshold for a max of 6 hours a day which only allows a max of about 8 kWh to be captured directly from PV.

test tracking the solar surplus and what could be available :

logging what was going on to emoncms :

monitoring the actual power drawn by the car as I change the available current value :

It was an interesting project but I wasn’t very happy with the robustness of the arduino / viridian EPC solution. My plan was to come back to it at some point but I then started thinking of how this could actually be used in other ways and that an OpenEVSE based solution might be more suitable for me.

After some thinking I began to see that OpenEVSE integrated with OpenEnergyMonitor could have a few applications. These could be made available as ‘operating modes’, such as :

mode 1) Solar Surplus : This is the one everyone comes to first and whats first.

mode 2) Solar Divert : The same as above, but taking the house base load out of the calculation. This way your car can be powered by sunshine, the house from your renewable energy supplier!

mode 3) Full manual : I would like to be able to manually adjust the current limit remotely and start / stop charge remotely.

mode 4) Grid carbon : Not that useful practically but I thought it would be interesting to demonstrate the ability to stop charging when Grid Carbon rises above a certain threshold value you set / choose.

mode 5) Peak Time Current Adjustment : When I get home I want to plug my car in to charge (so I don’t forget) but may not want it to pull full current as it s peak time. It would be possible / interesting to set a max current profile for the car to pull for each hour of the day. This way it could be plugged in put paused from say 5pm until 8pm then could start to charge at a low current rate of 6A ramping up to max after 11 or 12 when the grid is in surplus.

mode 6) SoC controlled : charge the car until a certain SoC is reached. I only need say 55% SoC to get to work so It would be good to plug in and forget about it rather than have to nip back out at some point to check the car and unplug.

mode 7) Timed : Not all EVs have charging timers so it would be good to plug in and then the EVSE command a charge (for instance) during the Economy 7 hours only.

I did an bit of testing using emonscms as a back end to drive it and setting modes and values in it via a simple web interface and the emoncms API but since then I’ve not really progressed it. I may get another OpenEVSE (as my current one is in daily use at work) and add the wifi functionality to learn a bit more…

ebsol · 22 December 2016 11:36

Right, I’m all tooled up and ready to play.

All I am short of now is knowledge.

I have good knowledge of c/c++ programming on microprocessors, but Linux, NodeRED, MQTT, etc are all new to me.

As this is a bench setup I think my first step is to provide some form of spoofed inputs to simulate live domestic consumption and solar generation. This got me thinking, is there a reasonably easy way to play back readings from my installed emonPi from last summer when I had some decent solar generation, and inject that as if it was live data?

ebsol · 26 December 2016 16:37

Answering my own question, I found, via the web interface, I could export selected data in .csv format to my PC where I then wrote a program to convert it back into Jeelib format.
Then, after changing the line:

com_port = /dev/ttyAMA0
to
com_port = /dev/ttyUSB0

In the config file, I was able to feed previous real data in as new samples for testing.

glyn.hudson · 29 December 2016 19:12

Wow, nice setup. You have disected an emonpi and openevse. I’m working on adding mqtt support to the openevse esp then you can just point this at the emonpi mqtt server and use nodered (also built into the emonpi) to build the intelligent charging implementation of your choice

ebsol · 31 December 2016 21:09

[quote=“glyn.hudson, post:17, topic:2439, full:true”]
You have disected an emonpi and openevse[/quote]
No dissecting necessary. I Ordered a spare board and esp with my OpenEVSE kit with the long term goal of converting my Rolec to give me a second OpenEVSE charger. One in the garage and one outside. And the EmonPi board was d.o.a. and got replaced by the shop, but I think I have fixed this one (at least good enough for bench testing). The rest is made up form stuff I had lying around. I had to recompile the OpenEvse to work with my display which only has the PCF8574 backpack.

[quote=“glyn.hudson, post:17, topic:2439, full:true”]
I’m working on adding mqtt support to the openevse esp[/quote]
A possible heads up for you:
What version ESP8266 Board Manager are you using? I reflashed mine using Arduino IDE with the latest after doing something wrong during setup, and then could not get it to communicate with Emoncms - user login. It turns out it only currently works with 2.2.0. see here

glyn.hudson · 2 January 2017 20:42

Thanks for the heads up. I will see what I can do to help.

@sean_fosberry do you think there are there any issues with changing the charge rate of an EVSE very frequently? E.g do you think changing the charge rate continuously would cause wear to the EV’s charging electronics and battery? Common sense suggests that if we are matching charge rate to excess solar generation we should apply a smoothing factor.

sean_fosberry · 2 January 2017 20:59

I would say no (that my opinion anyway!) The variation is tiny compared to driving. We are talking 0 to 1400 watts, then steps up to (worst case, if you have enough panels and a 6.6kw charger) 6600 watts. Driving you will be at 0 watts draw one second then pushing 80,000w if you floor it. These are tiny variations up to a max of 0.25C.

My 13 MY jap leaf 1 seemed happy to do whatever it was commanded when I tested it. I did find my UK 15 MY leaf did refuse to come back from ‘pause’ a couple of times but that might have been a problem with my code or the variable resistor chip I was using with the mainpine EPC.