SDM01 G2X & Combo Gen2 — EV Charger DLB Integration Guide

A complete technical guide to integrate the SDM01 Combo Gen2 and SDM01 G2X smart meters via Wi-Fi for Dynamic Load Balancing (DLB)

Status: Active| Applies to: SDM01 G2X and SDM01 Combo Gen2 | Firmware: V10+ | Audience: EV Charger Product Managers & Firmware Engineers| Last Updated: 2026-08-01

---

TL;DR — Quick Decision Card

What is your target DLB polling interval?

≤ 1 second (high-frequency, fastest response)
└── Raw UDP / UDP AES  ← Strongly recommended
    Push-based, zero connection overhead, lowest latency
    See Section 5.1

1–5 seconds (mid-frequency, covers most residential DLB use cases)
├── Raw UDP (still the simplest option)
├── HTTP polling (if your MCU already has an HTTP client stack)
└── Modbus TCP (if you have an existing Modbus stack)
    ⚠️ Single-connection limit — see Section 5.2 warning

> 5 seconds (low-frequency monitoring / energy logging)
└── HTTP polling (simplest, same JSON format as UDP)
    See Section 5.4

Configuration writes (one-shot)
├── HTTP POST  ← Primary local channel
│   See Section 5.4
├── MQTT       ← Cloud / remote configuration
└── BLE API    ← Local mobile configuration (BT Powerlink app or custom app)

Security compliance required (EN 18031)?
├── UDP AES (encrypted push, maintains low latency)  ← Recommended
└── WSS or Modbus TCP over TLS
    ⚠️ Pro firmware: max 2 concurrent TLS connections total recommended
    See Section 5.3 & 5.5

Multi-charger setup?
└── See Annex A for architecture options
   (Centralized Arbiter / OCPP Cloud Coordination)

---

1. Purpose & Scope

This guide helps EV charger product managers and firmware/embedded engineers integrate the SDM01 G2X and SDM01 Combo Gen2 smart energy meters into an EV charging system over a local Wi-Fi/LAN network to implement Dynamic Load Balancing (DLB) — also known as anti-tripping or load management.

What DLB does: By continuously monitoring the total grid import current ($I_{grid}$) at the home's main incomer, the EV charger dynamically adjusts its charging current so that the total household load never exceeds the main circuit breaker rating ($I_{max}$), preventing nuisance tripping.

What this guide covers:

• System architecture and control flow

• Electrical installation reference

• Wi-Fi provisioning and device discovery

• Communication protocol selection (Raw UDP, HTTP, Modbus TCP, MQTT, WSS)

• DLB closed-loop control logic and fail-safe design

• Testing and validation checklist

• Advanced: Multi-charger DLB and HEMS integration

• Advanced: Custom ESP32-C6 firmware development

---

2. System Architecture Overview

2.1 Control Flow

Step	Actor	Action
① Provision	User / Installer	Configure meter Wi-Fi via BLE (BT Powerlink app or custom app via BLE API)
② Discover	EV Charger (Main MCU)	Auto-discover meter IP on LAN via mDNS
③ Communicate	EV Charger (Main MCU)	Receive high-frequency UDP pushes (or poll via Modbus TCP / HTTP)
④ Control	EV Charger (Main MCU)	Run DLB closed-loop algorithm, adjust PWM duty cycle
⑤ Fail-Safe	EV Charger (Main MCU)	On comms timeout, immediately ramp down to safe current

💡 Configuring the UDP target address: The meter needs to know which IP:Port to push UDP data to. This can be configured via any of the following channels:

• LAN HTTP — POST http://<meter-ip>/save-config with {"cmd":"udp","IpAddress":"<charger-ip>","localUdpPort":<port>} from the charger MCU or any LAN client

• BLE — via BT Powerlink app or your own app using the BLE Secured API (local, no internet required)

• Cloud MQTT — via your app → cloud MQTT broker → meter (requires meter to be online)

2.2 Key Parameters

Symbol	Description	Typical Value
$I_{max}$	Main circuit breaker rating (set by user)	e.g. 60 A
$I_{safe}$	Safety headroom (10–20% of $I_{max}$)	e.g. 6 A
$I_{grid}$	Real-time total grid import current (from meter)	Live reading
$I_{ev}$	Current EV charger output current	Live reading
$I_{available}$	Dynamically available current for EV charging	Calculated

