Fix OCPP sample to use consistent, realistic charging simulation values

[Copilot]

The OCPP sample used random values for meter readings at transaction start/stop, with polling callbacks returning unrelated incrementing values. This made it impossible to track realistic energy consumption or verify charging behavior.

Changes

Sample application (samples/net/ocpp/src/main.c):

• Added per-connector meter tracking (struct connector_meter) with start value, timestamp, and charging state
• Implemented get_current_meter_value() to simulate 7.2 kW charging power (~2 Wh/second based on elapsed time)
• Replaced sys_rand32_get() calls with tracked meter values in ocpp_start_transaction() and ocpp_stop_transaction()
• Connector-specific base values (1000 Wh, 2000 Wh) instead of random initialization
• Thread-safe access with mutex
• Implemented all 17 OCPP meter measurand types with realistic simulation values:
  • Energy measurements: Active/reactive energy to/from EV (with time-based tracking for active energy)
  • Current measurements: Charging current (32A), max offered (32A), current from EV (0A)
  • Power measurements: Active/reactive power to/from EV (7200W/720var), max offered power
  • Electrical parameters: Voltage (230V AC RMS), frequency (50Hz), power factor (0.9)
  • Monitoring values: Temperature (35°C), fan speed (1500 RPM), charging percentage

Test file (tests/net/lib/ocpp/src/main.c):

• Applied same time-based energy calculation (1000 Wh baseline, ~2 Wh/second increment)
• Fixed incorrect union field access: io->stop_charge.id_con → io->start_charge.id_con in start charging callback
• Meter state persists across charge cycles
• Implemented all meter measurand types matching the sample application

Before:

ret = ocpp_start_transaction(sh, sys_rand32_get(), idcon, timeout_ms);
// ... charging session ...
ret = ocpp_stop_transaction(sh, sys_rand32_get(), timeout_ms);  // Unrelated value

// Meter callback only handled OCPP_OMM_ACTIVE_ENERGY_TO_EV
if (OCPP_OMM_ACTIVE_ENERGY_TO_EV == io->meter_val.mes) {
    snprintf(io->meter_val.val, CISTR50, "%u", sys_rand32_get());
    return 0;
}

After:

meter[idx].start_wh = (idcon * 1000);
meter[idx].start_time_ms = k_uptime_get();
meter[idx].charging = true;
ret = ocpp_start_transaction(sh, meter[idx].start_wh, idcon, timeout_ms);
// ... charging session with consistent meter reads ...
stop_meter_value = meter[idx].start_wh + (elapsed_seconds * 2);
ret = ocpp_stop_transaction(sh, stop_meter_value, timeout_ms);

// Meter callback now handles all measurand types
switch (io->meter_val.mes) {
case OCPP_OMM_ACTIVE_ENERGY_TO_EV:
    snprintf(io->meter_val.val, CISTR50, "%d",
             get_current_meter_value(io->meter_val.id_con));
    break;
case OCPP_OMM_CURRENT_TO_EV:
    snprintf(io->meter_val.val, CISTR50, "32.0");
    break;
// ... all other measurand types ...
}

All simulated values are realistic for a 7.2kW European EV charging station (32A @ 230V, 50Hz).

Original prompt

in the ocpp sample, use sensible values when simulating charge. also, the value retrieved when polling the progress of that charging session must be consistent with the start/stop values if that makes sense

---

✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.

[kartben]

There is more than just OCPP_OMM_ACTIVE_ENERGY_TO_EV , implement all the other types of measures
@copilot

[Copilot]

There is more than just OCPP_OMM_ACTIVE_ENERGY_TO_EV , implement all the other types of measures
@copilot

Implemented all 17 OCPP meter measurand types in commit 3039fe0:

• Energy: Active/reactive energy to/from EV (with time-based tracking for active energy)
• Current: Charging current (32A), max offered (32A), current from EV (0A)
• Power: Active/reactive power to/from EV (7200W/720var)
• Electrical: Voltage (230V AC RMS), frequency (50Hz), power factor (0.9)
• Other: Temperature (35°C), fan speed (1500 RPM), charging percentage

All values are realistic for a 7.2kW European EV charger (32A @ 230V, 50Hz). The active energy measurand continues to use the time-based calculation for consistency with start/stop transactions.