Dev: OpenEVSE Type-2 (non-tethered) enclosure (EmonEVSE)

glyn.hudson · 2018-03-18T20:50:36.699Z

We’re getting very close to launching OpenEnergyMonitor OpenEVSE with type-2 (non-tethered) socket. Please help us prioritise manufacture by completing the following poll. Feel free to select as many options as required. Thanks for your support and patience.

I’m interested in a non-tethered OpenEVSE with the following options:

Single-phase
Three-phase
Fully Assembled
Kit Form
I want the unit ASAP
I want to wait for OLEV approval

0 voters

IMG_20171124_1444461092×1456 179 KB

IMG_20180124_120132835-COLLAGE1941×1456 352 KB

IMG_20180211_1452481941×1456 456 KB

4fed7a6ba561c85a20a9440ac2ecdb93de28da55__77784.1510682190.1280.1280.jpg1008×696 124 KB

eiriksuperseig · 2018-03-18T23:05:33.976Z

Will it be possible to load balance between several units? In my case “just” between two units? The source is max. 32A single-phase and need to be shared by two chargers. There must also be a function to limit the max. available load/current for the load balancing to play with. For examples, in the afternoon just home from work the source could be limited to 16A due other stuff going on in the household and the overall intake limit. The during the night the source could be increased to 32A again. Ideally this could maybe all be done automatically by monitoring the intake and adjust available current to chargers on the fly. Maybe it’s already available in the firmware/software?

Thanks
Eirik

molnar · 2018-03-19T07:36:10.064Z

Great news, thanks!
I made my vote.: 3 phase, KIT, ASAP.

Thank you very much in advance.

glyn.hudson · 2018-03-19T12:55:26.425Z

eiriksuperseig:

Will it be possible to load balance between several units? In my case “just” between two units? The source is max. 32A single-phase and need to be shared by two chargers. There must also be a function to limit the max. available load/current for the load balancing to play with. For examples, in the afternoon just home from work the source could be limited to 16A due other stuff going on in the household and the overall intake limit. The during the night the source could be increased to 32A again. Ideally this could maybe all be done automatically by monitoring the intake and adjust available current to chargers on the fly. Maybe it’s already available in the firmware/software?

This is not yet possible, it will not be too difficult to implement it using a similar algorithm to the solar PV diversion. There is an open issue on the WiFi-gateway firmware github page:

github.com/OpenEVSE/ESP8266_WiFi_v2.x

Max Utility Power Shedding Mode

opened 08:44AM - 11 Jan 18 UTC

glynhudson

enhancement

Add feature to adjust charge rate to supply maximum power up to a maximum grid i…mport threshold. I.e reverse of solar PV divert. Enter total grid import MQTT feed (including EVSE power) and maximum utility supply threshold. Useful for users with a limited gird supply who want to charge their EV at maximum rate, charge rate will be automatically reduced to keep grid import below max utility supply threshold e.g. if another appliance is switched on charge rate will be reduced. If possible this feature should be independent to solar PV divert since it could be possible for a user to want to use solar PV divert e.g. "Eco Mode" and "Max Utility Power Mode". However given the memory constraints of the ESP it may be easier to implement max power mode using the same solar PV divert functions. It would not be too bad trade off to make the user choose between Eco Mode or Max Power mode e.g not both at the same time. *Note: recomend setting max utility grid import threshold below actual threshold to give some headroom to avoid overloading supply.*

It you want more control it would be possible to control the charger using your own NodeRED flow for example to issue RAPI commands over MQTT / HTTP to set the charging rate.

eiriksuperseig · 2018-03-19T22:24:07.823Z

Thanks for your reply. Will have to read up on this.

When do you expect to have these new units in stock as full assembled unit? Will they have the same certification, for instance like CE, also as a kit or will that just follow the full assembled version?

glyn.hudson · 2018-03-20T10:27:36.848Z

eiriksuperseig:

When do you expect to have these new units in stock as full assembled unit?

In the next few weeks

eiriksuperseig:

Will they have the same certification, for instance like CE, also as a kit or will that just follow the full assembled version?

The fully assembled Type-2 EmonEVSE will be fully CE certified.

We are still trying to decide if there would be demand also for the unit in kit form, please indicate your preference on the poll above. The kit version would be non CE certified, since obviously we can’t test the complete unit or ensure quality. However all components will be fully tested.

mgent · 2018-03-21T15:23:12.342Z

Is the second gland to allow for use of a teathered connector? If so would the unit be able switch between teathered and socket mode?

