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.
Hy Glyn, did you have the chance to review my last comment? do you agree with that approach to control the OpenEVSE?
Sorry, what comment are you referring to?
1 Like
This one
I’ve just published a blog post documenting the open EVSE build and usage so far OpenEVSE EV Charge Controller - Blog | OpenEnergyMonitor
1 Like
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…
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.
Yup, got a working demo issuing RAPI commands via MQTT 
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
Cool. Downloading it now… 
1 Like
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. 
> 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
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…
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
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
Update#2: firmware repo for OpenEVSE wifi 2.0 has been moved to: GitHub - OpenEVSE/ESP8266_WiFi_v2.x: ESP8266 WiFi for OpenEVSE Version 2.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
- 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 
1 Like
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: