We run a Multi RS Solar with two trackers on one unit (7 panels north-facing, permanently partially shaded by a roof dormer and an offset neighbouring terraced house, fitted with BRC optimizers; 5 panels south-facing, unshaded) plus two identical reference strings on two further Multi RS units on the same roof.
Over several weeks we’ve been running a structured comparison: partial shading detection On vs. Off, each measured against the unshaded reference strings at the same time of day (as a proxy for actual irradiance). Results so far are mixed — some days “Off” performs better, some days “On” does, with day-to-day swings of up to ~17% in the ratio.
Two practical points from this:
No per-tracker setting: On a unit with two trackers (our case: one heavily shaded, one not), partial shading detection can only be toggled for both trackers together, not individually. Given that scans are already interleaved per the manual (not simultaneous), the device logic already “knows” which tracker is being scanned at any moment — a per-tracker toggle seems technically feasible.
Optimizers under structural, permanent shading: We agree that for normal, occasional partial shading (passing clouds) optimizers are unnecessary and Victron’s own algorithm should suffice. But for permanent, structurally caused shading of part of a string (in our case a dormer and an offset neighbouring building, constant year-round) we do see a case for module-level optimizers — the issue is that this combination (BRC optimizers + Victron’s own shading detection) isn’t officially supported, and the two systems may work against rather than with each other.
Are there any plans to either (a) make partial shading detection configurable per tracker rather than per unit, or (b) provide an official position/recommendation on interoperability with module-level optimizers specifically for structural (not just transient) shading?
Yes, we’re aware of that section — that’s exactly why we ran a structured comparison rather than just assuming either way.
One distinction worth making though: the Multi RS (and SmartSolar RS) don’t run the same MPPT logic as the classic Blue/SmartSolar chargers that section 6.8.6 was presumably written for. Since firmware v1.16, the RS series does a periodic full I-V scan every 5 minutes to locate the global MPP, rather than just hill-climbing to the nearest local one — so it’s already closer to a real tracker than the older single-point MPPT chargers. It’s just not yet at the level of SMA/Fronius-style true global MLPE-aware tracking. That’s a gap we’d genuinely like to see Victron close on the new RS-series products, rather than the “don’t use optimizers” guidance simply being carried forward unchanged from the older charger manuals.
Our test setup: two 4-module strings on the same Multi RS, same roof, same conditions — one fitted with BRC optimizers, one without — both measured against unshaded reference strings on separate units as an irradiance baseline.
Result: with the Multi RS’s own partial shading detection switched off, the optimizer string generally outperformed the non-optimizer string. With partial shading detection switched on, the optimizer string performed worse — the two systems appear to actively work against each other rather than complementing one another, presumably because the built-in scan and the optimizer’s own tracking are both trying to hunt the MPP on the same string independently.
So our takeaway isn’t “ignore the manual and use optimizers anyway” — it’s that the interaction between the RS series’ scan-based shading detection and module-level optimizers specifically needs attention. Simply disabling one side of it (which is what we do now — partial shading detection off) gives noticeably better results than running the “as documented” combination with both active.
One more point worth raising separately, since it’s a distinct request from the optimizer discussion above:
Our Multi RS has two trackers on one unit — one heavily and permanently shaded (roof dormer + an offset neighbouring building), one completely unshaded. Partial shading detection can currently only be toggled for both trackers together, not individually.
Given that scans are already interleaved per-tracker (not simultaneous, per the manual), the device logic already distinguishes between the two trackers at the scan level — so a per-tracker on/off toggle seems like it would be a relatively small addition on top of what’s already there, rather than a new architectural feature.
In our case this matters because the two trackers have fundamentally different needs: the shaded one plausibly benefits from the scan, the unshaded one just pays the small cost of the periodic 5-second scan for zero benefit. Right now we have to compromise across both.
Would be curious whether this has come up before as a feature request, or whether there’s a technical reason (shared scan timing/logic between trackers on the same unit) that rules it out.
The whole point is that optimisers cause a conflict, and not just with enhanced features of the RS. It is included in the RS manual for a reason, not purely a result of cut and paste. They do actively work against each other.
It shouldn’t be a surprise that two optimisations are not working together.
Victron explicitly do not support them at all so there is next to no chance of trying to optimise any device or capability to accommodate them or any other unsupported configuration.
The “Partial shading detection” option will trigger a full rescan of the IV curve at 5 minutes. That’s all.
Probably the optimizer(s) doesn’t like this.
Therefore not checking that option will be better in your case, where the Multi RS algo just try to “hover” around the already “decided” max point.
Nice idea that individual selection of partial shading as per your usage case. Max flexibility in this situation.
Yep…
Not to mention an anomaly with these MPPTs…
When there is a partial need for production - so they function in limited current mode - they still do a scan from time to time when this is really not needed as the request for power is fixed and already at that point.
They’ve also used to do the full scan when the MPPTs were at max power production - but they corrected it, but the scan on limited mode is still there.
In other words…
When you need 1kW and the MPPT produces 1kW, there is no need for scanning for another MPP as you already producing what’s needed.
When the MPPT produces 3kW, which is the maximum, why scanning for another MPP, when it can’t produce more?
The last one is corrected, but first one, no.
Thanks for the replies. I’m aware optimizers aren’t officially supported on Victron chargers — that was never in question. Still, a few thoughts on why I think this is worth Victron taking another look at:
1. Market share: Customers with difficult roofs (dormers, offset neighbouring buildings, changing shading from extensions, etc.) either can’t use a Victron system at all with this stance, or have to run an external inverter (e.g. Fronius, which has no issues with BRC optimizers) on the AC-Out and leave the Multi’s own built-in tracker unused. BRC optimizers (and pretty much every other module-level optimizer manufacturer) work fine with nearly any other inverter brand — just not with Victron. That seems worth the Victron team taking a closer look at.
(Attached is a photo of an example roof with this kind of geometry — East-North-East orientation, partially obstructed by roof/building structure.)
2. Victron’s own shading management isn’t exactly uncontroversial either — separate from the optimizer question:
Before the v1.16 improvement, there were several reports of weak shadow management in the old Victron community archive (“MPPT RS 450 shadow management?”, “MPPT 450/200 – Poor Shadow Management?”)
The official v1.16 announcement (“RS series v1.16 – improved MPPT shading performance”) indirectly confirms there was room for improvement beforehand, and the associated beta test threads (“RS shade performance testing – v1.16-beta-02” and “-beta-05”) show the community was actively involved in evaluating the new performance
In this very Partial Shading Detection thread, @nesswill notes wanting to test the “Advanced Maximum Power Point Detection” marketing claim himself but not yet having had the right weather conditions to do so — showing the effectiveness hasn’t been conclusively verified even within the community
On the Akkudoktor forum, it’s quoted that Victron itself acknowledges the algorithm doesn’t show its strengths (only) under (partial) shading of modules/strings, but rather under changing light conditions — i.e. cloud cover changes — a different use case from our permanent, structurally-caused shading
So my point isn’t “ignore the manual” — it’s that for use cases like ours (permanent, structural partial shading of part of a string, not just changing cloud cover), neither the built-in solution nor a blanket rejection of optimizers seems like the best answer. A look at how other manufacturers solve this (global tracking like SMA/Fronius, or official optimizer support) would be welcome from a user’s perspective — especially since the RS series is already technically closer to a real solution than the older chargers.
Specifically, for the RS series, I’d like to see:
The two trackers individually switchable for shading management
An option or toggle to a supplementary algorithm that does global tracking specifically to support BRC optimizers — per tracker
I’d be happy to help test this — I run two strings (installations) with BRC optimizers.
Victron took the easiest and quickest route to this.
You can’t miss an/the MPP if you do a full sweep.
I’ve seen real cutting edge algorithms that combine the standard MPP algos with learning capabilities.
They can be set in “learning mode” and over 2-3 weeks they learn which are the maximum points during the whole day and then, they always produce the maximum energy and quite efficiently.
For an ESS this is gold and you don’t need additional optimizers…
That’s the stronger argument, and it’s independent of how sophisticated the sweep algorithm is (periodic or learning-based).
In a series string, current is shared across all modules. A shaded module can only supply less current than its unshaded neighbours at any given voltage, so there are really only two outcomes:
Bypass diode active: the shaded module is skipped entirely — contributes zero, but the rest of the string keeps its full current
Bypass diode inactive: the whole string gets pulled down to the shaded module’s low current — even the fully-lit modules lose output
A string-level MPPT — however smart the search algorithm is — only has one degree of freedom (one voltage/current pair) for the entire string, and can only pick between the handful of discrete local maxima these bypass-diode states create. A learning mode would help find the best of those available points faster and more efficiently, but it can’t remove the constraint imposed by the series topology itself — that’s structural, not algorithmic.
A module-level optimizer decouples this: each module gets converted at its own optimum, so a shaded module contributes what it can actually produce instead of either being bypassed entirely or dragging the rest of the string down with it.
So to summarize where this leaves us: a learning-based MPPT (as discussed above) would address the repeated-sweep energy cost, but not this string-topology limitation — for permanently, structurally shaded strings specifically, that seems like a genuine case for module-level optimizers regardless of how the MPPT search itself is implemented.
