When using setpoint and min/max value, which works perfectly, there is a small bug with heating icon, which still counts 0-100 as min max and therefor when using it as temperature it’s always in blue part of the icon 
Setpoint item=manualHeatingTemp label="Manual Temperature [%.1f °C]" minValue=15 maxValue=25 step=0.5
looks like
but icon should look more like this because 25 is max defined range (manually set to 100)
not a bigge, but if it can be fixed, would be nice
File an Issue in GitHub to get it noticed.
The example given can be covered by creating your own set of icons like icon-0 icon-10, … icon-25
openHAB can’t guess where you want the thresholds etc.
OH knows exactly where my threshold is by this
minValue=15 maxValue=25 step=0.5
when controls are able to follow this limit, there should be possible to recalculate 0-100 to display icon properly.
I don’t think it’s very good idea to redo icons everytime you reconfigure or add new min/max setpoint item somewhere.
This should apply to dimmers as well, if min/max dimmer is 5 - 30 where 30 is 100% dimmer slider should follow this logic as well as icon behind it.
but again, not a biggie
No it doesn’t. How many icons would you like to span that range? Six? Ten? Would you like a special Icon to show if the state is set exactly at max? or min? Or within say 2 points? An extra icon to show if the state is above the widget range?
There is the flexibility in the existing scheme to do all that. It does have the limitations that it won’t deal with negative numbers, or allow fractional number thresholds (22.5) or numbers over 100.
There’s a presumption in your idea that OH knows (or can find out) what range you have selected for your widget. That may be possible to do for sitemap based UI’s, but not really for other UIs like HABpanel.
A change in icon behaviour would represent a breaking change for existing dynamic icon users, and require rework of all UIs as well as openHAB icon server.
It’ll be a difficult sell 
Now would be the time to come up with a new scheme, before OH3 starts to take firmer shape.
“Manually” copying / renaming icon files isn’t that difficult. It is tedious. Maybe an organizer tool of some kind would help, a VSCode extension perhaps.
Please be aware that maxValue and minValue are only settings for this single Widget, not the Item nor it’s status.
might be, but then as well visualization of this widged should be in harmony with setting. And icon is widget representation at the end.
When controls are working as we are expecting, so they are adjusted by OH knowing min/max so it’s visualisation should be.
Otherwise it’s just seems to be not synchronized of what it is doing and what it is displaying
just my opinion
that’s absolutely not necessary and you know it.
All what should be expected is to work with same images, but recalculated minmax so 0 = minvalue, 100 = maxvalue, divided by how many pictures this icon already have (which is already there and working for 0-100)
I mean, I’m pretty sure you understands it well but just trying to complicate it so it looks like not needed 
thing is, it’s not change of icon behaviour at all. Just recalculate it’s position with different values than 0-100
I understand what you want, and it is attractive. There are “buts”.
What you want to do would limit what other people can do.
It is of course possible to add some control to select behaviour “old” or “new”.
That’s the thing, it is a change.
Example iconset
thermo.svg (blue)
thermo-10.svg (green)
thermo.svg-20 (red)
Setpoint widget range -5 to 25 step 1
Existing behaviour, with an Item state of 5 I get blue icon. state of 15, green, state of 32 (the Item can get data from other sources than this widget) red icon.
With an auto-base-100 selection, I get 5 blue, 15 blue, 32 blue , because the thermo-10 icon is the new “auto” midpoint. Or is the one-third point?
Of course that could be fixed by changing the icons to suit the new scheme, but that’s a breaking change for existing users. (and the whole point of the scheme was to avoid changing icons?)
Elsewhere in my sitemap, on a different sub-page, I present the same Item as a Text widget with no control, of course that works with current icons. I’m not sure what would happen under “auto” scheme?
How about if I had a Switch type widget with buttons to select preset setpoints - how would that work?
Make no mistake - I think the current icon selection scheme is clonky and nasty. That isn’t that surprising when it works with sitemap files that are also clonky. The whole UI is lacking refinements, not just this area.
Let me make an alternative suggestion - forget the widget.
Think about specifying the “range” of an icon set exactly where it has effect - where you specify the icon. e.g. at the Item <icon> definition, or if overriding with sitemap, in the sitemap icon= definition.
Part of any enhancement in this area should be to add capability to deal with negative and >100 numeric Item states.
Let’s imagine something like
<iconname [-10 to 255]>
and the icon provider at the OH end can find the set of six or ten icons - we should perhaps need a standardized 0-100 range for those - and scale them accordingly to fit when requested.
The widget you choose is irrelevant, the scheme still works with non-sitemap UIs.
That still has limitations, but you do keep the choice of “old/direct” or “auto” behaviour which does allow flexibility for many cases.
valid points indeed, I’m not familiar how it’s working under the hood, but I imagine something like it’s selecting icons when in given interval 0-100
eg. 10 > x < 20 display icon 15
right?
if so, there is possibility to recalculate and adjust interval as well
-10 to 255 means 0 - 100 = 265 steps which means 2.6 units per 1 “normal unit”
remaping 2.6 to 1 internally to display correct icon shouldn’t be big deal imho
then you can from there work with 0 - 100 icons as usual
same applies to 15 - 25 step 0.5 etc.
only difference will be that those interval will be shorter eg. some icons will not be used as it will simply fall into next interval with only one step.
If it’s done differently under the hood, then indeed there might be some hiccups, but my imagination is telling me that this is sort of approach which should not be that hard to follow and it will not break anything for “current” sitemaps
Yes, it simply selects “equal or next lowest”, with a fail to the default unnumbered icon - which it is mandatory to provide in a set (think Item NULL state).
icon-0.svg is different to icon.svg.
Number Item states -10 or 255 are currently “fails”.
EDIT - actually, that’s a NO it selects equal or next lowest. Not nearest. 10>15 displays icon-5 or icon-10 or just icon, depending what exists. 15>20 displays icon-15.
Any proposal should not interfere with string states working e.g. myicon-on.svg , someicon-alarm.svg
I am unsure of the exact mechanism. There is an icon provider service, so far as I know the UI sends root icon filename and Item state as a parameter to be worked out at OH host, which serves the image.
and that’s exactly what i’m suggesting.
just remap new interval to 0 - 100 and then maintain current logic
Here describes what the UIs do in a request.
https://www.eclipse.org/smarthome/documentation/features/icons.html#icon-servlet
So far as I can see, the icon provider could be enhanced with (optional) “auto scaling” without breaking the existing UI or existing sitemaps.
It would require the addition of (optional) parameters to Item definition mechanisms,.which I suppose involves REST API as well as xxx.items file parser and PaperUI.
If it were wanted to also allow the scaling option with icons defined in sitemaps, that would require changes to sitemap using UIs (openHAB core doesn’t know which sitemap you are looking at, I think) and I suppose to the request to let the icon provider know the extra requirement.
The icon provider itself was Smarthome, but I understand it is now fork-able for openHAB?