Slider change?

I have horizontal sliders with ranger 0 to 1, to emulate the horizontal sliders in the settings menus. They now get stuck in intermediate states. :slight_smile:

@omegab sorry I don’t understand.

You were using a slider with expected values of 0 and 1.
New app still provides 0 and 1.
Were you not using param.asInt() before?

Same problem as omegab notwithstanding the use of param.asint().

I replaced the sliders in my project with “menus”. Not as user friendly but I needed a solution pending the resolution of the slider issue.

Can someone provide a code snippet that now fails.

1 Like

Probably need to show an operational issue first, one that is not simply a visual floating point number shown on the slider widget. I have already tested and confirmed there is no operational change in the integer output value with a range of 0-4 (or any range).

When @Dmitriy said:

It didn’t really register with me that this would include button widgets, but it seems that this is the case and is causing a few issues for Node-Red users:

It’s easy enough to work around, but a bit of an inconvenience. I don’t know if the issue of a button widget not accepting 0.0 as an Off command is a peculiarity of the Node-Red implementation, or a bug in the latest Android release. I don’t have an Android device to test this on, but if passing a float value of 0.0 to a button widget from code doesn’t turn it off then it may catch some non Node-Red users out.

I’m still not clear why a switch widget with a binary state need the ability to use floats though!

Pete.

2 Likes

Thank you all for feedback. We will introduce additional settings to the slider that will allow set the slider step precision so this will make the slider to work as before. Sorry for any inconveniences.

6 Likes

@Dmitriy that’s fantastic! I am extremely glad I switched all my iot stuff to Blynk.

With increased resolution also? :slight_smile:

Great thank you!

Hi @Dmitriy.

Just a bit more on my post. From a UI point of view the upgrade to the slider now makes it very difficult to get the exact value one requires. A resolution of 0.01 is too much for my finger to control. I know my code and device will be converting to an integer and using an integer but the app will display the closest value I can get with my finger on the slider to a resolution of 0.01. It’s a bit messy and the change is a bit of a surprise.

Now that we can have a float could you please consider adding another attribute to the slider configuration which will allow the specification of an increment and a display resolution. For instance if I specify 0.5 then the increment will be 0.5 with a display resolution of 1 decimal place. If I specify 1 then the increment will be 1 with no decimal places displayed.

My preference is to use the slider rather than the stepper because cosmetically I like the slider better as I explained previously. That is my personal preference and opinion.

I would welcome the thoughts of other users of the slider.

Thanks.

There’s already another thread on the changes to the slider (and other widgets) that happened in this latest Android release. I don’t think we need another debate on this issue. The important outcome of that thread was this:

Pete.

Well, @Dmitriy said there are ‘fixes’ coming… so this may be a mute point :stuck_out_tongue:

Despite @Costas multiple requests, no one has provided actual code that showed issues with the normal param.asInt() commands with the “new” slider. So basically it seems to be an issue of perception.

As I have tested and explained to another user… nothing really changed as far as the operational use of the slider was concerned.

For example, if you had a range of 0-4, then you still needed to move the slider far enough for it to transition between 0 and 1, then on to 2, etc… the only new difference was now the float value and the little number at the top of the slider recognised these minuit changes in-between the integers.

So as far as I could tell, between testing and with all the sliders in my various projects, nether the distance needed to move the slider, nor the actual integer values changed from their usual functions… so why so many “issues” is a mystery to me :thinking:

I didn’t catch this until after my post :blush: But you are correct… so I moved this all over to the topic in question.

1 Like

@Gunner the last slider update broke Node-red implementation.

Yay, I caught that later :blush: I have never used Node-red, so don’t understand how or why… but thankfully Dmitriy does :stuck_out_tongue: Still doesn’t explain the “issues” with normal Blynk App use.

Well, after all my testing and having no issues… it had to happen… I finally found a slider issue of my own :smile:

NodeJS doesn’t like the strange values it is getting from a slider. Since it is using pigpio and not the traditional param.asInt() I don’t know how to work around it… yet :wink: … but just a heads up for @Dmitriy, it is not just a Node-red issue, but also NodeJS and/or pigpio issue.

const Gpio = require('pigpio').Gpio;
const PhysicalWhiteLED = new Gpio(18, {mode: Gpio.OUTPUT});

var WhiteLEDslider = new blynk.VirtualPin(0);  // Slider Widget on V0 for Pysical White LED intensity
var WhiteLEDintensity;

// Vary the intensity of White LED
WhiteLEDslider.on('write', function(WhiteLEDintensity) {  // Watches for V0 Slider
PhysicalWhiteLED.pwmWrite(WhiteLEDintensity);  // Sends PWM value to Physical LED (GPIO18)
});
Error: EINVAL, Invalid argument
    at Error (native)
    at Gpio.pwmWrite (/home/pi/Blynk-Test/node_modules/pigpio/pigpio.js:86:10)
    at .<anonymous> (/home/pi/Blynk-Test/index.js:92:18)
    at emitOne (events.js:96:13)
    at emit (events.js:188:7)
    at Blynk.onReceive (/home/pi/Blynk-Test/node_modules/blynk-library/blynk.js:470:27)
    at .<anonymous> (/home/pi/Blynk-Test/node_modules/blynk-library/blynk.js:556:50)
    at emitOne (events.js:96:13)
    at emit (events.js:188:7)
    at Socket.<anonymous> (/home/pi/Blynk-Test/node_modules/blynk-library/blynk-node.js:50:14)

EDIT - fixed with parseInt(value) e.g.

PhysicalWhiteLED.pwmWrite(parseInt(WhiteLEDintensity));  // Sends PWM value to Physical LED (GPIO18)
1 Like

@Gunner the fix for the server has been coded up as a default of zero decimal places i.e. as it was before. Almost 24 hours ago the fix for the server was at the QA stage. It will require an app update for Blynkers to be able to select how many decimal places they want to see in the slider.

2 Likes

Sounds good… meanwhile I edumacated me some more JS :stuck_out_tongue:

1 Like

:joy::joy::joy::joy::joy:

1 Like