SmartSolar 100/20 Load Disconnect Problem! Voltage Must Not Be Temperature Compensated!

DIY
, ,
1

Massive Bug / Development Fail in the SmartSolar 100/20
(I’m sure the same applies to the 75V versions too.)

Installed FW 1.64

Bought one a few days ago, set everything up (including the expert settings).
Using a maintenance-free lead-acid battery.

Now here’s the crazy part:

The thing did not turn off the load output at the configured voltage (user-defined algorithm 1)!

I tested it back and forth — for days! The whole damn thing!

Then I disabled the temperature compensation, and suddenly it started turning off the load output correctly.

Hello Victron, are you f. kidding me!?
That’s completely insane.
Voltage differences were up to 0.3V!

How is it justifiable that the Load Disconnect (LVD) voltage is affected by temperature compensation?
This is not only technically nonsensical, it actively interferes with reliable system behavior. Temperature compensation exists to adjust charging voltages – not discharge thresholds.

:cross_mark: This makes no sense
Load disconnect has nothing to do with charging characteristics.
Applying temperature offsets here causes random, unpredictable cutoff behavior.
It forces users to manually reverse-calculate their LVD settings depending on temperature – something that should never be necessary.

Real issue:
I set a disconnect at 12.40 V. At 30 °C, the system cuts off at ~12.20 V instead – and no part of the software explains this. How is it acceptable that I, as the user, had to spend hours testing and tracing this just to figure out that the damn firmware secretly manipulates the cutoff point?

What needs to happen:
Temperature compensation must be disabled for Load Disconnect/Load Reconnect.
Or at minimum: make this behavior optional.
Also: clearly display the effective compensated cutoff voltage in VictronConnect.

Furthermore, the app doesn’t even display the actual temperature from the unit’s internal temperature sensor!

This is basic expected transparency and system integrity. Spending hours reverse-engineering hidden firmware behavior is not how a critical safety feature should work.
Fix it.

Just to be clear – this Load Disconnect issue isn’t just a niche technical complaint.

There are multiple public reviews on Amazon and other platforms where users explicitly state:

“The load output doesn’t switch off when it should.”
“Device failed to protect battery – returned it.”

These are frustrated buyers who aren’t aware that temperature compensation silently shifts their cutoff thresholds, without any indication in the software.

The result:
People assume the unit is defective

They lose trust in the product

They return it – often writing negative reviews

All of this could be prevented with one checkbox in VictronConnect etc.

This issue directly affects customer satisfaction, reputation, and return rates.
It’s not just a firmware detail – it’s a real-world problem with visible consequences.

Fixing this is not optional – it’s damage control !!

And by the way:

The temperature effect on lead-acid battery discharge is being misapplied.
Higher temps → more capacity, lower internal resistance, voltage under load stays higher.
Lower temps → less capacity, higher resistance, voltage drops faster under load.

If load cutoff voltage is temperature-compensated, it must not use the same values as for charging, because the discharge behavior is much less sensitive to temperature.

Discharge voltage compensation for lead-acid batteries should be about one-third of the charging compensation, as temperature has a much smaller effect on discharge behavior !!!

The needed FIX for the whole mess:

:small_blue_diamond: Display Temp-Sensor readout of the Unit in the App

:small_blue_diamond: Use correct Temp compensation values for the load output (1/3!! see text above)
/ completly disable it for the load output. (what Victron is doin here is complete crap)

under the Load settings:

:small_blue_diamond: Option to enable / disable Temp compensation for the Load Output

:small_blue_diamond: Display the effective (temperature-adjusted) values

:small_blue_diamond: Or at least a warning/info message like:
“Note: Loadoutput values are temperature-compensated. Resulting current adjusted disconnect voltage: XX.XX V”

etc etc..

I’m so f… pissed! Who on the dev team is responsible for this coding? Who’s in charge of the manual and documentation? This is not how a professional company should operate!

So, Victron — what’s your plan to fix this issue?

For the people in here: If you’re not using the load output because you thought it was defective or unreliable — now you know what kind of weird crap is actually going on with the load outputs.

2

I can understand your frustration but first you should calm down a bit.
It helps no one if you rant here and insult the devs.

1 Like
4

I forwarded your complain/request to the devs.
It’s now on the to-do list to add a button to switch that behavior ON/OFF with it being ON as default to don’t mess with systems where it’s working how it is now.
But I can’t say when it will be implemented.

5

Hello Matthias,

big Thank You.

What i still dont get is that was coded this way and absolutely nowhere mentioned.
— out of laziness?
That’s completely incomprehensible.

