I’ve been reading about OCPP - thanks paul for that, i had no idea what it was - and it is not Open like Openenergymonitor, it’s open for the companies that what to be part of it.
I found no server, and no implementation ready to test, it’s all about the possible messages that a unknown central server makes to the charging station. Actually V1.6 can also change pilot signals, however only V2.0 (draft) brings full encryption and that seem really late.
For a personal charging station it’s completely overkill and useless.
For a commercial project it’s perfect
For a community driven charge infrastructure would be interesting ( but probabily illegal in most contries)
Using a Solar Cell to Control an EVSE (via the EPC)
Hi All,
I have not read all the way through this thread so forgive me if the subject of this post has already been mentioned or is not relevant.
People trying to match their EV charging current to their PV output (to minimise exported energy) may wish to consider using a small solar cell in proximity to the EVSE with a reasonably clear view of the sky. On the basis that the solar cell will be illuminated in approximate proportion to the PV array and at the same time (roughly), this may be a lot easier to implement than other methods especially when the EVSE is remote from the PV and/or its control electronics (ie a clamp-on inductive-type sensor is inappropriate/too expensive).
It would certainly be a useful addition to what has already been submitted here if one were interested in using the Viridian (Mainpine) EPC which I sell through my webshop at EVBitz.uk (related plug so I hope it doesn’t upset the moderators).
I understand your point, however in my opinion the best way is to have a remotely controlable EVSE, like the one i’m developing here (EVSE Colaborativo - Clubeletricos.com).
With this EVSE, the integration is direct, since it talks the same language as the IoT platforms like Node-RED. To make everything work we just need a bidirectional energy sensor and a raspberry pi ( a emonPi) and we’re set.
There are other EVSE that can change Amps, instead of adapting a solar cell to change the current based on the intensity, maybe it’s easier to adapt a ESP8266 to control the amps and provide remote control via WiFi. OpenEVSE is a great example of this approach. It should’t be hard to integrate ESP8266 with the Viridian EVSE.
This only works if you can assume that all the solar is there to be diverted. In my set-up I am only diverting - or trying to - the spare solar that is not already being used in the house, i.e. what I would otherwise export.
The above link is to my first build of a ‘surplus power’ charger using your Viridian EPC and a modified emontx v2. It worked very well and I even got several enquiries as to whether I would build a commercial version. It’s a very accessible solution for the electronics DIYer.
Recently I invested in an OpenEVSE unit as it is more customisable. My new EVSE will wait until the Tesla Powerwall home battery is 90% charged before charging the EV using surplus solar. I’m also going to include an Economy 7 mode. I’m almost there - Node-RED was a learning curve!
Thanks for the update. I hope it goes well and let me know if you do come up with a commercial version as I have had a fair amount of interest from people wanting this sort of facility. So, I would be interested in selling it.
Regards, Martin.
EVBitz.uk Limited
Wychwood
Widford Road
Much Hadham
Herts
SG10 6EZ
UK
We have been busy working on a significant update for OpeneEVSE Wifi which now includes full in-built solar PV diversion capabilities i.e. all diversion calculations are made on the ESP unit inside the OpenEVSE, nodeRED is not required. The solar data comes from an emonPi via MQTT.
Solar PV divert can be enabled by selecting Eco mode in the UI web page.:
Just tested using Grid Import / Export feed to modulate charge rate based on EXCESS solar PV i.e house consumption takes priority. EV will reduce consumption if household demand increases e.g. switching on a kettle:
I could add some real life scenarios, however my graphs of solar + consumption + EV charging are kind of ugly. Anyway i started browsing my emoncms history and found this one i’d like to share with you:
The algorithm is optimized for the maximum power, so everytime the power is above threshold the EVSE reacts. If the power is below the threshold, only 1 EVSE change/min is allowed. I’ll change the behavior for solar mode and report back the changes.
Now there is a question i haven’t thought much and maybe you guys could help. Since the car charges in 1A steps, in the [ -1A, 1A] range would you prefer to let go and inject and never import or would you prefer to consume a little from the grid and make sure to export nothing?
I am implementing a “winter” mode, where the surplus diversion is based on a break-even calculation of day/night rates on my E7 tariff - i.e. in summer I divert only available power while in winter I will divert power that would not cost me more than overnight charging (about 60%, but it will be based on actual tariff values and the ratio in a node-red function calc).
“top up” mode - I arrive at home, I am empty but know I need to drive 5 miles later. I want to click a button that adds 1kWh per click at full charge rate and counts down delivered kWh until done. This can also be done in advance of arriving at the EVSE so it is waiting, ready to go. A quick calculation based on a static input can convert this to miles (based on your personal estimate of miles/kWh).
The second one works now, the first is just some extra work from a previous incarnation of my node-red flow.
Not sure if these are useful, but they work for me
Thanks for the suggestion. Yes, both your suggestions make total sense. I’ll add it to the do-to list. Although it sounds like someone like yourself would be batter controlling the OpenEVSE Via RAPI over MQTT from a nodeRED flow to have total control over the unit. It sounds like this is what you are already doing! For the benefit of others here’s am example node-RED flow to control the OpenEVSE divert via MQTT:
I’ve been fine tuning my solar algorithm and found some interesting things i’d like to share on this topic
there is the need to make small step approximation when the calculations of candidate EVSE Amps is close to the real consumption
The car (2013 MK2 Nissan Leaf) takes as much as 40 seconds to start charging. since my algorithm only relies on the total installation consumption there are unwanted peaks at each start, as seen on the image below and that were fixed:
the car takes some time to change amps and the meter more time to detect changes, the energy meter is updating every 5seconds and i found that i had to prevent consecutive changes to the EVSE.
The final result is better than i expected as shown below on a cloudy day:
the last tweak was to implement the corner case of having to choose between minimizing import or export. The latter was chosen, I prefer to use all of the sun’s direct energy and import some energy from the grid. And the final result is this:
I had to add a calibration multiplier because even though the adjustment was almost self calibrating it both lagged (a bit like you say) and also in some edge cases would bounce around the target PWM but never converge.This will account for the difference between the CT readings on the emonTX and the car’s idea of the current (at whatever voltage it is seeing).
I apply this at the very last step before outputting the PWM value so that any other “fiddles” I do, like winter/summer allowances etc., do not affect this roughly constant number.
I created a set of node-red buttons that increased or decreased the calibration by 0.01% and then, while charging, moved it around until the whole thing just “clicked” into sync - in my case about a 0.96 (96%) multiplier.
Awsome node red sketch, I’ve been playing with it and have got it working with my Enphase PV Envoy.
The Envoy provides a json output which give all the data that an emon would provide.
It needed a few tweaks but as I don’t have a OpenESEV yet its all hypotetical to see if I could get the required data.
Is there a document for all the MQTT topics that are required?
Are they just
temp1
pilot
state
amp
wh
freeram
just not sure about mode (divertmode, divertmode/set) etc
