Planning a CT4000 deployment with dynamic, closed-loop load control and seeking real-world control loop characteristics and failure modes I am designing a site with multiple CT4000 dual-port L2 units on a 120/208 V 3Φ panel with a constrained feeder and variable on-site PV. The objective is to implement continuous, closed-loop demand limiting driven by a building EMS, not just static panel caps or scheduled DR events. ChargePoint’s “Power Management” and DR integrations look promising on paper, but I am struggling to find hard data on control latency, granularity, and offline behavior specifically for CT4000 hardware. Questions for operators who have implemented active load modulation (OpenADR 2.0b, ChargePoint APIs, or equivalent) with CT4000s: End-to-end latency and jitter: What is the typical and worst-case latency from a demand-limit update (e.g., OpenADR or API call) to an actual per-port pilot current change at a CT4000? Do you see deterministic behavior under good backhaul (wired vs LTE) or significant variance session-to-session? Resolution, ramping, and minimums: What is the smallest reliable current step size per port (A) the CT4000 will honor mid-session? Is there an enforced ramp rate (A/s), or does it step immediately? Behavior when commanded below the SAE J1772 6 A floor: does the station clamp at 6 A, pause the session, or drop the contactor? Dual-port allocation logic under a station- or group-level cap: With both ports active, does the CT4000 equal-share, proportional-share, or use a queue/priority model? If a station-level cap is applied (e.g., 32 A total), how predictable is the per-port reallocation as one vehicle tapers? Group management and offline failover: When operating a group cap across several stations, what happens if WAN connectivity to ChargePoint’s cloud is lost? Are group limits cached and enforced locally, or do stations revert to nameplate limits and risk feeder trips? Any documented/observed grace periods, default fallbacks, or watchdog behaviors during prolonged outages? Integration mode and pathway: For OpenADR-based control, is the VEN endpoint effectively the cloud with downstream control “fanned out,” or can CT4000s act on OpenADR signals with local autonomy? If using ChargePoint’s APIs for demand limits, what polling/command cadence is practical before you hit rate limits or see throttling? Vehicle behavior under frequent setpoint changes: Which vehicle models are tolerant of rapid current adjustments (≤5 s) and which exhibit session drops or ignore downward adjustments mid-charge? Any make/model-specific quirks at 208 V versus 240 V supply that affect stability when modulating near the 6-10 A range? Metering and billing implications: Does the internal metrology maintain accuracy through rapid current changes for kWh billing, or do you see reconciliation issues on invoices under aggressive modulation? Any firmware thresholds that “debounce” pilot changes and cause short-lived demand spikes not reflected in station-reported telemetry? Phase balancing at the panel: For multi-station installations on 120/208 V wye, has anyone coordinated phase assignment and group control to actively balance A-B, B-C, and C-A loads? Any tooling or practices to avoid systemic phase bias with CT4000s? Security and protocol details: TLS versions/cipher constraints for DR/API control in production today; any enterprise firewall/proxy caveats that add meaningful latency? Are there site-facing logs or syslog exports to time-correlate control commands with pilot current updates at the station? Known-good configurations, firmware versions, or specific pitfalls would be highly valuable. Even better would be time-stamped datasets showing: Control command time Port pilot current target Measured current at 1-5 s resolution Session state transitions Network RTT/packet loss during tests If there is no reliable path to sub-5-second response via cloud control, has anyone implemented a safe local fallback (e.g., upstream feeder metering with fast breaker protection, or an intermediary local controller) that cooperates with CT4000s without fighting the ChargePoint cloud logic?

