I don’t really understand the value of allowing non integer steps on the slider if as @Dmitriy says param.asInt(); still returns an integer value.
Is a param.asFloat(); function in the pipeline to allow these values to be used in code?
Pete.
Now you can get a float value from the slider. I don’t know for the ESP library the command because I use JS.
But since the value is sent as string, you can interpret the value as you wish 
Yes. It is there since begining.
1 Like
I would appreciate if the slider doesn’t show decimal.
Today I reviewed my code because I thought it was due to a change by myself. For my project the slider is unusable now. I change values between 50 and 70 and can’t mange to have for example exactly 55.
For me having the slider function with Integers as it did before is desirable. I am all for additional functionality but I am not in favor of new functionality that is different than before.
It should have an option for number of decimal points with zero forcing it to integer as we expected.
Now i have to teach my AC units to take 23.47 as set temperature. And teach myself to precision finger sliding. Until then, this is a breaking change and a show stopper for me. Min, max and step increment value are properties found in most sliders. Such change shouldn’t be done without this adition and cruical default behaviours should not change either. I can not change the code on my controllers in all places. So… is this just a toy?
Are the older versions of the APKs accessible anywhere so we can roll back for now?
This I agree. It should have been back compatible, either by adding a different “float slider” widget or by having an option to pick int-float and by default on int so that all previous code didn’t break.
Premium rate float slider for the few that want it and cause increased stress on the server, now that is a good idea @tulo
Where is the increased stress of a float slider? Sending 1000 in a int slider adds more stress than sending 0.01
Every value is a string, so the longer the worst.
Odd behaviour from sliders.
param.asInt(); no longer returns an integer. Why is this? If I wanted the slider to return a float I would use param.asFloat(); but I don’t want a float so how do I get the slider to return an integer as it was before this latest update?
I don’t understand all the hubbub… Slider value options work perfectly for my tests and all my pre-existing projects still work the same way…
BLYNK_WRITE(V0) {
Blynk.virtualWrite(V1, param.asInt());
Blynk.virtualWrite(V2, param.asFloat());
}
You do have to have a very low range (<10) to take advantage of the float precision. Perhaps a bit better with the slider in vertical… assuming the increased length isn’t just visual.
1 v 1.00
2 v 2.00
3 v 3.00
etc
or for your
1 v 1.00000
2 v 2.00000
3 v 3.00000
Why? 1 can be sent as “1” also for float 
Sending 1023 as integer is the same as 0.001 float.
I can agree with you only if someone makes a statistic saying that small integers (1-10) are used more than long integers (1000+). And btw I don’t think the server overload is the motivation for the 2 digits resolution.
I would have thought that was obvious.
I believe @tulo will be using a range like 0 to 0.09 to use 2dp or 0 to 0.00009 if 5dp were made available.
Setting the slider range 0-1 will give 0.01 decimal control (if you are very careful)… but at what advantage over a range of 0-1000 and mapping the number down?
I forgot to mention, you can simply hold the step button down and it will advance at the set Write Interval rate (plus any active processing of code)