Summary
Once a charge point has been added, there is no supported way to change which measurands it reports. The selection UI exists but is only reachable while adding a charge point, and there is no options flow, no reconfigure flow, and no way to remove a charge point either — so the only route left is editing .storage/core.config_entries by hand with Home Assistant stopped.
Why the existing paths do not work
async_step_measurands is only called from async_step_cp_user, which starts with:
self._async_abort_entries_match({CONF_CPID: user_input[CONF_CPID]})so re-running the flow for a charger that is already configured aborts before it ever reaches the measurand selection.
Checked against current main:
- no
async_get_options_flow / OptionsFlow — the integration has no options dialog
- no
async_step_reconfigure
- no
async_remove_config_entry_device — the charge point device cannot be deleted and re-added either
What this looks like in practice
My charger was set up with only Energy.Active.Import.Register. I later wanted Power.Active.Import, Current.Import, Voltage, Current.Offered and Temperature as well. The entities for all of these already exist — the integration creates one per measurand in MEASURANDS regardless — they just stay unavailable forever because the charger is never asked to report them.
Setting MeterValuesSampledData directly on the charger with the ocpp.configure action does work, and the charger accepts all six. But it does not survive: on the next connection post_connect() → get_supported_measurands() pushes monitored_variables from the config entry back to the charger, which reverts the key to the single measurand. Verified across two Home Assistant restarts — the value was reset both times.
Worth noting the asymmetry: MeterValuesAlignedData is not touched by the integration, so setting that one via ocpp.configure does persist. Only the sampled list is overwritten.
Suggestion
Some supported way to edit monitored_variables for an existing charge point. Since it lives in entry.data rather than entry.options, a reconfigure flow may fit better than an options flow, but I do not want to guess at your preference.
Would you be open to a PR, and if so which shape would you prefer? I am happy to write it including tests and the en/de translations, but would rather agree on the direction first than send something you would want built differently.
Versions
ocpp v0.10.15- Home Assistant 2026.7.4
- OCPP 1.6-J charger, single connector
Summary
Once a charge point has been added, there is no supported way to change which measurands it reports. The selection UI exists but is only reachable while adding a charge point, and there is no options flow, no reconfigure flow, and no way to remove a charge point either — so the only route left is editing
.storage/core.config_entriesby hand with Home Assistant stopped.Why the existing paths do not work
async_step_measurandsis only called fromasync_step_cp_user, which starts with:so re-running the flow for a charger that is already configured aborts before it ever reaches the measurand selection.
Checked against current
main:async_get_options_flow/OptionsFlow— the integration has no options dialogasync_step_reconfigureasync_remove_config_entry_device— the charge point device cannot be deleted and re-added eitherWhat this looks like in practice
My charger was set up with only
Energy.Active.Import.Register. I later wantedPower.Active.Import,Current.Import,Voltage,Current.OfferedandTemperatureas well. The entities for all of these already exist — the integration creates one per measurand inMEASURANDSregardless — they just stayunavailableforever because the charger is never asked to report them.Setting
MeterValuesSampledDatadirectly on the charger with theocpp.configureaction does work, and the charger accepts all six. But it does not survive: on the next connectionpost_connect()→get_supported_measurands()pushesmonitored_variablesfrom the config entry back to the charger, which reverts the key to the single measurand. Verified across two Home Assistant restarts — the value was reset both times.Worth noting the asymmetry:
MeterValuesAlignedDatais not touched by the integration, so setting that one viaocpp.configuredoes persist. Only the sampled list is overwritten.Suggestion
Some supported way to edit
monitored_variablesfor an existing charge point. Since it lives inentry.datarather thanentry.options, a reconfigure flow may fit better than an options flow, but I do not want to guess at your preference.Would you be open to a PR, and if so which shape would you prefer? I am happy to write it including tests and the
en/detranslations, but would rather agree on the direction first than send something you would want built differently.Versions
ocppv0.10.15