V2G Discharge Test — Charger 551155

Summary

On 17 June 2026 we attempted a small, controlled V2G discharge from a real EV through charger 551155 — commanded from our backend over its secondary OCPP connection (SERVERURL2). The charger never responded.

Both attempts returned a conf timeout: the SetChargingProfile command went out on a healthy, open WebSocket, but the charger sent back nothing — no CALLRESULT, no CALLERROR — and the vehicle simply kept charging (it never discharged). This report sets out exactly what we sent, what the charger did, and the candidate explanations to take to TellusPower.

What we set up

The exact command we sent

An OCPP 1.6-J SetChargingProfile CALL. The discharge-specific fields are highlighted.

[
  2,
  "<msgId>",
  "SetChargingProfile",
  {
    "connectorId": 2,
    "csChargingProfiles": {
      "chargingProfileId": 6,
      "stackLevel": 2,
      "chargingProfilePurpose": "TxProfile",
      "chargingProfileKind": "Absolute",
      "chargingSchedule": {
        "startSchedule": "2026-06-17T07:14:30Z",
        "chargingRateUnit": "W",
        "duration": 300,
        "chargingSchedulePeriod": [
          {
            "startPeriod": 0,
            "limit": 5000,
            "numberPhases": 3,
            "limitDischarge": -5000,
            "desiredMode": "discharging"
          }
        ],
        "minChargeRate": 0
      }
    }
  }
]

What happened

Why this is telling

The silence is the key signal. A spec-compliant charger that received a malformed or unsupported message should reply with a CALLERROR stating the reason — we got none. And this is not a connection problem: the socket was stably open for ~14 minutes, and this same charger does answer read commands (GetConfiguration) on this very connection when stable. So the non-response is specific to this command, not the link.

Possible causes for no response

1. The V2G profile shape / mechanism isn't what the charger expectsmost likely

   The discharge relies on the TellusPower-specific limitDischarge / desiredMode fields, built from an example. 551155 may need a different profile shape, different fields, a different chargingProfilePurpose, or an entirely different V2G-initiation message. An unrecognised command silently dropped (rather than CALLERROR'd) fits the observation.

2. Control commands are accepted only from the primary CMSmost likely

   This charger is dual-homed and already routes Authorize / Start / Stop transactions to the primary CMS only — never to our SERVERURL2 backend. V2G control (SetChargingProfile) may follow the same rule: read commands are honoured on the secondary backend, but control commands are ignored. If so, discharge cannot be initiated from our backend at all.

3. V2G discharge needs a dedicated initiation step

   Discharge may require a vendor-specific handshake, a DataTransfer command, or a RemoteTrigger before/instead of a charging profile — not SetChargingProfile alone.

4. The vehicle/charger wasn't in a V2G-ready state

   The vehicle was actively importing. A discharge may require a different session state or an explicit V2G-capable handshake that wasn't present.

5. Connection instability / unread messagelargely ruled out

   Considered, but the socket was stably open ~14 min, both fires landed on it, and read commands work on this socket when stable. The frame log shows the charger streaming MeterValues continuously across both fires.

The evidence — full frame log

The complete OCPP frame log captured on our backend for this session (≈3 hours, 537 genuine wire frames): every charger message (BootNotification, StatusNotification, MeterValues, the Autocharge DataTransfer/MACIDInfo), our replies, and the session's connect/close churn. The two SetChargingProfile fires are spliced in at their approximate times and clearly marked "_reconstructed": true — they were not captured on the wire (outbound command logging was not yet deployed), so they are flagged to keep the record honest.

Questions for TellusPower

1. What is the correct message and format for 551155 to initiate a V2G discharge? Is SetChargingProfile with limitDischarge/desiredMode the intended mechanism, and if so what shape does the charger expect?
2. Does the charger accept control commands (SetChargingProfile / V2G) on the secondary backend (SERVERURL2), or only from the primary CMS — as it already does for Authorize/Start/Stop?
3. If a malformed/unsupported command is received, should the charger return a CALLERROR? We received total silence, which made the failure hard to diagnose.