and slightly off wording choice. Quite some time ago, I could not get ANY sensible
results from custom widgets, so I forgot about the feature. Having been pointed
to it again and I got immediately what I needed, I thought I give it more attention.
This is a custom widget I could live with:
The devs might want to replace the word “should” with “must” - or even better yet, assume the user knows what he wants and let him - see preview.
Because after VRM decides that your choice of y-axes is bad and its own is probably better, when looking at the widget in VRM, it shows these “beautiful” y-axes:
and that’s something I really don’t want to have to look at. Why did I try custom y-axes at all? Because the autoscaling does not recognize values that should be treated equally:
You wonder how a 120W PV power output could be only slightly higher than a 40W power output unless you see the widget scaled them differently.
Maybe even the option for the default scaling (most of the time it does get things right) to lock in values with other values? That way I could configure it to lock in scaling of voltages together and that of power outputs and let it do the rest. Could be fine.
It s the 42 that the issue on your y axis shoice so just use 21?
You don’t even need to use the same scaling for all data sets.
I do agree though i would like to be able to group datasets with the same scale and range.
The issue is not just the 42, but also the 200. This was my attempt to give both “10 steps” on the y axis. The real underlying issue I have with the scaling is that this “window of interest”:
got mangled into what I show in the last screenshot in my OP. I would have expected and liked if the zoom didn’t rescale, nota bene all of the values with their own individual scale.
As is, zooming doesn’t really clarify such windows of interest.
Intervals means how many bars you want, not the numerical value between bars. So scaled 0 to 240 with 10 intervals will give 0, 24, 48 etc scaled 0 to 240 with 12 intervals will be 0, 20, 40 etc.
Oh - right. So it’s not “Intervals”, but “Number of Intervals” or “#Intervals”.
Now it starts to look sensible. Thanks. Possibility of renaming of the parameters would
be most welcome, but I guess that’s for another request.
You know: “East-Middle (V)” instead of “MultiRS - PV Voltage Tracker 1 (V)”
I do not need the "MultiRS - " prefix to each parameter, I named the widget already.
I need human readable assignments to the strings not something one needs a translation table again.
No, the inherent definition of interval is the size of the interval.
So “y-axis intervals”, is to be interpreted as “What size shall your intervals have”, NOT
“how many intervals do you want”.
Of course you get struck by that non-ambiguity only with the appropriate education.
Never mind, now I know what the Victron devs meant - not what is usually meant.
(Interval (mathematics) - Wikipedia)
How is renaming the value shown a language issue? I’m renaming it for myself,
so even if I wanted it to be in كِسوَحِيلِ, only thing Victron devs need to make sure is proper support of UTF-8 or somesuch.
With the cross of professionals and diyers there has to be some kind of meeting in the middle.
While a graph is mathematical essentially, it is for information display which in this application is not mathematics.
Graphana now is more suitable for the number of data points you had wanted to show there.
For the most part users understand it to meant make your own intervals… Almost all users we have encountered so far have understood it that way. Remember not (i will go as far to say most) every user is technical.
