[Bug]: I don't see MPPT PV current.

[brianbodholdt-cloud]

I have read the documentation

• I have read the documentation and understand the setup process.

Describe the bug

I don't see MPPT PV current. PV power and voltage are there as well as battery current.
Am I missing something or is it intended.

Steps to reproduce

Go to device and entity.

Expected behavior

No response

Environment

No response

Additional context

No response

[tomer-w]

Based on the doc, the /Pv/x/I topics are deprecated.

[Zaraxxx]

Hi @brianbodholdt-cloud, while waiting for a potential native solution, you can build per-tracker PV current entities yourself with the data the integration already exposes. The trick: /Pv/x/I is deprecated upstream, but per-tracker power and voltage are published:

• sensor.*_solarcharger_NNN_solarcharger_tracker_0_power (W)
• sensor.*_solarcharger_NNN_solarcharger_tracker_0_voltage (V)

(and tracker_1_* for the second string)

So I = P / V is just a template helper. In Settings > Devices and services > Helpers > Add helper > Template > Template a sensor:

{% set p = states('sensor.victron_mqtt_solarcharger_278_solarcharger_tracker_0_power') | float(0) %}
{% set v = states('sensor.victron_mqtt_solarcharger_278_solarcharger_tracker_0_voltage') | float(0) %}
{{ (p / v) | round(2) if v > 0 else 0 }}

Set unit to A, device class to current, state class to measurement. Duplicate for tracker_1 and you get PV1 / PV2 current matching what VictronConnect shows. Working great on my setup since May.

The system-level PV current is also already exposed as sensor.*_system_0_system_dc_pv_current (computed by the GX, total across all MPPTs), if that is what you needed instead.

@tomer-w, since the underlying data (per-tracker power and voltage) is already in the library, would it make sense to expose a computed solarcharger_tracker_X_current directly in the integration? No new MQTT topic needed, just a derived value. Would save users from rebuilding the helper, and it lines up nicely with what VictronConnect shows per string. Totally understand if it is low priority, just thought it might be a quick win. Thanks again for all the work on this.

[tomer-w]

The library is fully capable to derive computed values based on other topics. We already use it few places and it will be super easy to add.
The reason I didn't suggest it is that if Victron deprecated their own computation I assumed it is not accurate or is misleading users in some way. Therefore I didn't want to do the same.
@ThiemoVanEngelen, what was the reason the published value got deprecated to begin with?

[ThiemoVanEngelen]

The value was deprecated to limit the amount of dbus traffic. On older systems, the amount of dbus traffic would cause significant CPU usage. As the value can also be calculated from /Yield/Power and /Pv/V (or /Pv/x/P and /Pv/x/V for multi tracker devices), the value was no longer placed on the dbus but calculated in the GUI.

[tomer-w]

Cool. If there is no accuracy problem with exposing this calculation, I will expose it from the library based on the formula metric support.

[tomer-w]

Added in v2026.5.9. let me know if this solved it.

[tomer-w]

@brianbodholdt-cloud , didn't hear back so I'm closing for now.