Community
OpenEnergyMonitor

Community

OpenEVSE EV Charging station with Emoncms WiFi Integration

ev
charging
openevse
Tags: #<Tag:0x00007f880ee219e8> #<Tag:0x00007f880ee218a8> #<Tag:0x00007f880ee21768>
(Cliff) #15

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

All I am short of now is knowledge. :disappointed:

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

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?

(Cliff) #16

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. :grinning:

(Glyn Hudson) #17

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

(Cliff) #18

[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 http://data.openevse.com/emoncms/. It turns out it only currently works with 2.2.0. see here

(Glyn Hudson) #19

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) #20

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.

1 Like
(Glyn Hudson) #21

Good point, I was more concerned about the control electronics than the battery. However, I guess the control electronics are designed for exactly the purpose. I have a 2014 UK Leaf with 24KW battery that I have only owned for a few weeks, therefore, I’m still treading lightly and proceeding slowly! Thanks for sharing your experience.

(Antonio) #22

Hy Glyn, did you have the chance to review my last comment? do you agree with that approach to control the OpenEVSE?

(Glyn Hudson) #23

Sorry, what comment are you referring to?

1 Like
(Antonio) #24

This one

(Glyn Hudson) #25

I’ve just published a blog post documenting the open EVSE build and usage so far https://blog.openenergymonitor.org/2017/01/openevse-build/

1 Like
(Bryan Mayland) #26

Looks really good! I have to say I love the idea of adjusting the charging current based on the current solar output. Unfortunately, I would be at work when the sun is shining and my car would only be home when it is dark so there’s no real opportunity to take advantage of such a cool feature.

I love all the integration that can be done with these ESP modules. I’m not sure when I became aware of them, but I clearly wasn’t when I built my OpenEVSE. I used a GL.iNET “smart router” with OpenWrt installed and write a plugin for the LuCI webui luci-app-openevse that allowed you to control the charging current and see the status and all that. I also have a daily cron job to keep the RTC synced with the NTP time. It’s been pumping into emoncms (using plain ole HTTP POST) ever since!

Although with all this cool integration you’re making me think I should revisit that project…

(Cliff) #27

Well done, that is a nice, interesting blog.

[quote=“glyn.hudson, post:17, topic:2439, full:true”]
I’m working on adding mqtt support to the openevse esp…[/quote]

Have you made any progress on that yet?
I’d be happy to do some testing when you have something releasable, and it will help me to learn about mqtt which is my current mission.

(Glyn Hudson) #28

Yup, got a working demo issuing RAPI commands via MQTT :slight_smile:


Publish RAPI commands to: <base-topic>/rapi/<rapi_command> <rapi_value>

Base topic can be set via openEVSE web interface:

e.g. to set current to 13A:

openevse/rapi/$SC 13

See video demo:

Update: code has been merged by @chris1howell into OpenEVSE dev branch

1 Like
(Cliff) #29

Cool. Downloading it now… :thumbsup:

1 Like
(Cliff) #30

Thanks @glyn.hudson. I created a simple test flow in Node-Red on the pi and it works great:

flow.txt (2.0 KB)

The only thing that caught me out was I rebuilt the esp to send the debug output to “Serial1”, which meant nothing was going out on “Serial” in mqttmsg_callback().
So I added identical calls to “Serial”, so I could monitor and communicate simultaneously, and it started working. :grinning:

> void mqttmsg_callback(char* topic, byte* payload, unsigned int length)
> {

>   // ASSUME RAPI COMMANDS ARE **ALWAYS PREFIX BY $ AND TWO CHARACTERS LONG**
>   
>   // print RAPI command received via MQTT sub topic e.g. "$SC"
>   String topic_string = String(topic);
>   int rapi_character_index = topic_string.indexOf('$');
>   
>   if (rapi_character_index > 1)
>   {
>     // Print to serial RAPI command from mqtt-sub topic
>     for (int i=rapi_character_index; i<rapi_character_index+3; i++)
>     {
>       DEBUG.print(topic[i]);
>       Serial.print(topic[i]);
>     }
>     DEBUG.print(" ");
>     Serial.print(" ");
>     // print RAPI command value received via MQTT msg
>     for (int i=0;i<length;i++)
>     {
>       DEBUG.print((char)payload[i]);
>       Serial.print((char)payload[i]);
>     }
>     DEBUG.println("");
>     Serial.println("");
>   }
> }
1 Like
(Glyn Hudson) #31

Nice, good work. I’ve not experimented using two UARTs. Would be perfect for this application. What pins do you connect to the huzzah to access the second UART?

I think the ability to print to the second UART is built into the openEVSE code, I think if you un-comment #define DEBUG_SERIAL1 then all DEBUG.print commands will go to UART1 while Serial.print will go to UART0 I believe. I’ve not tested this…

(Cliff) #32

GPIO2 is the “Serial1” TX pin. There is no associated RX pin as I believe that got used for the flash chip connection.

[quote=“glyn.hudson, post:31, topic:2439, full:true”]I think if you un-comment #define DEBUG_SERIAL1 then all DEBUG.print commands will go to UART1 while Serial.print will go to UART0 I believe. I’ve not tested this…
[/quote]
Yup, that’s what I did and it worked great.

1 Like
(Glyn Hudson) #33

I’ve just pushed a PR to OpenEVSE Wifi ESP dev branch fixing some issues with RAPI over MQTT, it;s working much more reliably for me now.

Update: my pull-request has now been merged into the OpenEVSE_RAPI_WiFi_ESP8266 dev branch :slight_smile:

Update#2: firmware repo for OpenEVSE wifi 2.0 has been moved to: https://github.com/OpenEVSE/ESP8266_WiFi_v2.x

See real-world demo controlling nissanLEAF charge rate:

Here are the main changes included in the PR:

  • Tweaks to make RAPI over MQTT reliable
  • Add hostname support eg. http://openevse now works on local network :slight_smile:
  • Slow down update_rapi_values() to 5s intervals to make web interface more responsive and fix firmware upload via .bin upload
  • Don’t show security sensitive info in serial print or web interface e.g. passwords or WiFi PSK
  • Various web interface bug fixes & tweaks
  • Initial start on creating a user guide in the readme

Now the ground works is in place I have started work on charge rate control from solar PV. I have decided to create both a NodeRED flow to handle the control logic and also add the ability for the ESP subscribe to the solar PV feed and control the charge rate locally. Both approaches have their merits, the techno savvy user who wants a super reliable, secure and very customisable system will probably choose to use nodeRED on a Pi connected to the OpenEVSE via serial (or MQTT / HTTP) while other users will probably go for using the ESP with less customisable options but easier setup.


OpenEnergyMonitor store is due to become a reseller for OpenEVSE charging stations in Europe, we are expecting stock of units next week :smiley:

1 Like
(Glyn Hudson) #34

I’ve just started a new thread to document my current progress using NodeRED and MQTT to control OpenEVSE charge rate based on solar PV production: