Replies: 13 comments 1 reply
-
I have made my own V2L adaptor for my Ioniq5. An IC potentiometer could be used inside the plug, but there's no way to know what vehicle is connected so... |
Beta Was this translation helpful? Give feedback.
-
@fhteagle V2L cannot be used for V2H/V2G since V2L cannot sync with the grid, at the moment V2L can only be used in island mode. CCS V2X (ISO 15118-20) as far as I'm aware requires additional communication with the vehicle which currently the OpenEVSE is not capable of. @KipK that's cool, is this documented somewhere? It's surprising they all use different resistors?! This is going to cause a lot of confusion when people try and use a Kia adaptor on a Hyundai! |
Beta Was this translation helpful? Give feedback.
-
@glynhudson Kia works on Hyundai, but MG not. I used this scheme for mine : resistor between PE & PP is 62 ohm for Kia/Hiundai, and 70 ohm for MG I saw on ali express some V2L CCS plug with a switch for different brands There's a big thread about this there : https://www.ioniqforum.com/threads/v2l-inner-secrets-not-many.39857/ |
Beta Was this translation helpful? Give feedback.
-
@KipK - Very interesting about making your own custom V2L adaptor. Do you have it up and working already? Agreed that the state of standardization for vehicle power export leaves much to be desired. @glynhudson - Agreed that each user will need to possibly plan for additional equipment upstream of the OpenEVSE to fully support bidirectional charging, and those equipment requirements will likely vary by off-grid vs on-grid, differing jurisdictions, etc. There are hybrid smart inverters that are capable of utilizing multiple unsynchronized AC inputs. My personal target use case calls for the Sol-Ark 15k to accomplish the grid-interactive and auto-islanding functions. This equipment includes a GEN input that does not need to be grid synchronized. As to "additional communication with the vehicle which currently the OpenEVSE is not capable of.", the point of my opening this issue was to serve as a feasibility study for how much effort is going to be required to add this. Part of that process is getting a decent definition of scope of work. I think trying to support every individual manufacturer's quirks, communication add-ons, resistor values, etc that do not conform to any open standards should be out of scope. If the standards are not stabilized enough yet, then the answer of the feasibility study is "wait". I am perfectly fine with that answer, as long as the feasibility study at least identifies "wait until when". So, I vote that downstream equipment adapters, communication boxes, toggle switches, resistors for various OEMs, etc are out of scope for OpenEVSE project. Upstream hardware equipment above the OpenEVSE is likewise out of scope. The only considerations we should have for upstream and downstream hardware and communication are a well defined, open standards based method of changing from charging the EV to exporting power from the EV modes and back. Does this make sense? |
Beta Was this translation helpful? Give feedback.
-
@fhteagle yes for monthes, works as it should. The Ioniq 5 / EV6 can deliver 3.6kw from v2l. Not bad when you have a long grid failure to backup the fridge / Wifi / smart home server. |
Beta Was this translation helpful? Give feedback.
-
@KipK - Awesome. AFAIK, our US E-GMP cars are limited to 120V and a lower kW export. I have not researched if a US E-GMP platform car can be tricked into exporting 3.7kW at 220-240V range............. Also, my understanding of ISO 15118 is that it utilizes powerline communications on the J1772 / Type 2 pins. Yes, this is utilized for communication in the CCS (DC) based power export system (which I also think is out of scope for OpenEVSE for now... Until OpenCCS project is started someday anyway lol). But ISO 15118 communications protocol can also be utilized over AC-only connections as far as I know. I have not bought or read the spec document itself as of yet, but I may do so in the future. If anyone has it, or has read it and has better information than I do, I am all ears. Thanks |
Beta Was this translation helpful? Give feedback.
-
Other minor issue I thought of, is that if there is no source of AC power, the OpenEVSE boards will be likewise de-powered. De-powered OpenEVSE cannot speak ISO 15118 to the vehicle to start the export. If there is AC power already on the circuit, then the vehicle power export will need to sync to it, which as @glynhudson mentioned I do not think most cars can do. Possible solutions:
If anyone has any other brilliant ideas for powering the unit during the changeover, I would be glad to hear them. |
Beta Was this translation helpful? Give feedback.
-
Possibly relevant other issues: |
Beta Was this translation helpful? Give feedback.
-
This is an interesting discussion but not really relevant to this repo, I will close this issue. It would be best to discuss on a form e.g https://community.openenergymonitor.org/ |
Beta Was this translation helpful? Give feedback.
-
@glynhudson could you turn this into a discussion item now that discussions are on for this repo? Also, parallel work from EVerest project: Looks like more cars already will pass back AC or DC power through their charge ports than manufacturers have been loud and proud about yet. |
Beta Was this translation helpful? Give feedback.
-
Adding additional notes about this with new developments: SAE J3400 specifications for the "Tesla" aka "NACS" connector and communication supposedly done. Tesla Powershare is in real world testing at employee houses, customer houses soon. https://www.tesla.com/powershare . Supposedly, the Tesla 3V (not a typo, its 3V not v3?!?) gateway is alternately powered during a grid outage by a low voltage DC tap that goes vehicle -> EVSE -> gateway , not sure across which pins though . I assume this a proprietary / nonstandard implementation that is not actually written into J1772 / J3400? |
Beta Was this translation helpful? Give feedback.
-
SAE J3068/2 standard published for bidirectional AC signalling: https://cleantechnica.com/2024/02/22/sae-adopts-new-standards-for-vehicle-to-grid/ I don't have the actual standards docs to dig through, but if anyone does and could provide more specifics, that would be very helpful. |
Beta Was this translation helpful? Give feedback.
-
Tesla 3V gateway and bidirectional EVSE wiring diagram: |
Beta Was this translation helpful? Give feedback.
-
I am hearing of a few in production, announced, etc vehicles that will have the ability to output AC power via the J1772, J3400, or Mennekes/J3068 port. I am NOT referring to DC power export via CCS or J3400 in this feature request.
I would like to start collecting ideas, problems, showstoppers, standards, etc to plan for supporting bidirectional AC charging via OpenEVSE. I know there is a lot of other dev work that is being done and needs done with higher priority, but "planning out loud" on this will help a more informed go / wait / no go decision about this feature.
List of vehicles that have AC output via their AC charging port (work in progress):
80 amps bidirectional AC , https://www.lucidinsider.com/2022/07/12/lucid-motors-tech-talk-on-wunderbox-electric-vehicle-charging-system/
VW ID series(appears to be DC based according to: https://www.volkswagen-newsroom.com/en/press-releases/convenient-networked-and-sustainable-new-solutions-for-charging-electric-volkswagen-models-7695)Relevant standards and communication protocols (work in progress / research required):
DIN SPEC 70121 ?
ISO 15118-2 and -20:
-- https://www.iso.org/standard/77845.html
-- https://www.emobilitysimplified.com/2021/01/basics-of-iso-15118-usecases.html
SAE J1772
SAE J3068 (especially J3068/2)
SAE J3400
Other IEEE equivalent to the above?
Not vehicle communication, but home side / grid side communication for start/stop/throttle requests:
Possible Problems and Considerations (work in progress):
-- via HTTP API?
-- via "two wire start" concept (used for combustion generators)? Potential solution: raspberry pi to watch for this signal and spit out HTTP API command?
What have I missed on the above lists? Quick and dirty estimate of feasibility, difficulty to implement, etc?
Beta Was this translation helpful? Give feedback.
All reactions