Energy management & EMS integration FAQ

EV chargers do not live in isolation. A modern home or building has solar panels, a battery, a heat pump, hot-water storage, HVAC, lighting, sometimes a swimming pool — and on top of that a dynamic electricity tariff and a limited grid connection. Charging well in 2026 is a coordination problem, not a charger problem.

This FAQ explains how Veton chargers fit into that picture: built-in basic load management for sites that do not have a full energy management system (EMS), and an open Modbus/TCP interface for sites that do.

Why use an external energy management system?

The best charging decision depends on information that the charger itself does not have. Solar production right now, battery state of charge, whether the heat pump is about to start a defrost cycle, what the spot price will do in the next four hours, whether the dishwasher is running, what the building connection limit is, what the user wants the car ready by tomorrow morning. The charger sees one piece of the puzzle: the car.

An external EMS sees all of it. It can decide to slow the car down so the heat pump can finish a hot-water cycle on solar, or to push the car to 11 kW for the next two hours because spot prices are negative and the battery is full. Charger-only “smart charging” cannot make those calls because it does not know what else is happening in the building.

One system that knows everything beats five apps that each know one thing. That is the architectural reason to put the EMS above the charger, not inside it.

One app versus many apps

In a premium project, the user experience matters as much as the energy outcome. A house with one app for the charger, another for the inverter, another for the battery, another for the heat pump and a fifth for the home automation is not finished — it is fragmented. The end client should open one interface and see one coherent picture.

This is also why Veton avoids forcing its own cloud or app on installations that already have a building automation or EMS layer. Niko Home Control, Qbus, Loxone, KNX, Home Assistant, Xemex, LifePowr — if it speaks Modbus or OCPP, it can drive a Veton charger natively. The end client keeps their familiar interface; the charger becomes part of the building, not a guest in it.

What if there is no EMS?

Most homes do not have a full EMS, and many never will. For those installations, Veton chargers ship with their own basic load management built in:

• Static current limit — set per charger via the local web interface or mobile app, protects the building connection.
• Group balancing — up to 48 Veton charging points can be balanced as one group from a single Phoenix Contact CHARX controller, with multiple groups possible.
• Mobile app and local web UI — start, stop, set max current, view sessions, manage RFID whitelist, all without depending on a cloud service.
• Optional dynamic balancing — with an external grid meter (Carlo Gavazzi, Iskra, Inepro, Phoenix Contact EEM-series) the charger can throttle dynamically when the rest of the building draws more.

This is enough for the majority of single-charger residential and small commercial sites. The moment a site adds solar, battery and a heat pump and wants them coordinated, the right answer is to add an EMS — not to put more logic into the charger.

How do I connect my own EMS to a Veton charger?

Veton chargers run on a Phoenix Contact CHARX controller, which exposes a documented Modbus/TCP register map on port 502. Any EMS that speaks Modbus/TCP can read live charging data and write the target current. There is no cloud round-trip, no vendor lock-in, no API key.

Connection details

• Protocol: Modbus/TCP
• Port: 502
• Unit ID / slave: 1
• Connector base offset: connector_number × 1000 (so connector 1 uses registers 1000–1999, connector 2 uses 2000–2999, and so on)
• 32-bit values: two registers, MSW first, big-endian

The registers an EMS actually needs

A typical EMS only needs to read a handful of registers to make good decisions, and write one register to act on them. The full Phoenix Contact register map is large; the practical subset for energy management is short.

For a single-connector station, the integration loop is: read X232–X299 every few seconds, decide a target current based on solar, battery, price and other loads, write X301 and refresh the watchdog. That is enough to do PV-tracking, dynamic load balancing and price-based charging from any EMS.

Use the watchdog

Always configure the Modbus watchdog (X306 + X307). If the EMS or the network goes down, the charger falls back to a safe current after the timeout instead of holding the last commanded value. This is the difference between an EMS integration that is safe to deploy and one that is not.

Is there a reference implementation?

Yes. Veton maintains an open Home Assistant integration that uses exactly the registers above. It includes a coordinator that polls the charger every 5 seconds, an EMS controller with seven modes (solar, capacity, tariff and combinations), HomeWizard P1 meter integration and EnergyZero day-ahead pricing for the Netherlands and Belgium.

It is a working example of a third-party EMS driving a Veton charger over Modbus/TCP, and it is intentionally readable so installers and integrators can copy the patterns into Niko Home Control, Loxone, KNX, OpenHAB, ioBroker or a custom PLC.

What about OCPP?

OCPP is the right protocol for a charging-platform relationship: billing, RFID authorisation, remote support, multi-site reporting. It is not the right protocol for sub-second energy decisions in a single building. For that, Modbus/TCP is faster, simpler and works fully locally.

Most well-designed Veton sites use both: OCPP to a billing platform of the owner’s choice, and Modbus to the local EMS for real-time energy management. They do not interfere with each other.

Related topics

See also load balancing, solar EV charging, local OCPP, EMS and cloud management, OCPP and charging platforms and charging power and cables.