All assistants seem to use the 0.5 fraction whatever is set, Is this a normal thing in coding or mathematical logic?
It’s annoying when setting assistants:
For instance: If I set an assistant to use ACout2 for a hot water diversion load when SOC is higher than >99% (You can’t set 100% as you can’t go higher than 100%) then the assistant will actually trigger at 99.5%. - So I will never be able to balance LFP in that 99.5-100% region.
If I wanted it to actually trigger at 99.5, why cant I select that 0.5 in the assistant? - I.E. the GUI is written in integers but the logic / coding isn’t.
Also when the remote console is showing a SOC percentage, say 50% to 51% I would expect that to be true integers, but Victron will call 49.5% to 50.4% = 50%
Why?
50 = 50 to 50.9 surely, all the decimals belonging to 50 are 50!?
I would much prefer to use integers, or if not, to have granular control of the decimal for assistants so they at least trigger all the way to 100% SOC.
I realise a change now will affect many peoples own assistants and maybe Node Red flows, but unless there’s some important reason I’ve missed I think it makes sense and would give better control.
Yeah rounding is useful sometimes, like when I’m rounding down the cost of my share of a meal with friends ; ) but there’s no point in this ‘rounding’ peculiarity to the 0.5 decimal. That’s just the half way point between two whole integer numbers whereas the GUI / Assistants only display or give options for whole numbers / integers anyway. It would be more logical to use either one or the other, not both.
Mixing up two different methods doesn’t work for accurate assistants or expected logic, we can’t use 100% for anything only 95.5%, we can’t even use an actual specific 50% we only get 49.5% and 50.5%, but that’s not what the GUI is showing us, we see 50%, there’s just no need or benefit to this ‘rounding’ only downsides that I can see.
Am I missing something, is this expected logic across software / hardware systems then? I don’t recall coming across this before?
“consumed Ah” isn’t an option available with assistants.
Sure I could use Node Red, and then there are many more options, but I can’t yet on the Cerbo for my personal system as it’s already overloaded, and I assume there are more general users of VenusOS seeing the strange rounding and using assistants to quickly put systems together than there are Node Red users.
If this rounding is too far embedded in the system for whatever obscure reason having decimal control for end users / installers to partially get around it would be a great upgrade to assistant functionality, especially whilst there’s still no simple option for off grid hot water diversion.
In the Victron case isn’t this RND function just a solution to a problem that doesn’t exist, which then causes more problems? - Why round to 5 decimal places either site of a whole number, when there are already 10 decimal places between each number as we can see in the GUI, and we only have options for adjusting anything by whole numbers.
The reality is: If I buy 2 beers in Victron’s bar I will only get 1.5 beers as the whole number 2 is always rounded down to 1.5 or maybe 2.5 beers if the barman over fills slightly, but I just can’t get 2 beers when I ask for them, even though I expect to get two, the bar menu says I can buy 2, but the beer machine can only dispense beers rounded..
If I drive 95.5Km/h in a 100Km/h zone am I hitting the limit?
If we want to meet for lunch at 12.30pm will you arrive at 12pm?
If I wanted to fly the 158.35Km to Mars, you can be sure I will not round my calculations up to 158.40Km to decide when to fire the rockets to slow down and enter Mars orbit.
“2 (real) ofc remains 2(int)” - OK, lets say we have those 2 beers on the table, but I can’t actually take away 2 beers, the rounding code law only allows me to do anything if I spill them down to 1.5 beers or the rain fills the glasses up to 2.5 beers then I can legally take them away and drink them.
The trigger points for the GUI and Assistants are rounded, but that means they happen either side of the integer leaving a gap at both ends of the scale, and absolute numbers can’t be used to trigger anything.
I don’t see the point of this rounding, absolute numbers with decimals is more accurate. We’re not even trying to round multiple complex equations and yet we still have this rounding error.
I can see this as a reason why so many people over the years have got confused why assistants don’t act as they expect.
I don’t remember ever seeing any documentation mention that due to rounding, assistants won’t trigger on the whole number, or for instance that relays based on SOC will not be based on the absolute whole number. - This would be useful.
I can imagine it’s maybe hard baked into the code now, and would be difficult to change, but It’s something I’ve been contemplating for a while, as it has always bugged my desire for simple accuracy.
Considering that SOC is a derived metric, the calculation thereof has a far greater inaccuracy than the 0.5% you are concerned about.
Any LFP battery is balancing well below that threshold, and, unless there is large drift, it is as close to charged as you can get.
You could also choose to trigger on battery voltage instead.
The hardware/firmware in the inverters have some limitations and every use case can’t be catered for.
This isn’t really something we can escalate, being a niche problem.
If I want to be sure that 100% SoC ist not 99.9%, I set “charge efficiency” 2% lower, then at 98..99% SoC will directly jump to 100%, calculation undershoots, voltage and tail current are reached.
But I guess that’s too high for an Artificial Intelligence