Core DLB formula:

$I_{available} = I_{max} - I_{safe} - (I_{grid} - I_{ev})$

$(I_{grid} - I_{ev})$ represents the baseline load of all other household appliances.

---

3. Electrical Installation

⚠️ Safety Notice: Installation must be performed by qualified electricians only. Always de-energize the circuit before wiring.

3.1 Typical Installation Position

The meter should be installed at the main incomer (grid entry point) of the consumer unit, upstream of all loads including the EV charger. This ensures $I_{grid}$ reflects the true total household consumption.

3.2 CT Orientation

The split-core CTs must be installed with the correct polarity (arrow pointing toward the load / away from the grid). Reversed CT orientation will result in negative power readings during normal import, which will break the DLB logic.

• Positive value = importing from grid (normal consumption)

• Negative value = exporting to grid (e.g. solar surplus)

3.3 Supported CT Ratings

CT Rated Current	CT Aperture
50 A	Ø10 mm
120 A	Ø16 mm
300 A	Ø24 mm
400 A	Ø36 mm

---

4. Network Configuration & Device Discovery

4.1 Wi-Fi Provisioning (BLE)

The meter connects to your 2.4 GHz Wi-Fi network. Provisioning is done via BLE. Two paths are available:

Path A — BT Powerlink App (End-user / Installer)

1. Download the BT Powerlink app.

2. Scan the QR code on the meter OR scan for nearby meters via BLE → select the target device.

3. Enter your router's SSID and password → push to the meter.

4. The meter connects to Wi-Fi and obtains an IP address via DHCP.

Path B — Integrate BLE Provisioning into Your Own App (OEM)

If you are building your own EV charger companion app and want to provision the meter directly from within it, use Bituo's BLE API:

💡 For SDM01 G2X and Combo Gen2, always use the BLE Secured API. The BLE Basic API is for Gen1 only and is NRND (Not Recommended for New Designs).