glyn.hudson · 2018-03-22T00:36:18.829Z

mgent:

Is the second gland to allow for use of a teathered connector? If so would the unit be able switch between teathered and socket mode?

It is possible for a tethered cable toe be connected to the 2nd gland. Although we won’t be able to ship unit in this configuration (or recomend it) since this would not be allowed under the EV charging standards e.g. the tethered cable would be ‘live’ when an EV is charging using the T2 socket. Also there is a danger of two EV’s being connected at once which could cause damage.

Giddy · 2018-03-26T14:31:47.051Z

Hi, have you implemented changing of current on EVSE side sensing the resistor between PP and PE in OpenEVSE firmware? If the OpenEVSE is set for 30A and you plug in Type2 cable rated for 16A, EVSE should reduce the current to that is rated for plugged cable.

glyn.hudson · 2018-03-28T17:02:59.649Z

Yes certainly, see:

github.com

openenergymonitor/open_evse/blob/master/firmware/open_evse/AutoCurrentCapacityController.cpp#L20

    
      
          // GNU General Public License for more details.
          //
          // See LICENSE for a copy of the GNU General Public License or see
          // it online at <http://www.gnu.org/licenses/>.
          
          
#include "open_evse.h"
          
          
#ifdef PP_AUTO_AMPACITY
          
          
static PP_AMPS s_ppAmps[] = {
            {0,0},
            {93,63},  // 100 = 93
            {185,32}, // 220 = 185
            {415,20}, // 680 = 415
            {615,13}, // 1.5K = 615
            {1023,0}
          };
          
          
