I'm wondering if anyone has built or considered building an OpenEVSE with pluggable AC input cables. The main reason I'm thinking this is because at the three most likely places I might want to use my own EVSE, I have 3 different plugs. I have L6-30 receptacles on a 30A circuit in my garage. I have a 6-30 receptacle on a 30A circuit at the in-laws garage. At the cottage, we're upgrading the service so we'll be putting in a new circuit. I *could* put in a 30A circuit similar to one of the other two places, but since we have the cost of upgrading the service and the plug will be within a few feet of the main electrical panel, it seems to make more sense to put something like a 6-50 receptacle there rather than limit ourselves to only 30A.
I know that I can build or buy adapter cables for all of these scenarios, but doing so doesn't communicate anything about the capabilities of the supply circuit to the EVSE.
I know that I can change the maximum current via WiFi, but to my mind this seems like a tedious and error prone process. All it takes is to forget one time or make a mistake one day when tired, distracted, not thinking or whatever.
I realize that the worst case is that the breaker trips and my car doesn't charge, but if I don't notice that until the next morning when I'm planning to drive home, that's a bit of a hassle.
My thinking is that with some firmware modifications, I could use a four pin plug with a pulldown resistor built into the cable to indicate the current limitations of the supply to the EVSE. Something like a 50A RV connector seems like it could do the job, although it's probably too big for the existing OpenEVSE case, both outside and in. Some of the 50A non-NEMA locking plugs seem like they might also be options and might be able to be squeezed in - at least on the outside. I suspect space inside the case is likely still a problem.
In any case, if I can find a suitable plug with four pins that can deal with 250V and 50A, that seems possibly doable. I really only need two hots and a ground, so the neutral pin could instead be used for the pulldown resistor from the neutral to the ground pin and then we can use this as part of a voltage divider that gets fed in to an ADC to set the maximum output current. This seems more idiot proof to me and probably more convenient. I just plug in the cable that fits and it already has a pulldown resistor in it that tells the EVSE what charge current limit to communicate to the charger. It also seems that such a charger could then be used for both level 1 and 2 charging. Make a cable with a 5-15 or 5-20 plug on the other end and appropriate pulldown resistor and it would seem I have the one and only EVSE I'll ever need.
It seems simple enough, but what are the flaws in this plan?
To some extent, OpenEVSE already does some of what you want out of the box. That's probably not a bad place to start right off the bat. It stores two different current limits - one for level 1 (120V) charging and a separate one for level 2 (240V) charging. So, for example, you can set it to charge at 32A when connected to 240V and 12A when connected to 120V. It will automatically detect the input voltage and set the control pilot to indicate maximum charge current accordingly. This looks like it covers a couple of your use cases already.
NEMA 10 isn't grounded. EVSE generally require a good ground and either the EVSE or your car's onboard charger may refuse to work without a good ground. That said, the neutral should be grounded at the service panel so maybe you can fool it using the neutral pin as ground. Whether that will be good enough or not I don't know. It's not supposed to be used as a ground and I haven't tested my EVSE on ungrounded circuits. OpenEVSE does allow you to disable some of the safety checks such as GFI and ground monitoring if there is a problem. Whether that's a good idea is a different question. Your car's onboard charger may refuse to work if it thinks your ground isn't good even if you disable any issues within the EVSE. If you've already tested this using your existing EVSE then maybe you already have your answer. If possible, maybe changing this to a NEMA 14 or NEMA 6 receptacle would be prudent.
NEMA TT-30 is 120V/30A, so potentially about 3.6kW but J1772 doesn't specify level 1 charging above 16A. I believe the control pilot is the same regardless of input voltage, so you can theoretically indicate a charge current limit higher than 16A and I believe OpenEVSE will do so. You'd have to test whether your car's onboard charger will use the extra current at 120V or not. I've been meaning to rig up a test cable to test this with my Kona but haven't gotten around to it.
If the existing out of box functionality isn't enough, there may be a software only solution that might work for you. You could use some other property of each location to set charge current limits. This avoids the need for any hardware changes and may be a good option if you only need it to work in certain well-known locations. I'm thinking that WiFi SSIDs could be used to determine where you are. My thinking was to have it default to the standard limits but if it detected specific SSIDs, it could override the current limit with a different value associated with that SSID. I'm not sure how much persistent storage is left on the microcontroller, but I suspect there should be more than enough to store maybe 10 SSIDs each with their own L1 and L2 charge current limits. There is already an operation to request an WiFi scan by the WiFi module and get back a list of SSIDs. You'd do that during or shortly after startup. Maybe sort them by signal strength, then work down the list until you find a match. If you find a match, then use the associated current limits and stop checking any further SSIDs. If you don't find a match, then just use the regular current limits by default. These should probably be set to a sane limit for most locations - maybe 12A for level 1 and 24A for level 2. This assumes that you have a WiFi network to use as an indicator in each location where you want to charge at higher currents. It also means that if your WiFi dies or has reception issues in a given location, you may be stuck on the lower charge rate. A simple implementation could just hard-code these and compile them in but if you wanted to do it properly, you also need to build a UI to display these values and allow yourself to update them.
If you want to go the hardware route, this has fewer operational caveats, but there are some challenges. Note that you only need 4 pins, not 5. You need two power pins, 1 ground pin and a sense pin. The way I figured it, you'd connect the sense pin to ground via a sense resistor built into the cable assembly. Inside the OpenEVSE, you'd connect the sense pin to Vdd via a known pullup resistance. You then have a voltage divider and can read off the voltage of the sense pin via an analog input. I'm not sure off-hand if there is a readily accessible analog input on the microcontroller. You'd need to figure that out yourself. I think the sane approach is to use smaller sense resistors to indicate higher charge current capability. There's also the question of what to do with a short or open circuit between sense and ground. One option is to treat these condition as a fault, but whether that makes sense depends on the connector option you choose. Speaking of connectors, using off-the-shelf parts, aviation connectors seem like a good option. You can find them on AliExpress for reasonable prices. They're designed to be watertight. They appear to be keyed to avoid improper insertion orientation. There are versions that handle 50A and 500V with 4 pins and they're relatively compact. The best way would be to have a male socket in the bottom of the OpenEVSE. This is less dependant on the seal for water resistance since gravity should keep water reasonably well away. It also would look better externally. The downside is that there's limited space inside the OpenEVSE case and you need most of that to work reasonably with the heavy, high-current conductors. You might be able to make it work, but you might need a larger or differently shaped case. Alternatively, you could stick with cables coming out of the unit and use inline aviation connectors instead. They're still supposed to be watertight, but you may be more reliant on the seal in those plugs now and this seems a little less clean looking to me but still functional. You want the female connection on your plug to keep any potentially live pins hidden away inside. Some examples of these connectors on AliExpress are:
Another option for the connector could be to just use NEMA 14-50. I did allude to that in an earlier post. You could maybe use the neutral pin as your sense pin since the EVSE doesn't need it, however I'm not sure off-hand whether this could create transient problems that might damage your microcontroller or other issues like violating electrical codes and the like.
Oh yes - with regard to the PP analog pin that OpenEVSE Support referred to above, I don't think that's a solution for what you're looking for. I believe they're referring to the Proximity Pilot (or Plug Present) pin specified in the J1772 standard. This is on the wrong side of the EV. It's designed to indicate the current handling capability of the J1772 plug/cable assembly to the EVSE via a sense resistor connecting that pin to ground. Using a J1772 connector for the connection to the power supply doesn't make much sense. J1772 connectors are expensive. They're bulky. They may also lead to confusion since it's the same connector that plugs into your car.
I’ve had an EV for a couple of years now. Chevy Bolt. Technically it’s my wife’s, which is part of the reason for this inquiry. She’s not interested in fiddly things, so I need something that just mindlessly works. Pushing buttons, using apps, or web sites (or shaking or tapping a card) to change the charge current on an EVSE are simply not tolerable use cases, not to mention having to be cognizant of what charge current to select based on a specific plug configuration.
Currently we’re still using the factory EVSE, but I made a 14-50 to 5-15 dongle to allow us to charge using 240v, so it’s provided an acceptable charge rate for our usage of that vehicle up until now. Recently our situation has changed so that she needs to drive longer distances with little layover time at different locations, so a faster charge is required. Eventually, I will also be getting an electric pickup which I will be driving cross country regularly, and want to charge at the campgrounds we stay at when possible. So I’m looking for a convenient travel charger.
As for what dongles I envision needing, I have NEMA 14-50s at home. Remote locations that we need access to have NEMA 10-30 available. A 5-15 just in case, and assuming my future truck can charge at 120V@24A, I’d want a TT-30 for campgrounds that have that, but not the 14-50, even though I know I wouldn’t get a lot out of it.
I’d actually love to assemble my own OpenEVSE. I’ve taken apart and modified more than a couple home electronics devices. My background is in software, developing complex, high performance embedded systems, so I’m not afraid of writing/modifying some code for a simple microcontroller. Not really what I want to do, but since the market isn’t willing to provide a solution, I’m willing to roll my own.
Hopefully that clarifies my use cases.
Back when I started this thread, I did do some thinking about this and searched for suitable parts, so I can probably share some of my thoughts from back then. Having said that, back then I was a shiny new EV owner with no real experience living with an EV and looking for an electronics project. 9 months later, I no longer think this is a project worth doing because it just wouldn't have provided sufficient value to warrant the time/effort and additional complexity/risk.
Before I share much more, a few questions/assumptions to help guide the discussion...
Ok, Glad I stumbled across this thread finally. I've been debating on getting an OpenEVSE for quite a while now and the lack of this feature/option was the one thing preventing me. IMO the Mustart Travelmaster and the Tesla UMC are the only sane/safe EVSE on the market. Setting the current based on the supply plug should be mandatory for all EVSE. Unfortunately, I don't trust the Mustart, and the Tesla UMC is limited to Tesla only without the addition of a bulky/cumbersome adapter, and also largely unobtainable.
So, now that my rant about the lack of availability of any good EVSE is done, I need to resume my search for a suitable connector. For this to work requires a 5 pin connector. 3 - 50A pins and 2 - "data" pins. So far I've found nothing suitable that is remotely affordable. Any suggestions would be appreciated! It may be easier, if less clean to go with two connections, one for power and a small dongle for the configuration sense and find some way to securely attach to dongle so it doesn't get separated from the supply cable.
As to the PP analog port, is the code for that already active in the North America product? Is there something that needs to be done to activate it? The values listed are obviously not idea for the North America electric system where we'd want 12A, 16A, 24A, 32A, and 40A as the options. Any advice or suggestions on how to take advantage of this feature would be greatly appreciated!
That Mustart Solutions EVSE is one I'd seen prior to buying OpenEVSE and what gave me the thought of having pluggable power cables with some kind of resistor to indicate maximum charge current, but there were a couple of reasons that I decided against it, including the fact that I just like the idea of an open design that I could potentially tinker with one day if I ever get suitably motivated.
As far as the idea of pluggable cables with a resistor in them to indicate appropriate loads for the supply circuit, so far it's turned out to be a non-issue. If you were to implement something, I'd suggest still using the NEMA 14-50 plug or similar on the EVSE and build the resistors into adapter cables instead. Finding some other readily available connector that can carry the heavy current at a reasonable price is tricky. Something like an M28 connector might work. However, with about 6 months of using the car and the OpenEVSE, I think that a better goal is to minimize the amount of crap you need to carry around and mess with to charge your car. If you can afford an EV, you can probably afford the cost of installing a 14-50 receptacle or whatever the equivalent is for your locale. That seems a better solution rather than shoe-horning a charging solution on top of whatever receptacles you already have available. Charging an EV is a heavy, persistent load. Having a separate circuit specifically for that is probably not such a bad idea, anyway.
i thought i recalled reading that somewhere.
OpenEVSE already supports this in Europe on the PP analog port, it detects a resistor from the Type 2 PP pin to ground and sets the current based on the resistance.
13 A 1.5 kΩ
20 A 680 Ω
32 A 220 Ω
There is no reason the port can not be used for the same purpose with the same or additional values with modified firmware.
I love openEVSE so im not trying to take business away... But check out the link below, it would be neat if openEVSE had some kind of analog input so we could use resisters to tell the board what to set the output to without having to go in the web interface or menu to set it.. So you plug in a special plug that has a sense wire, and you have a resister from ground to the sense wire, the openevse board detects say 30 ohms and it knows to set it's output power to 15A? Or just buy one of these travel chargers below, that's how they are doing it lol...
So after all my ruminations, I finally realized what the NEMA 14-X plug means. Now that I realize that the plug that comes with the OpenEVSE will plug into both NEMA 14-30 and 14-50 receptacles, that changes things a bit. I clearly don't need any adapter at two out of my three most likely charging locations, so now it's just a matter of what I do at home. Do I install a NEMA 14 recptacle in my garage at home, or do I build an adapter cable? Either way, the solution then just boils down to me not being an idiot and setting the maximum charge current too high.
One thought was that an improperly wired receptacle or cable could potentially put 240VAC on that neutral pin, which could potentially damage your ADC and maybe the controller board itself. Some kind of protection circuit might be in order. I'm thinking something like a zener clamp and fuse might be enough?
For that matter, an incorrectly wired receptacle or cable would potentially put 120VAC or more across the pulldown resistor, which could get hot. Ensuring high enough resistor values might mitigate this somewhat. I think it's unlikely that such a cable would be left plugged in without the charger, and I'd probably plug the charger into the cable before plugging the cable into the wall, so maybe the detection sequence could be used to further mitigate this. If we use a relay to pull the pin low for maybe a second or so during startup, that should be enough to trip a breaker and de-energize the whole thing. It would also give us a way to verify if the fuse mentioned above has been blown.
Just thinking some more about this...
If the EVSE simply has a NEMA 14-50P plug attached to it, that could probably fulfill this desire. The neutral and ground are shorted together at the service panel, so if the firmware interpreted a 0 ohm pulldown as indicating 40 amp maximum output, then it should work fine for the 50A circuit with a 14-50R receptacle. Then I can build L6-30 and 6-30 adapter cables, but on the 14-50R end of it, put an appropriate pulldown resistor that indicates only 24A maximum output current to the firmware. It just needs to be fed into an ADC and read off. Using some kind of I2C ADC chip should be pretty simple. The one downside of this I see is that in the case plugging into a normal NEMA 14-50R receptacle, you would probably be injecting a few milliamps of DC current into the neutral and back up the ground wire, since I assume that the chassis ground is connected to the controller negative/ground rail. That said, this probably only needs to be done for a few milliseconds during startup, so maybe that's not such a big deal.