V2H Transfer Unit: Interlocks and Anti-Islanding Control
← Back to: High-Voltage Energy & Safety
When I plan a V2H transfer unit, I treat it as the dedicated safety and control bridge between the grid, my EV and my house, with the right interlocks, anti-islanding, metering, isolation and communications so energy can flow safely in either direction. This page is my checklist for how to architect that bridge, which IC building blocks it needs and which BOM fields I should pin down before I talk to suppliers.
What is a V2H Transfer Unit?
When I talk about a V2H transfer unit, I mean the hardware that decides whether my house is fed from the utility grid or from the EV – and makes sure neither source ever feeds power into the wrong place. It sits between the car, the bidirectional charger and the home panel, and it is the layer that turns “EV as a battery” into a safe, controllable power source for the whole house.
Compared with a simple ATS or generator transfer switch, a V2H transfer unit has to think about more than just “grid present or not”. It has to understand when the car is ready to invert power, keep the grid and the EV electrically separated, and maintain a clean metering and control story so energy flows can be billed and limited correctly instead of behaving like an anonymous backup outlet.
- Interlocks: prevent back-feeding the utility and avoid any unsafe make-before-break path between the grid, the EV and home loads.
- Anti-islanding: coordinate with the inverter so the house disconnects cleanly from the grid when the utility drops, and only the home-side microgrid stays alive.
- Bi-directional metering & comms: measure energy from car-to-home and home-to-grid separately and expose it to tariffs, control logic and safety limits.
System Architectures for V2H Transfer
Before I pick ICs or relay drivers, I first lock down which V2H architecture I am actually building. Different layouts put the transfer unit at different points between the utility, the main panel, the EV charger and any PV or home storage, and that changes where I measure power, where I place isolation and which blocks are allowed to talk to the grid.
In the most common AC-side V2H setup, the bidirectional inverter lives in the EV or the wall charger and exports AC into the home. The V2H transfer unit then sits next to the main panel: it sees the utility feed, it sees the house load group, it sees the V2H source, and it decides how to connect or separate them. CTs and voltage taps inside the unit feed the metering and protection, while an MCU and isolated comms links coordinate with the charger and the home energy management system.
In a DC-coupled or hybrid layout, PV, stationary storage and the EV may sit on a shared DC bus and only one central inverter exports AC towards the house and the grid. In that case, the V2H transfer unit often looks more like an AC interface with focused duties: cleanly disconnecting the house from the utility, applying residual-current and overcurrent limits and placing metering at the right point in the power path. The detailed DC-bus metering and control rules live with the PV and storage controller; here I focus on how the transfer unit has to plug into that bigger system.
Interlocks and Transfer Topologies
When I design a V2H transfer unit, the interlocks around the grid and V2H contactors are the first thing I try to get right. If I mis-manage the sequencing, I either back-feed the utility or briefly tie the grid, the EV source and the house bus together. A proper topology forces break-before-make at the hardware level and leaves the software to orchestrate safe transitions instead of fighting wiring mistakes.
The usual pattern is a pair of interlocked contactors or a dedicated transfer switch: one element connects the house bus to the utility, the other connects it to the V2H source. A mechanical interlock stops both paths from being closed at the same time, and an electrical interlock in the V2H controller enforces clear operating states. On top of that, I still need a clean way to bypass or take the unit out of service without ever losing the fail-safe behaviour.
- Grid mode: grid contactor closed, V2H contactor open, house bus fed from the utility only.
- V2H mode: grid contactor open, V2H contactor closed, house bus fed from the EV or hybrid microgrid only.
- Fail-safe / all open: both paths open on fault or uncertainty so nothing can back-feed the utility and the house goes dark instead of unsafe.
On the IC side I still need solid contactor or relay drivers with coil current control and undervoltage handling, plus clear position feedback from auxiliary contacts or opto-isolated inputs. The detailed weld detection comparators and current signatures live in my contactor safety pages; here the goal is to make sure the V2H topology itself supports safe states and simple, verifiable logic.
Anti-Islanding Detection and Standards Mapping
Any time I let a car power a house, I have to assume that linemen and utility crews may be working on a line they believe is de-energised. Anti-islanding is the part of the design that keeps my V2H system from quietly feeding a dead grid. If the utility goes away, the inverter has to notice quickly, and the V2H transfer unit has to break the hard connection before anyone outside my property can touch a live conductor.
In most architectures the inverter or bidirectional charger carries the heavy algorithm work: it senses grid voltage, frequency and current, injects small perturbations and looks for the loss of a strong utility reference. When that controller decides the grid is gone or out of tolerance, it asserts a trip signal. The V2H transfer unit is then responsible for turning that trip into a physical open gap to the utility, and later for deciding when it is safe to reclose based on restored grid measurements and the local interconnection rules.
The signal chain is straightforward on paper: grid voltage and current feed an AFE with dividers, CTs or Rogowski coils, then an isolated ADC or ΣΔ modulator reports into the inverter controller or DSP. That controller runs the anti-islanding logic and exposes a clean digital trip and status interface to the V2H controller. On the V2H side I still need a small MCU or logic device, digital isolation where required and a contactor driver sized for the available fault current at the service point.
Grid codes and local interconnection standards define how quickly I must detect the loss of utility, how fast and how far I must disconnect, and under what conditions I am allowed to reconnect. The deeper topics such as frequency support, reactive power control or aggregated V2G services live in my V2G interface discussions; for V2H I focus on making sure islanding is detected promptly and that the transfer unit always enforces a clear, auditable open point to the grid.
Bi-Directional Metering and Protection
When I plan the V2H transfer unit, I treat metering and protection as the same problem: I am not just counting kilowatt-hours for curiosity, I am deciding how much power can flow between the grid, the EV and the house without overloading cables or tripping the wrong breaker. The same voltage and current information that feeds billing and graphs is what I rely on to spot overloads, imbalance and leakage before they become safety issues.
At a minimum I want to see both sides of the power story. On the grid side I need to know how much energy is moving between the utility and the house, and in some projects that means a revenue-grade metering path that can reconcile with the utility meter. On the V2H side I want a clear view of how much energy flows between the EV and the house so I can enforce daily discharge limits, avoid draining the pack too far and give the homeowner a believable picture of what the car is doing for their bills.
That normally leads me to a mix of devices: a revenue-grade metering IC or module on the grid–house path, and a system-grade measurement path on the V2H branch that is accurate enough for control but not tied to a tariff. I also have to decide whether I measure a single combined channel or break things out: full L and N measurement for better accuracy and imbalance detection, or even multiple channels if I want separate visibility for the V2H outlet and selected house circuits. The detailed choice between shunts, CTs or Rogowski sensors lives in my dedicated metering pages; here I focus on what the V2H unit has to see.
On top of that, I want the metering to support my protection strategy. Overcurrent and long thermal overloads can be detected electronically so the V2H controller can limit power or open its contactors before a mechanical breaker has to trip. Residual-current and leakage detection are handled by their own AFEs, but the transfer unit still has to provide a clean way to feed those signals into the protection logic. In the end I want the fuses and breakers to be the last line of defence, not the only thing standing between a fault and an unsafe installation.
Isolated Communications and Control Integration
Once the power paths are under control, I still need the V2H transfer unit to behave like a good citizen in the wider energy system. It has to talk to the EVSE or bidirectional charger, to the home energy management system, and sometimes to a smart meter, utility or aggregator. At the same time it must present a simple, trustworthy view to the homeowner through a local HMI or gateway. The controller inside the V2H unit ends up being a small hub that keeps all of these parties in sync.
On the vehicle side I usually have a link to the EVSE or charger that reports whether the car is connected, ready to discharge and what power limits apply. On the building side I want at least one path into the home EMS or gateway so higher-level logic can decide when V2H should be enabled or capped based on tariffs, PV output and storage state. In some installations the V2H unit also needs a way to observe data from a smart meter or utility interface, especially if interconnection rules or demand-response programmes apply.
Physically this tends to boil down to a handful of familiar interfaces: CAN or RS-485 toward the EVSE or charger, PLC or RS-485 toward a meter or utility-side modem, and Ethernet or Wi-Fi via a gateway for home and cloud integration. I do not need to lock down every cloud protocol in the V2H design document, but I do want to define which buses the controller must support and how much isolation and surge tolerance each link requires.
Underneath all of this I split the design into a low-voltage control and communications domain and a high-voltage measurement and actuation domain. The V2H MCU and its CAN, RS-485 or Ethernet PHYs sit on the low-voltage side; the grid metering AFEs, isolated ADCs and contactor drivers sit on the high-voltage side. Digital isolators and isolated transceivers carry just enough information across that boundary to keep the two domains coordinated without letting high dv/dt noise or fault energy leak back into the logic and user interfaces.
IC-Level Signal Chain Mapping
Once I am comfortable with the system-level architecture of the V2H transfer unit, I break it down into IC-level signal chains. The goal is not to lock in exact part numbers, but to make sure every function in the topology is backed by a realistic combination of IC families. If I can map those functions to the major vendors up front, it is much easier to build a short list later without missing a critical block.
For a V2H transfer unit the core signal chains fall into a few clear categories: grid sensing and anti-islanding AFEs or metering SoCs, a control MCU or MPU with security features, isolated communications and digital isolators, contactor and relay drivers, and the aux power stages that feed everything else. The detailed AC metering architectures, ΔΣ front-ends and weld-detection comparators live on dedicated pages; here I am only checking that each signal chain has a home in the overall IC mix.
At a high level I treat the V2H transfer unit as a combination of the following IC-level signal chains:
- Grid sensing & anti-islanding AFE / metering SoC: voltage and current AFEs, isolated ADCs or metering SoCs that feed grid measurements into the inverter controller and V2H logic.
- MCU / MPU & security: the main V2H controller that runs transfer logic, talks to the EVSE, EMS and HMI and, where required, anchors secure boot and cryptographic functions.
- Isolated comms & transceivers: CAN, RS-485, PLC and Ethernet PHYs, often with integrated or companion isolation, that link the V2H controller to the charger, smart meter and home gateway.
- Digital isolators: coreless-transformer or capacitive isolators that carry status, trip and measurement data between the low-voltage controller domain and the high-voltage metering and driver domain.
- Contactor / relay drivers: automotive-grade drivers sized for the contactor coil current and fault energy at the service point, with diagnostics routed back into the controller.
- Aux power rails: AC/DC front ends and DC/DC converters that generate the isolated bias rails needed for AFEs, metering ICs, isolators, drivers and the main MCU.
Across the major automotive and industrial suppliers, I can usually find representative families for each of these chains:
- TI / ST / NXP / Renesas: grid metering AFEs and SoCs, Cortex-M and Cortex-A MCUs with security options, automotive CAN and Ethernet PHYs, digital isolators and high-side or smart-FET contactor drivers.
- onsemi / Microchip: AC/DC controllers, DC/DC converters, isolation-ready gate and relay drivers, discrete current-sense front-ends and robust CAN / LIN / RS-485 transceivers.
- ADI and similar signal-chain specialists: high-accuracy ΣΔ converters, precision AFEs, isolation products and metering-focused reference designs that can anchor the sensing side of the V2H design.
The exact part numbers and deep trade-offs between shunt, CT and Rogowski sensing or between reference metering SoCs and custom ΣΔ chains are handled in my AC metering and contactor driver pages. For this V2H transfer view I am mainly confirming that the system can be built from standard IC classes that exist in all seven major vendor ecosystems.
BOM & Procurement Checklist for V2H Transfer Unit
When I prepare a request for quote or a sourcing package for a V2H transfer unit, I compress the technical requirements into a small set of BOM fields. These fields tell suppliers which grid standards, power levels, operating modes and safety constraints they have to design to, and they make it much easier for a project owner or buyer to compare different module offers. The table below is the checklist I use as a starting point.
| Field | Description / options |
|---|---|
| Target market / region | NA / EU / CN / other; indicates which grid codes, voltage systems and certification routes apply. |
| Interconnection standards | List the main interconnection / anti-islanding standards that the V2H transfer unit must comply with (names only, no clause details). |
| Nominal voltage & phases | Single-phase / split-phase / three-phase; nominal line-to-line and line-to-neutral voltages at the point of connection. |
| Power rating | Continuous and short-term V2H power in kW, plus any overload capability requirements. |
| Transfer interruption time | Allowed outage duration during transfer in milliseconds; defines how fast the unit must change between grid and V2H modes. |
| Operating modes | Backup-only / self-consumption and peak shaving / full V2G-ready. Indicates whether the unit only powers the house in outages or also supports export and grid services. |
| Contactor / switch poles | Number of poles and required switching configuration for grid and V2H paths. |
| Rated & short-circuit current | Nominal current rating and required short-circuit withstand for contactors and switches at the installation point. |
| Mechanical interlock required | Yes / no; defines whether a hardware interlock is mandatory between grid and V2H contactors in addition to logic interlocks. |
| Metering accuracy class | Revenue-grade (e.g. 0.5S or better) or system-grade; used for selecting metering ICs and AFEs. |
| Measurement channels | Number of voltage and current channels to be measured (L/N, per phase, dedicated V2H branch, etc.). |
| Residual / leakage detection | Whether residual-current and leakage detection is required, and if so, what sensitivity and response requirements apply (detailed design handled in residual detection pages). |
| Required communication interfaces | List of mandatory physical interfaces: CAN, RS-485, PLC, Ethernet, Wi-Fi, or others needed for EVSE, EMS, utility and HMI integration. |
| Security elements | Requirement for secure elements, hardware crypto or secure boot to support V2G, billing or utility authentication schemes. |
| Safety & certification targets | Target UL / IEC categories for the transfer unit, insulation class, pollution degree, creepage and clearance requirements (values to be defined with local codes). |
| V2G / grid-service readiness | Whether the design must be prepared for future V2G, frequency support or grid-service features, influencing choices for metering, security and communications. |
Request a Quote
FAQs: V2H Transfer Unit Planning & Selection
These twelve questions are the way I sanity-check my own V2H transfer unit plans. When I can answer them clearly, I know I have covered topology, protection, metering, isolation, communications and sourcing well enough to move forward. I also reuse the answers as short notes in design reviews, supplier conversations and customer-facing documentation.
When does it make sense to add a dedicated V2H transfer unit instead of relying on the EV charger’s built-in relay?
When I already have a bidirectional charger with a basic relay, I add a dedicated V2H transfer unit when I need more than a simple on/off contact. As soon as I need proper interlocks, anti-islanding coordination, better metering, cleaner interfaces to the home EMS and clear safety responsibility, the separate unit becomes worth it.
How do I choose between a simple backup-only V2H mode and full bidirectional V2H with self-consumption?
I start by deciding whether I just want backup power during outages or I also want to shift and export energy every day. Backup-only is simpler and cheaper, but self-consumption and V2H modes need better metering, tighter interlocks and EMS integration. If I plan to support V2G later, I treat that as a separate, higher bar.
How much headroom should I design into the V2H power rating compared to the home’s typical and peak loads?
I size the V2H power rating by looking at my critical loads, my typical evening load and my worst-case peaks. The transfer unit does not have to cover absolutely everything, but it should run heating, networking, lighting and key appliances with some headroom. I usually add margin for future EVs, heat pumps or extra IT gear.
What contactor or transfer topology should I use to guarantee break-before-make and avoid grid back-feed?
For safe transfer I always aim for a topology that physically prevents grid and V2H sources from being tied together. That normally means two contactors or a transfer switch with mechanical interlock and logic that enforces break-before-make. I design a clear all-open fail-safe state so any fault or uncertainty drops both paths at once.
How fast does the V2H transfer need to be to avoid nuisance resets of home appliances and IT loads?
I set the transfer speed by thinking about which loads I care about most. Many small appliances, routers and PCs will ride through a short interruption but will reset if I take too long. If I want the transition to feel seamless, I target tens of milliseconds and accept that some legacy devices may still restart occasionally.
Which anti-islanding responsibilities belong to the inverter and which belong to the V2H transfer unit?
I treat anti-islanding as a shared responsibility but with different roles. The inverter or bidirectional charger implements the detailed algorithms, monitors grid voltage and frequency and raises a trip when the utility is gone. The V2H transfer unit turns that trip into a hard open point to the grid and manages safe reconnection afterwards.
How accurate does my metering need to be, and when do I actually need revenue-grade metering ICs?
My metering accuracy target follows the use case. If I only need internal logs and rough optimisation, system-grade metering is usually enough. If I want to settle energy with a utility, run a programme or present bankable numbers, I specify revenue-grade accuracy for the grid path and may keep system-grade metering on the EV branch.
What isolation and creepage or clearance rules typically apply to a residential V2H transfer unit?
For isolation and creepage or clearance I start from the applicable safety standards and the installation voltage. I split the design into a low-voltage control domain and a high-voltage measurement and switching domain, then use digital isolators and isolated transceivers between them. The exact millimetre values and test methods come from the safety file, not rule-of-thumb drawings.
How should I think about overcurrent, residual-current and leakage protection around the V2H transfer unit?
I think about protection as three related layers. Overcurrent and long overloads are handled by breakers, but the V2H controller can use metering data to limit power before they trip. Residual and leakage currents need their own sensing front-ends and thresholds. I make sure the transfer unit leaves room to integrate those RCD functions cleanly.
How should I integrate the V2H transfer unit with the home energy management system and the EVSE or charger?
I integrate the V2H transfer unit by treating the controller as a small hub. It exchanges readiness and power limits with the EVSE or charger, sends measurements and status into the home EMS and, if needed, reads data from a smart meter or utility link. A simple local HMI then presents modes, power flows and alarms to the homeowner.
Which communication interfaces should I mandate on the V2H transfer unit to avoid being locked into one vendor’s ecosystem?
To avoid lock-in I specify the physical interfaces I want before I talk about cloud platforms. For most projects I ask for CAN or RS-485 toward the EVSE, RS-485 or PLC for meter or utility links and Ethernet toward the home gateway. Optional Wi-Fi or cellular can sit behind the gateway rather than inside the V2H unit itself.
What information should I include in an RFQ to get realistic V2H transfer unit proposals from suppliers?
When I write an RFQ I include the region and interconnection standards, nominal voltage, kW rating, allowed transfer time and operating modes. I describe the required contactor poles, metering accuracy, residual-current protection, communication interfaces and security features. Finally I list the safety categories, insulation class and any future V2G or grid-service expectations so suppliers can scope the design.