FWIW from a recent CT4000 (mixed CT4021/4025) rollout on 120/208 V with PV and a tight feeder, a few datapoints that might help: Latency/jitter: seeing 3 -8 s typical from cloud limit change to pilot change on hardwired backhaul, 8 -20 s on LTE when signal is clean. Worst-case spikes to 30-60 s during packet loss or after firmware updates. It’s not real-time deterministic, but pretty repeatable on wired. Step size/ramp: 1 A steps are honored mid-session; most cars react within 1-3 s. No enforced ramp rate from the station side (it steps); some cars internally smooth. If a computed share drops below 6 A, ChargePoint tends to pause that port rather than advertise <6 A. Dual-port sharing: default behavior has been equal-share with quick reallocation as one car tapers (rebalances every few seconds). First-in doesn’t seem to get hard priority unless you configure it that way in Power Management. Group caps offline: site-level caps are cloud-coordinated. When WAN drops, stations hold the last-known limit for a while (we’ve seen “minutes,” not hours), then drift back toward station defaults. We treat cloud as SPOF and rely on upstream protection for true failsafe. OpenADR/API path: VEN lives in ChargePoint’s cloud; CT4000s don’t act as local VENs. API updates at 5 -10 s cadence have been fine; faster than 2 -3 s starts to hit throttling and you gain nothing due to station/vehicle reaction time anyway. Vehicle tolerance: Tesla (via adapter), Bolt, newer Leafs, Model 3/Y handle 5 s adjustments fine down to 6 -8 A at 208 V. Older i3 and early Leafs have been touchier near the floor and sometimes drop if you bounce them between 6-8 A repeatedly. RAV4 Prime occasionally ignores a small downward step until the next pilot change. Metering/billing: kWh totals reconcile within 1 -2% for us even with aggressive modulation. Telemetry is time-bucketed, so very short spikes/steps don’t always line up perfectly in exports, but invoices haven’t gone weird. Phase balance: best luck assigning pedestals sequentially AB/BC/CA down the row and keeping each “site group” evenly spread across phases. A simple panel map + spreadsheet saved us from a persistent A-B bias. Security/latency gotchas: TLS 1.2 with modern ciphers; SSL inspection breaks things (especially websockets). Proxies add 100 -300 ms but aren’t the main source of control lag. Local fallback: for sub‑5 s protection we use an upstream feeder meter with a shunt-trip contactor that drops the EV branch if it approaches a hard ceiling; the cloud limits run more conservatively underneath so they don’t “fight.” If you end up capturing time-stamped pilot/current at 1-5 s resolution, I’d love to compare traces. I’m especially curious if anyone has truly stable <5 s loops on CT4000s over LTE without oscillations.

Chargepoint Ct4000

ChargedLife

Planning a CT4000 deployment with dynamic, closed-loop load control and seeking real-world control loop characteristics and failure modes

I am designing a site with multiple CT4000 dual-port L2 units on a 120/208 V 3Φ panel with a constrained feeder and variable on-site PV. The objective is to implement continuous, closed-loop demand limiting driven by a building EMS, not just static panel caps or scheduled DR events. ChargePoint’s “Power Management” and DR integrations look promising on paper, but I am struggling to find hard data on control latency, granularity, and offline behavior specifically for CT4000 hardware.

Questions for operators who have implemented active load modulation (OpenADR 2.0b, ChargePoint APIs, or equivalent) with CT4000s:

End-to-end latency and jitter:
- What is the typical and worst-case latency from a demand-limit update (e.g., OpenADR or API call) to an actual per-port pilot current change at a CT4000?
- Do you see deterministic behavior under good backhaul (wired vs LTE) or significant variance session-to-session?
Resolution, ramping, and minimums:
- What is the smallest reliable current step size per port (A) the CT4000 will honor mid-session?
- Is there an enforced ramp rate (A/s), or does it step immediately?
- Behavior when commanded below the SAE J1772 6 A floor: does the station clamp at 6 A, pause the session, or drop the contactor?
Dual-port allocation logic under a station- or group-level cap:
- With both ports active, does the CT4000 equal-share, proportional-share, or use a queue/priority model?
- If a station-level cap is applied (e.g., 32 A total), how predictable is the per-port reallocation as one vehicle tapers?
Group management and offline failover:
- When operating a group cap across several stations, what happens if WAN connectivity to ChargePoint’s cloud is lost?
- Are group limits cached and enforced locally, or do stations revert to nameplate limits and risk feeder trips?
- Any documented/observed grace periods, default fallbacks, or watchdog behaviors during prolonged outages?
Integration mode and pathway:
- For OpenADR-based control, is the VEN endpoint effectively the cloud with downstream control “fanned out,” or can CT4000s act on OpenADR signals with local autonomy?
- If using ChargePoint’s APIs for demand limits, what polling/command cadence is practical before you hit rate limits or see throttling?
Vehicle behavior under frequent setpoint changes:
- Which vehicle models are tolerant of rapid current adjustments (≤5 s) and which exhibit session drops or ignore downward adjustments mid-charge?
- Any make/model-specific quirks at 208 V versus 240 V supply that affect stability when modulating near the 6-10 A range?
Metering and billing implications:
- Does the internal metrology maintain accuracy through rapid current changes for kWh billing, or do you see reconciliation issues on invoices under aggressive modulation?
- Any firmware thresholds that “debounce” pilot changes and cause short-lived demand spikes not reflected in station-reported telemetry?
Phase balancing at the panel:
- For multi-station installations on 120/208 V wye, has anyone coordinated phase assignment and group control to actively balance A-B, B-C, and C-A loads? Any tooling or practices to avoid systemic phase bias with CT4000s?
Security and protocol details:
- TLS versions/cipher constraints for DR/API control in production today; any enterprise firewall/proxy caveats that add meaningful latency?
- Are there site-facing logs or syslog exports to time-correlate control commands with pilot current updates at the station?

