[quote=“glyn.hudson, post:4, topic:2439, full:true”]
Do you also have an openEVSE?[/quote]
Yup, Here’s mine: 
p.s. obviously that cable from an old iron is only being used for bench testing the unit, not charging.
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 )
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.
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.
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?
@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
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:
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
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?
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.
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 :
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…
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?
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. 
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
[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
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.
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.
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?
This one