💡 Best Practice: After provisioning, configure a DHCP static IP reservation on the router (bound to the meter's MAC address) to prevent IP changes after router reboots.

4.2 Automatic Device Discovery (mDNS)

• Service type: _http._tcp.local

• Hostname format: energysensor-{model}-{mac}.local

• Example: energysensor-SDM01-c8b0d137f7c4.local

Resolving this hostname always returns the meter's current IP, even after a DHCP lease renewal.

Fallback — HTTP probe:

GET http://<ip>/model
GET http://<ip>/sn/

A valid JSON response confirms the device is an SDM01 meter.

---

5. Communication Protocol Reference

🎯 Protocol Selection Matrix

Protocol	Direction	Recommended Interval	Best For	Encryption Option
Raw UDP	Meter → Charger (Push)	0.5–1 s	High-freq DLB, lowest latency	UDP AES
HTTP	Charger → Meter (Poll)	3–5 s	Mid/low-freq DLB, config writes	HTTPS (Pro only)
Modbus TCP	Charger → Meter (Poll)	3–5 s	Existing Modbus stack; single-charger only ⚠️	Modbus TCP over TLS (Pro only)
MQTT	Meter → Broker (Push)	1–5 s	Multi-charger with Linux master / HEMS controller	MQTTS
WebSocket	Bidirectional	Continuous real-time stream	Persistent real-time telemetry & bidirectional control	WSS (Pro only)

⚠️ TLS Concurrency Limit (Pro firmware): The Gen2 Pro firmware supports a maximum of 2 concurrent TLS connections recommended, selecting from: Modbus TCP over TLS, HTTPS, MQTTS, and WSS. Plan your security architecture accordingly.

❌ Never use HTTPS for high-frequency polling (such as < 3 s interval). Every HTTPS request triggers a full TLS handshake on the ESP32-C6 SoC, saturating the CPU and causing watchdog resets. HTTPS is only acceptable for low-frequency queries or one-shot configuration writes.

💡 WebSocket vs WSS: Plain WebSocket (ws://) is sufficient for most LAN DLB deployments. Use WSS (wss://) only when your security policy or compliance requirement (e.g. EN 18031) mandates encrypted transport. WSS counts as 1 TLS connection toward the Gen2 Pro 2-connection limit.

---

5.1 Raw UDP — Primary Protocol for High-Frequency DLB

Best for: Any DLB scenario requiring ≤ 1 s data freshness. The simplest and most efficient integration path.

Parameter	Value
Transport	UDP (connectionless)
Target IPs	Up to 5 unicast targets configured via BT Powerlink app
Direction	Meter pushes JSON to each configured target IP:Port
Recommended interval	0.5–1 second (configurable, min ~0.5 s)
Encryption	Cleartext (default) / UDP AES (enable via app)

📌 How UDP targeting works: The meter performs 5 independent unicast sends per interval — one to each configured target. There is no broadcast or multicast. Each target is an individual IP:Port pair configured in the BT Powerlink app (or via HTTP API). This means a maximum of 5 simultaneous receivers (e.g. charger A, charger B, HEMS gateway, monitoring system) can receive data directly from one meter. For more than 5 receivers, use a Leader-Follower or HEMS gateway architecture (see Annex A).

📌 Multicast support: Multicast UDP delivery is planned for a future firmware release, which will remove the 5-target limit for LAN broadcast scenarios.

5.1.1 Full Payload Example

{
  "Post": 142,
  "Time": 1785567041,
  "IP": "192.168.50.166",
  "Rssi": -46,
  "FWVersion": "3.1.7",
  "SerialNumber": "C8B0D137F7C4",
  "ProductModel": "SDM01_3PN",
  "MCUVersion": "001.01.00",
  "TP": 8,
  "VoltageX": "225.0",
  "VoltageY": "224.8",
  "VoltageZ": "224.8",
  "CurrentX": "0.000",
  "CurrentY": "0.000",
  "CurrentZ": "0.000",
  "ActivePowerX": "0.000",
  "ActivePowerY": "0.000",
  "ActivePowerZ": "0.000",
  "ReactivePowerX": "0.000",
  "ReactivePowerY": "0.000",
  "ReactivePowerZ": "0.000",
  "ApparentPowerX": "0.000",
  "ApparentPowerY": "0.000",
  "ApparentPowerZ": "0.000",
  "PowerFactorX": "1.00",
  "PowerFactorY": "1.00",
  "PowerFactorZ": "1.00",
  "UnbalanceLineCurrents": "0",
  "OverallPowerFactor": "1.00",
  "Frequency": "50.03",
  "ForwardEnergyX": "0.33",
  "ForwardEnergyY": "0.14",
  "ForwardEnergyZ": "0.47",
  "ReverseEnergyX": "0.00",
  "ReverseEnergyY": "0.00",
  "ReverseEnergyZ": "0.00"
}

5.1.2 Field Reference

The JSON payload is self-explanatory. Fields fall into two categories:

Device & Session Fields — metadata about the device and this packet: Post (sequence counter, increments by 1 each push — use to detect missed packets), Time (Unix timestamp), IP (meter's current LAN IP), Rssi (Wi-Fi signal strength in dBm), FWVersion / MCUVersion (firmware versions), SerialNumber (MAC-based unique device ID), ProductModel (e.g. SDM01_3PN = 3-phase 4-wire), TP (reporting interval in seconds).

Electrical Measurement Fields — per-phase readings for Voltage, Current, Active/Reactive/Apparent Power, Power Factor, and Energy. Phase suffix: X = L1, Y = L2, Z = L3.

⭐ For DLB, the only fields you need are CurrentX, CurrentY, and CurrentZ (unit: Amperes). Everything else is optional telemetry.

⚠️ All measurement values are strings (quoted numbers). Always parse with float() before arithmetic.

5.1.3 Derived Values for DLB

I_X = float(payload["CurrentX"])
I_Y = float(payload["CurrentY"])
I_Z = float(payload["CurrentZ"])

# Option A: Worst-phase current — RECOMMENDED default
# Protects the most loaded single-phase breaker from tripping
I_grid = max(I_X, I_Y, I_Z)

# Option B: Sum of all phases — for 3-phase symmetric load budgeting
I_grid_total = I_X + I_Y + I_Z

Recommendation: Use Option A (max) as the default DLB strategy. It is the most conservative and protects against single-phase breaker trips in unbalanced households.

5.1.4 Sign Convention

• Positive current / active power = importing from grid (normal consumption)

• Negative current / active power = exporting to grid (e.g. solar surplus)

5.1.5 UDP AES (Encrypted Variant)

Enable via BT Powerlink app. Payload structure and field names are identical to cleartext UDP; only the transport layer is AES-encrypted. The encryption key is the broadcast key derived during BLE secure pairing, shared between the meter and the paired app.

---

5.2 Modbus TCP — Mid-Frequency Polling for Single-Charger Deployments

Best for: Charger platforms with an existing Modbus TCP stack, at 3–5 s polling intervals.

⚠️ Critical: Single-Connection Limitation The firmware supports only ONE concurrent TCP connection and actively resets the socket after each read request. You must:

• Open a new TCP connection before each read

• Close it immediately after

• Wait a minimum of 150 ms between consecutive reads

Practical implication for DLB: Modbus TCP is suitable for single-charger + single-meter deployments only. If any other device on the same LAN attempts to poll the meter simultaneously (e.g. a monitoring tool, HEMS gateway, or another charger), the meter will reject the concurrent connection — which may disrupt your charger's DLB data acquisition. For multi-client or multi-charger scenarios, use Raw UDP or MQTT instead.

Parameter	Value
Port	502 (TCP)
Role	EV Charger = Master; Meter = Slave
Slave ID	1 (default)
Byte Order	Big-Endian (AB CD)
Recommended poll rate	3–5 s (stable); 1–2 s (acceptable with care)
Function Codes	0x03, 0x04 (read); 0x06 (write/control)

Register Map — Key DLB Registers (Float32, AB CD)

Address (Dec)	Address (Hex)	Description	Unit
1006	0x03EE	Current Phase A (L1)	A
1008	0x03F0	Current Phase B (L2)	A
1010	0x03F2	Current Phase C (L3)	A
1012	0x03F4	Active Power Phase A	kW
1014	0x03F6	Active Power Phase B	kW
1016	0x03F8	Active Power Phase C	kW
1044	0x0414	Total Active Power	kW

💡 Modbus TCP over TLS is available on Gen2 Pro firmware. Note the 2-connection TLS concurrency limit.

---

5.3 MQTT — Multi-Charger / HEMS Local Controller Scenarios

Best for: Multi-charger deployments where a Linux-based master charger or a dedicated HEMS Local Controller (e.g. Home Assistant, OpenHAB, custom Linux gateway) can run a local MQTT broker.

📌 Hardware prerequisite: Running a local MQTT broker (e.g. Mosquitto, ~5 MB RAM) requires a Linux-capable host. This is not suitable for resource-constrained embedded MCUs (FreeRTOS / bare-metal). If your charger MCU cannot run a broker, use Raw UDP (up to 5 unicast targets) or the Leader-Follower architecture instead (see Annex A).

Parameter	Value
Port	1883 (MQTT) / 8883 (MQTTS)
Direction	Meter publishes to broker; charger(s) subscribe
Configurable interval	1–30 s (default: 5 s; adjustable to 1 s)
QoS	0 (telemetry /data), 0/1 (commands /cmd)

Topic Architecture

Topic	Direction	Description
{Model}/{SN}/data	Meter → Broker	Periodic telemetry (energy data)
{Model}/{SN}/cmd	Broker → Meter	Commands to meter
{Model}/{SN}/cdata	Meter → Broker	Command execution responses
{Model}/{SN}/mdata	Meter → Broker	Device metadata (published on boot, retained)

Example topics for SDM01_3PN, SN C8B0D137F7C4:

SDM01_3PN/C8B0D137F7C4/data
SDM01_3PN/C8B0D137F7C4/cmd

MQTT Payload

The MQTT /data payload is structurally identical to the UDP payload, with two additions:

• TotalActivePower — pre-calculated sum of all three phases (kW) ✅

• TotalForwardEnergy — pre-calculated total imported energy (kWh) ✅

These pre-calculated totals make MQTT slightly more convenient for DLB than UDP (no need to sum phases manually).

💡 MQTTS: Supported on all firmware branches. Counts as 1 TLS connection toward the Gen2 Pro 2-connection limit.

---

5.4 HTTP — Mid/Low-Frequency Polling & Primary Configuration Channel

Best for: 3–5 s interval DLB polling (when UDP is not implemented), one-shot configuration writes, and diagnostic queries.

Parameter	Value
Port	80 (HTTP) / 443 (HTTPS, Pro only)
Recommended poll rate	3–5 s for DLB; ≤ once/min for HTTPS
Response format	Identical JSON to UDP payload

📌 HTTP is the primary local configuration channel. All device settings (UDP target IPs, MQTT broker address, reporting intervals, etc.) are written via HTTP POST. MQTT and BLE API are alternative configuration channels — see TL;DR.

⚠️ Do NOT use HTTPS for DLB polling intervals < 3 s. Each HTTPS request requires a full TLS handshake. At 1 s intervals this will saturate the ESP32-C6 CPU. HTTPS is acceptable for ≥ 3 s intervals or one-shot config writes only.

Key endpoints:

GET  http://<ip>/data          → Returns full JSON payload (same as UDP)
GET  http://<ip>/model         → Returns device model string
GET  http://<ip>/sn/           → Returns serial number
POST http://<ip>/config        → Write configuration parameters

---

5.5 WebSocket — Persistent Real-Time Connection

Best for: Scenarios requiring a persistent connection for continuous real-time data streaming and bidirectional control (e.g. Home Assistant local integration, custom dashboards).

Parameter	Value
Plain WebSocket (ws://)	Port 81
Secure WebSocket (wss://)	Port 502 (or custom)

💡 Use plain WebSocket (ws://) by default. WebSocket keeps the connection open, so the meter can push data continuously at full rate — equivalent to UDP in terms of data freshness, but with a persistent TCP channel. Only upgrade to WSS when your security policy or compliance requirement (e.g. EN 18031) explicitly mandates encrypted transport.

💡 WSS establishes a persistent connection — the TLS handshake happens only once at connection setup, then data flows with negligible overhead. This is why WSS is preferred over HTTPS for encrypted real-time data when TLS is required.

⚠️ WSS counts as 1 TLS connection toward the Gen2 Pro 2-connection limit.

For the complete JSON message format and command reference, see the WebSocket API Protocol documentation.

---

6. DLB Control Logic Implementation

6.1 Threshold Configuration

Parameter	How to Set	Example
$I_{max}$	User sets main breaker rating in charger app	60 A
$I_{safe}$	Fixed at 10–20% of $I_{max}$	6 A
Fallback current	User configures (min 6 A per IEC 61851)	6 A
Timeout threshold	5–15 s (configurable)	10 s

6.2 Control Loop (Pseudocode)

# DLB Control Loop — runs every 1 second (UDP) or every poll interval (HTTP/Modbus)
def dlb_loop():
    data = receive_meter_data()   # UDP packet, HTTP response, or Modbus read

    I_X = float(data["CurrentX"])
    I_Y = float(data["CurrentY"])
    I_Z = float(data["CurrentZ"])
    I_grid = max(I_X, I_Y, I_Z)  # Worst-phase strategy (recommended default)

    I_available = I_max - I_safe - (I_grid - I_ev)

    if I_grid > (I_max - I_safe):
        # RAMP DOWN — must complete within 2 seconds (safety-critical)
        I_ev_new = max(MIN_CURRENT, I_ev - STEP_DOWN)
        set_pwm_current(I_ev_new)

    elif I_available > I_ev + STEP_UP_THRESHOLD:
        # RAMP UP — slow and gradual to prevent oscillation
        if time_since_last_increase >= RAMP_UP_INTERVAL:
            I_ev_new = min(I_ev + 1, I_available)
            set_pwm_current(I_ev_new)

    if I_available < MIN_CURRENT:   # MIN_CURRENT = 6A per IEC 61851-1
        suspend_charging()
        wait_for_headroom()

📌 Control parameters (STEP_DOWN, STEP_UP_THRESHOLD, RAMP_UP_INTERVAL, etc.) are charger-side design decisions. The values above are illustrative only. Charger manufacturers should tune these based on their own product requirements, grid conditions, and EV compatibility testing.

6.3 Control Strategy Summary

Condition	Action	Speed
$I_{grid} > I_{max} - I_{safe}$	Ramp down PWM immediately	Fast: within 2 s
$I_{available}$ has surplus	Ramp up PWM gradually (+1A steps)	Slow: configurable interval
$I_{available} < 6A$	Suspend charging (IEC 61851-1 minimum)	Immediate
Data timeout	Trigger Fallback (see Section 6.4)	Within timeout window

Why asymmetric speed? Fast ramp-down prevents breaker trips (safety-critical). Slow ramp-up prevents control oscillation and avoids triggering the EV's BMS protection. Specific ramp rates and intervals are charger-side design decisions.

6.4 Fail-Safe / Fallback Mechanism

⚠️ This section is critical. A DLB system that silently continues full-power charging when meter comms are lost is worse than no DLB at all.

Trigger: No meter data received for 10 consecutive seconds (configurable, recommended range: 5–15 s).

Fallback actions (in order):

1. Immediately force charging current to minimum safe value (6 A).

2. If user enabled "Stop on comms loss": open relay and suspend charging.

3. Activate fault indicator + push notification: "DLB communication lost".

Recovery: After 3 consecutive successful data reads/packets, automatically exit Fallback and resume dynamic regulation.

---

7. Custom Firmware Path (Advanced)

For EV charger manufacturers who prefer to run proprietary firmware on the meter's Wi-Fi SoC instead of using Bituo's stock firmware.

7.1 Why Custom Firmware?

• Full control over Wi-Fi stack, security policies, and OTA update mechanism

• Deep integration with your own cloud platform or MQTT broker

• Compliance with your own cybersecurity certification requirements

• Eliminate dependency on Bituo's firmware release cycle

7.2 Hardware Architecture

┌─────────────────────────────────────────────────────┐
│             SDM01 G2X / Combo Gen2                  │
│                                                     │
│  ┌──────────────────┐      ┌─────────────────────┐  │
│  │  Wi-Fi/BLE SoC   │      │   Base Meter MCU    │  │
│  │   (ESP32-C6)     │◄────►│  (Metering + RS485) │  │
│  │                  │ UART │                     │  │
│  │  YOUR FIRMWARE   │      │  Calibration data   │  │
│  │  runs here       │      │  stored here        │  │
│  └──────────────────┘      └─────────────────────┘  │
│         │                           │               │
│      Wi-Fi                       RS485              │
└─────────────────────────────────────────────────────┘

Key principle: Flashing custom firmware on the ESP32-C6 does not affect metering accuracy or calibration data, which are stored independently in the Base Meter MCU.

7.3 Internal Data Interface: Modbus over UART

The ESP32-C6 reads energy data from the Base Meter MCU via Modbus RTU over UART (internal bus, separate from the external RS485 port).

Gen2 register compatibility: The internal UART Modbus register map is identical to Gen1 (ESP8685). Refer to the SDM01 Combo (ESP8685) Custom Firmware Guide for the complete register address table and UART parameters.

🛑 DANGER: LETHAL VOLTAGE. Always disconnect from AC mains before connecting any UART adapter.

---

8. Testing & Validation Checklist

📌 Note: The following checklist covers the key integration touchpoints between the SDM01 meter and the EV charger. It is intended as a starting reference only — each charger manufacturer will have their own validation methodology, reliability testing standards, and certification requirements that go well beyond the scope of this guide.

8.1 Communication Stability

• Open a UDP socket listener; verify packets arrive at the configured interval; verify Post counter increments by 1 each packet

• Simulate router power cycle → verify charger re-discovers meter via mDNS within 60 s

• Simulate Wi-Fi disconnection → verify Fallback triggers within configured timeout

• (Modbus TCP only) Verify no second client is simultaneously polling the meter; test connection reset behavior

• Anti-pattern test: Poll via HTTPS at 1 Hz → verify SoC reboots (confirms why UDP/HTTP is necessary for high-frequency use)

8.2 DLB Response Latency

• Connect a 3 kW resistive load suddenly to the household circuit

• Capture charger CP signal (PWM) with oscilloscope

• Pass criterion: PWM duty cycle reduces within < 2 seconds of load connection

8.3 Boundary Conditions

• Test $I_{available}$ oscillating around 6 A → verify no rapid suspend/resume toggling

• Test Fallback trigger → verify charger drops to 6 A within timeout

• Test Fallback recovery → verify charger exits Fallback after 3 successful reads

• Test $I_{available}$ < 6 A → verify charger suspends (does not attempt sub-minimum current)

8.4 Custom Firmware (if applicable)

• Verify internal UART Modbus reads match RS485 external port readings

• Verify custom OTA mechanism works independently of Bituo firmware updates

---

9. FAQ

Question	Answer
The meter's IP changed after a router reboot.	Use mDNS: resolve energysensor-SDM01-{mac}.local. Or set a DHCP static IP reservation.
Can I use HTTPS to poll every second?	No. TLS handshakes will overheat the ESP32-C6 and cause reboots. Use Raw UDP for ≤ 1 s, or HTTP for 3–5 s intervals.
What is the minimum charging current?	6 A per IEC 61851-1. If $I_{available}$ < 6 A, suspend charging — do not attempt sub-minimum current.
How many chargers can receive UDP data simultaneously?	Up to 5 (5 independent unicast targets; multicast support is planned for a future firmware release). For > 5 chargers, use MQTT or Leader-Follower architecture.
If my charger is already using Modbus TCP, can another device also poll the meter at the same time?	Not recommended. The meter supports only 1 concurrent Modbus TCP connection. Any second client will be rejected and may intermittently disrupt your charger's data acquisition. For multi-client scenarios, use Raw UDP or MQTT instead.
Can I integrate BLE provisioning into my own app?	Yes. Use the BLE Secured API for Gen2.
Does flashing custom firmware affect metering accuracy?	No. Calibration data is in the Base Meter MCU, unaffected by SoC firmware changes.
What happens if the meter loses Wi-Fi during charging?	Charger detects data timeout (default 10 s) → Fallback: reduces to 6 A or suspends.
How many TLS connections can Gen2 Pro handle simultaneously?	Maximum 2 recommended, selecting from: Modbus TCP over TLS, HTTPS, MQTTS, WSS. Plan your security architecture accordingly.

---

Annex A — Multi-Charger DLB Architecture

A.1 Multi-Charger DLB Coordination — Architecture Comparison

The two architectures below are both industry-validated and commonly seen in the field. The "broadcast self-calculate" pattern — where each charger independently derives its own allocation from raw $I_{grid}$ broadcast data — is generally not recommended, as it requires real-time state synchronization between chargers and tends to be fragile when charger count changes or packets are dropped.

---

🥇 Architecture A: Centralized Arbiter — Common for Residential & Small-Site

Suitable for deployments where a single local controller coordinates all chargers. The Arbiter role can be fulfilled by:

• A designated charger (e.g., the first-installed or highest-rated unit), or

• A local HEMS controller or home energy gateway that already manages other loads (PV, battery, etc.)

• Topology: One entity acts as the Arbiter; all chargers it manages are Followers.

• How it works:

  • a. The Arbiter communicates with the smart meter (e.g., via UDP unicast), receiving $I_{grid}$ data.

  • b. The Arbiter runs its allocation logic and determines an individual current limit for each Follower.

  • c. Each Follower's limit is delivered via LAN (e.g., UDP unicast, local MQTT, or a proprietary protocol).

• SDM01 fit: ✅ Up to 5 UDP unicast targets supported. The Arbiter (charger or HEMS controller) can receive meter push directly.

• Typical advantages:

  • Supports unequal power distribution and priority-based allocation

  • Fast trip-prevention response

  • Can leverage an existing HEMS controller without additional hardware

⚠️ Note: Each Follower should receive its own dedicated current limit, not the raw $I_{grid}$ value. Allocation logic runs on the Arbiter side.

---

🥈 Architecture B: OCPP Cloud Coordination — Common for Commercial Sites

Suitable for commercial deployments or where multi-brand interoperability is required.

• Topology: All chargers connect to a cloud-based Charging Station Management System (CSMS) via OCPP 1.6J / 2.0.1.

• How it works:

  • a. The CSMS issues individual power/current limit schedules to each charger via SetChargingProfile (Smart Charging Profile).

  • b. Meter data is forwarded to the CSMS via MQTT/HTTP (directly or through a local HEMS gateway), allowing the CSMS to adjust profiles dynamically.

• SDM01 fit: ✅ Meter can publish data to a cloud CSMS via MQTT or HTTP, or via a local HEMS gateway.

• Typical advantages:

  • Open industry standard; cross-brand compatible

  • Supports advanced features: billing, scheduling, remote management

  • Scales well to larger sites

---

A.2 Architecture Comparison Summary

	Architecture A: Centralized Arbiter	Architecture B: OCPP Cloud
Arbiter	Charger or local HEMS controller	Cloud CSMS
Meter → Arbiter	UDP unicast (LAN)	MQTT / HTTP (cloud)
Arbiter → Chargers	UDP unicast × N / local MQTT / proprietary	OCPP SetChargingProfile
SDM01 fit	✅ Native	✅ Via MQTT / HTTP
Works offline	✅ Yes	❌ No (cloud dependency)
Cross-brand	❌ Typically same-ecosystem	✅ OCPP standard
Best for	Residential / small site	Commercial / large site

---

A.3 Multi-Charger Current Distribution

This section outlines a common approach to current allocation in Architecture A. Charger manufacturers will typically implement their own allocation logic based on their product requirements — the following is provided as a reference pattern only.

A.3.1 Available Current Calculation

A typical starting point for the Arbiter's allocation calculation:

$I_{available} = I_{max} - I_{grid} + I_{ev\_total}$

Where:

• $I_{max}$ — main breaker rated current

• $I_{grid}$ — current grid import reading from the meter (e.g., worst phase)

• $I_{ev\_total}$ — sum of current limits currently assigned to all active chargers (to avoid double-counting EV load already reflected in $I_{grid}$)

A.3.2 Common Allocation Strategies

Strategy	Description	Typical Use Case
Equal Share	$I_{available}$ divided equally among all active sessions	Simple same-charger deployments
Priority-Based	Higher-priority chargers receive allocation first	VIP parking, fleet with SLA
Rated-Power Proportional	Allocation proportional to each charger's rated maximum current	Mixed charger types (e.g., 7.4 kW + 22 kW)

A.3.3 Minimum Current Consideration (IEC 61851)

Per IEC 61851-1, the minimum signalled current is 6 A. Charger implementations typically handle the case where a calculated allocation falls below this threshold by suspending that session (signalling State B) and redistributing the quota — but the specific handling is left to the charger manufacturer's discretion.

A.3.4 Ramp Behaviour Considerations

• Ramp-down is typically applied quickly to all chargers when $I_{grid}$ approaches the limit.

• Ramp-up is often staggered across chargers to reduce simultaneous inrush current risk.

The specific ramp rates and step sizes are implementation-defined by the charger manufacturer.

---

A.4 Multi-Level Fail-Safe Considerations

Single-charger fail-safe (§6) covers meter communication loss. In multi-charger deployments, additional failure scenarios are worth considering during system design.

A.4.1 Common Failure Scenarios

Scenario	Typical Handling
Meter → Arbiter link lost	Arbiter falls back to a conservative current limit for all chargers until meter comms recover
Arbiter unavailable	Followers fall back to a safe local current limit (e.g., 6 A) after a timeout
Follower goes offline	Arbiter may release that Follower's quota back to the pool for redistribution
Meter + Arbiter both lost	Followers suspend or reduce to minimum current independently

💡 The specific timeout values, fallback currents, and recovery sequences are implementation decisions for the charger manufacturer. The key principle is that each layer should have an independent fallback so that a single point of failure does not result in an uncontrolled overcurrent condition.

A.4.2 Arbiter Recovery — General Considerations

When the Arbiter recovers from a fault, it is generally advisable to:

1. Verify meter data is stable before resuming full allocation.

2. Re-query Follower states before recalculating limits.

3. Restore charging current gradually rather than all at once, to avoid simultaneous inrush from multiple EVs.