Known-good configurations, firmware versions, or specific pitfalls would be highly valuable. Even better would be time-stamped datasets showing:

Control command time
Port pilot current target
Measured current at 1-5 s resolution
Session state transitions
Network RTT/packet loss during tests

If there is no reliable path to sub-5-second response via cloud control, has anyone implemented a safe local fallback (e.g., upstream feeder metering with fast breaker protection, or an intermediary local controller) that cooperates with CT4000s without fighting the ChargePoint cloud logic?

ampedadventurer

FWIW from a recent CT4000 (mixed CT4021/4025) rollout on 120/208 V with PV and a tight feeder, a few datapoints that might help:

Latency/jitter: seeing ₃-8 s typical from cloud limit change to pilot change on hardwired backhaul, ₈-20 s on LTE when signal is clean. Worst-case spikes to 30-60 s during packet loss or after firmware updates. It’s not real-time deterministic, but pretty repeatable on wired.
Step size/ramp: 1 A steps are honored mid-session; most cars react within 1-3 s. No enforced ramp rate from the station side (it steps); some cars internally smooth. If a computed share drops below 6 A, ChargePoint tends to pause that port rather than advertise <6 A.
Dual-port sharing: default behavior has been equal-share with quick reallocation as one car tapers (rebalances every few seconds). First-in doesn’t seem to get hard priority unless you configure it that way in Power Management.
Group caps offline: site-level caps are cloud-coordinated. When WAN drops, stations hold the last-known limit for a while (we’ve seen “minutes,” not hours), then drift back toward station defaults. We treat cloud as SPOF and rely on upstream protection for true failsafe.
OpenADR/API path: VEN lives in ChargePoint’s cloud; CT4000s don’t act as local VENs. API updates at ₅-10 s cadence have been fine; faster than ₂-3 s starts to hit throttling and you gain nothing due to station/vehicle reaction time anyway.
Vehicle tolerance: Tesla (via adapter), Bolt, newer Leafs, Model 3/Y handle 5 s adjustments fine down to ₆-8 A at 208 V. Older i3 and early Leafs have been touchier near the floor and sometimes drop if you bounce them between 6-8 A repeatedly. RAV4 Prime occasionally ignores a small downward step until the next pilot change.
Metering/billing: kWh totals reconcile within ₁-2% for us even with aggressive modulation. Telemetry is time-bucketed, so very short spikes/steps don’t always line up perfectly in exports, but invoices haven’t gone weird.
Phase balance: best luck assigning pedestals sequentially AB/BC/CA down the row and keeping each “site group” evenly spread across phases. A simple panel map + spreadsheet saved us from a persistent A-B bias.
Security/latency gotchas: TLS 1.2 with modern ciphers; SSL inspection breaks things (especially websockets). Proxies add ₁₀₀-300 ms but aren’t the main source of control lag.
Local fallback: for sub‑5 s protection we use an upstream feeder meter with a shunt-trip contactor that drops the EV branch if it approaches a hard ceiling; the cloud limits run more conservatively underneath so they don’t “fight.”

If you end up capturing time-stamped pilot/current at 1-5 s resolution, I’d love to compare traces. I’m especially curious if anyone has truly stable <5 s loops on CT4000s over LTE without oscillations.