Create energy-based utilisation metrics
- Dominant language
- No language data
- Stars
- 14
- Forks
- 3
- PR merge metrics
- No merged PRs in 30d
Description
Add port-level and connector level energy-based utilisation metrics.
There are other ways: [here](https://www.linkedin.com/posts/lorenmcdonald_dcfc-utilization-metrics-activity-7313264018473775106-B_c2)
Ex: One port of 150 kW max_power can have 50 kW CHAdeMO and 150 kW CCS connectors, but only one connector can be used at a time.
## The core design decision: what does the port's max_power_kw represent?
I'd set it to the best-case connector — 150 kW (CCS) — because that's the physical ceiling the port infrastructure was built to support. The port could deliver 150 kW; whether it does depends on which connector a driver chooses to plug into.
Port-level utilization formula:
```
port_utilization_pct = SUM(energy_delivered_kwh, both connectors) / (port.max_power_kw × available_hours)
```
Since only one connector is active at a time, energy delivered across connectors sums cleanly with no overlap — that part is straightforward.
But here's the catch you should be aware of: this formula will make CHAdeMO sessions look chronically "underutilized" relative to the port ceiling — a CHAdeMO session running at its own full 50 kW max will only ever show ~33% port-level utilization (50/150), even though the connector itself was maxed out. That's not a bug — it's arguably the correct signal, because it captures a real opportunity cost: every hour spent on CHAdeMO is an hour the port wasn't capable of hitting its full potential throughput, regardless of demand.
I'd recommend splitting this into two distinct metrics rather than collapsing to one number:
Connector-level utilization — energy delivered ÷ (connector's own max_power_kw × active hours). This tells you "was this specific connector being used efficiently while it was in use" — fair, apples-to-apples, no penalty for connector choice.
Port-level utilization — energy delivered ÷ (port's max_power_kw × available hours), as above. This tells you "is this physical asset's installed capacity being fully exploited" — useful for infra planning (e.g., "should we deprecate the CHAdeMO cable and add a second CCS connector instead, since drivers rarely choose CHAdeMO and it caps throughput when they do").
Why both matter separately: if you only report port-level utilization, you can't tell whether low numbers mean "underused asset" or "connector standard driver preference is limiting throughput" — two very different problems with different fixes (more marketing/incentives vs. hardware upgrade). Given your background writing about avoiding generic single-number metrics that lie, this feels like exactly the kind of case where one blended number would hide the actual story.
Contributor guide
No contributing guide indexed for this repository
Assessment
This issue has not been assessed yet.