Furthermore, it must be possible to deactivate this for all modes, including battery-life mode.

The temperature readout from the internal sensor should also be visible in the app please ,
so that proper shutdown behavior during charging — in relation to temperature compensation — can be verified and adjusted more precisely.

Please send this to the devs too.

I work in the tech field myself, and I just don’t understand how a manufacturer this size could simply sweep something like this under the rug.
Zero information in the app, nothing in the user manual.

Also, the compensation values — if they’re being used for the load output — are incorrect, as they are far too high. (As i wrote in the main post)

They should be, at most, one-third of the load compensation used during the charging process. (The final fix for this would be a change of the formula and a extra hint in the software after the next update)

Honestly, it’s unbelievable that something like this has happened — especially considering customer satisfaction.
I don’t even want to know how many returns there have already been because of this whole issue. It’s just bizarre.

So needed stuff for a full fix of the issue would be:

  • Show temp units and temp sensor value in the app

  • Enable/disable temp comp for whole load output incl. battery saver mode

  • (Additionally, the final fix for the values if enabled would be:
    Correct temp comp value for load output to, e.g., 1/3 and include notice @ load output selection tab in the app, that from now on, 1/3 value is used if temp compensation is enabled for the load output.)

I sincerely hope the developers fully recognize the significant frustration this issue has caused for many customers and this gets fixed immediately, something like this is truly unbelievable.

Such circumstances are undoubtedly detrimental to both the company’s business and its reputation.

:folded_hands:

6

found out another weird stuff.

same problematic @ the re-bulk voltage offset @ the charging expert setting.

guys thats nuts, whats goin on here? i dont get it.
what is this coding? only explanation is laziness.

i invite every resp. victron coder / staff member in here to explain it, cuz there is no technical explanation for it.

should be fixed too!!!
(eg also with → enable / disable temp comp for re-bulk…)

/general disable temp comp for everything else other than the real chargin… to get rid of the whole mess / “bug” /“feature^^”.

7

If battery voltage at equilibrium is temperature dependant, then, at first glance, all associated parameters in regulation should also behave like this. It may be more tricky for dynamic cut off, as kinetic aspects, that are also temperature dependant, are involved. Is temperature compensation correctly implemented in Victron products?

8

Your feedback is appreciated but please stop ranting and insulting.

The devs are aware of the issue and working on it.

9

Matthias, I’m more than calm in my wording now.
The thing is, from a technical point of view, what happened is nuts — there’s no way around it or any way to downplay it.

I buy from a market leader to be on the safe side — not to beta test products and now its clear this is`nt just a bug it was coded this way.

Also, let’s look at it from another perspective:
You’re a technical engineer yourself and you buy a product from the so-called market leader,
at a premium price — and then, after installing the unit, it doesn’t work as it should.
The manual doesn’t mention what it actually does, and you think the unit is defective.

You start searching online, find others with the same problems, see very negative Amazon reviews — but you don’t give up.
You start testing the unit for days: charging the battery, enabling setting X, disabling setting Y, repeating it all over days — and over time, you start figuring out whats really goin on yourself.

Then you think: “Okay" Problem found — reported - let’s hope for a quick fix.”

Two days later, you discover the next weird issue that makes no sense (and also can kill people’s batteries faster).

I think its not so funny to spend €300 or more on 250–300Ah batteries — and then find out things like this.

This all should never have been implemented that way in the first place — (esp. with zero documentation) — and I think you know that too.

I really hope for a fast fix.

10

Indeed…

If load disconnect is designed to be triggered by a certain set voltage, then that voltage must be used.
That voltage should not be temperature compensated, because that voltage is the desire of the user.

But …

If load disconnect would have been based on a SOC value entered by the user, then, if the battery SOC would have been computed from the voltage, then the temperature compensation should have been used for the battery voltage, in order to properly compute an approximate SOC.

Probably something like that was in the mind of the programmer…

11

Regarding the SOC thing — that’s not happening.
Also, see my newer comment above about the re-bulk offset.
The whole system just generally shifts voltage based on the temperature compensation setting — which makes no sense.

12

Sorry, English is not my native language, so maybe tense conjugation was not ideal…
I didn’t say that this is the status quo, I just tried to find an explanation.
To err is human, to forgive is divine… :wink:

13

no prob mate, allready got it.

i dont think something like what you wrote was on the mind of the coder(s)

the whole issue looks like a (okay fugg eet) dont wanna code this now… skipped.

cuz the re-bulk offset does the same stuff = the whole relevant code and documentation is missing.

anyway. hope w`ll see a fix soon.