AutoCurrentCapacityController::AutoCurrentCapacityController() :
            adcPP(PP_PIN)
          {

For reference taking from BS EN 61851:1:2001:

Selection_227

molnar · 2018-03-28T19:41:30.871Z

“of course” it does

By the way, an other question, inspired by this:
During the charge, is the actual charging current compared to the PP_Amps value?
(Is there an “overcurrent error” state, if the EVSE is set to 32A, and the Type2 cable is 16A rated, and somehow the car starts pulling 20-30A?)

I’ve checked the OpenEVSE flowchart, but I’ve only seen the temperature monitoring function, and the “overtemp” state.

glyn.hudson · 2018-03-28T23:28:07.880Z

molnar:

By the way, an other question, inspired by this:

During the charge, is the actual charging current compared to the PP_Amps value?

(Is there an “overcurrent error” state, if the EVSE is set to 32A, and the Type2 cable is 16A rated, and somehow the car starts pulling 20-30A?)

The max charge current is limited to PP_Amps e.g. if no PP>GND resistor is present the EVSE ~~defaults to the lowest possible charge rate (6A). The EVSE will not allow the charging current to be increased higher than the PP_Amps limit.~~ will not start a charge.

If the resistor is present (as in the case of all compliment non-tethered cables) the EVSE will not allow the pilot signal to be increased to a charging current higher then PP_Amps e.g. 13A cable with 1.5k ohm resistor, EVSE will not allow pilot max amps to increase beyond 16A.

The charging limit is determined by the lowest denominator (weakest link) out of these three factors:

EVSE capability (max current setting in OpenEVSE config)
Maximum rating of the EV charging cable (set by PP > GND resistor in EVSE end T2 connector)
EV on-board charger capability

molnar · 2018-03-29T07:08:50.052Z

That’s clear.
I’m talking about a failure event.
The EVSE is only “commanding” the EV, how much Amps it should consume maximum.
But the actual Amps is determined by the EV itself.
There is a risk, that if the EV is malfunctioning (for example it doesn’t care the CP signal), then it can take more Amps, than the cable can handle.

For example:
my Leaf has a 6,6kW onboard charger (it can consume 32Amps), and the EVSE is set to 32 Amps, BUT the cable is only 16Amps rated, then the EVSE commands the Leaf, that is should not take more than 16Amps.
But if something goes wrong in the onboard charger of my Leaf, then it’s physically possible, that it will take 32Amps.
When the cable will melt.

The OpenEVSE is continously monitoring the inner temperature, during the charge session, and if it raises, then it reacts, at last by ending the charge session (overtemp).

I think, it would be a great safety function, if the actual charging current would be monitored also continously, and if it would be greater than the max Amps (calculated as you have described above) for a certain time period, then the charge should be also terminated and show “Overcurrent Error”.

glyn.hudson · 2018-03-29T12:16:41.866Z

molnar:

The EVSE is only “commanding” the EV, how much Amps it should consume maximum.

But the actual Amps is determined by the EV itself.

Correct

molnar:

There is a risk, that if the EV is malfunctioning (for example it doesn’t care the CP signal), then it can take more Amps, than the cable can handle.

The EVSE that generates the pilot square wave and sets the duty cycle. You are correct that if the EV chooses to ignore the pilot signal then it could draw more current, however there are many protection mechanisms in place to stop this happening since almost all other EVSE’s don’t have any way to measure the actual current being drawn. This would be particularity bad if the EV malfunctioned and tried to draw 32A from a granny cable! In practice I don’t think it could ever happen. But yes, I agree since we have the ability to monitor the current it would be good to check the current is withing limits. I’m pretty sure the openevse controller already does this. I will double check and do some testing.

molnar · 2018-03-29T12:50:27.939Z

great, thanks!

glyn.hudson · 2018-04-17T00:42:43.598Z

Hi guys,

I’m pleased to announce that the EmonEVSE is now available to purchase from the OpenEnergyMonitor store!

Shop | OpenEnergyMonitor

EmonEVSE WiFi Connected EV Charging Station (Type-2)

Open-source hardware tools for energy monitoring and visualisation

Price: GBP 560.54

Datasheet download: http://files.openenergymonitor.org/datasheet/emonevse-datasheet.pdf

Thanks a lot for all your help, feedback and support during the development. I’m sorry it’s taken longer than planning to get to this stage. As a thank you I would like to offer you 15% discount on the new unit, just use code F0ZS87E76197 at checkout. Valid until 31st May 2018

Here is a video demonstrating the solar PV divert feature in action:

Here is a copy of my slides from a presentation I gave on the EmonEVSE last week, there is lots of background info on the development, background CE testing and future development of the unit.

Please let me know if you have any questions feedback.

glyn.hudson · 2018-04-17T01:25:41.700Z

We made the first customer installation of the EmonEVSE (outside of our development team) last week, it went well. The solar PV divert and web interface control have been working well

twitter.com

OpenEnergyMonitor

@Openenergymon

First ever customer installation of our #emonEVSE #opensource WiFi connected #EV charging station in partnership with @OpenEVSE #Emoncms and #solarPV divert integration using #emonPi #MQTT #ESP8266 https://t.co/vvqZ67dVOb

5:11 PM - 13 Apr 2018 19 14

twitter.com

Dominic Zapaman

@Zapaman

Timer control of EV charging worked great #emonEVSE and electricity consumption monitoring is so useful @Openenergymon @glynhudson @beaylott @TrystanLea @CarbonCoop https://t.co/JSsp3bpEbA

4:58 AM - 14 Apr 2018 3 1

twitter.com

Dominic Zapaman

@Zapaman

Now trying solar diver “eco” function on #emonEVSE @Openenergymon https://t.co/x3BW9CBysx

12:11 PM - 14 Apr 2018 2 2

twitter.com

Dominic Zapaman

@Zapaman

We’ve had a few things running simultaneously (EV charging, washer, kettle and microwave) but #emonEVSE is doing a great job of tracking PV export! @glynhudson @Openenergymon @beaylott @EcoHome_Lab @lowwintersun @CarbonCoop https://t.co/8PeGzicWn9

1:03 PM - 14 Apr 2018 4 2

twitter.com

Dominic Zapaman

@Zapaman

Nice simple display on #emonEVSE @CarbonCoop @Openenergymon https://t.co/GMDg5Ng6cV

6:35 PM - 16 Apr 2018 5 2

janh · 2018-04-29T17:11:28.563Z

Sorry for my late reply. Somehow I don’t get notifications and I only checked back in now.
Nice to see you are shipping the EmonEVSE. Thank you for making it a reality.

I ordered one today.
I still need to choose a place to install the unit (and the car only comes in September). When I have it installed, I’ll post a picture.

glyn.hudson · 2018-04-30T12:44:45.121Z

janh:

Sorry for my late reply. Somehow I don’t get notifications and I only checked back in now.

Nice to see you are shipping the EmonEVSE. Thank you for making it a reality.

I ordered one today.

I still need to choose a place to install the unit (and the car only comes in September). When I have it installed, I’ll post a picture.

Fantastic, thanks a lot for your order. It will be shipped this week

glyn.hudson · 2018-05-18T12:38:42.687Z

2 posts were split to a new topic: OpenEVSE DEV: Detecting three-phase using single CT sensor