Slider change?

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

What does asInt() function actually do? Does it trim or does it round? If it trims OK, but then why stop at 2 decimal places? Now I have 4 tiny numbers changing on screen to set an integer value of temperaure in celsius. Also sliders with given step inrement should move at given increment. So it “falls” / “jumps” into a desired value, no need for precision finger placing. Also, slider on my Note 8 is still very tiny. For the life of me I can’t set a desired value even on 1 decimal place. So where is the point of displaying something you can’t really set? If you show me a number, i.e. 23.47, now show me how to make it 23.51. My perception and expetation would and should be that this must be possible.

Virtual pin data is always sent as strings… this might explain issues with Node-red and NodeJS as they translated the full float value instead of the normally expected integer.

The ‘value’ of that string is always shown on the little numbers on the widgets like Sliders… for reference I guess? But they are not necessarily representative of the actual data type your sketch processes.

In the Arduino code options you can choose how you want the incoming data (to the device) to be received and processed…

param.asInt();  // As an Integer (no decimal points)
param.asFloat();  // As a floating number with decimal points (if applicable on that widget)
param.asDouble();  // As a double precision floating point number (if applicable on that widget - GPS is a good example)
param.asStr();  // As a string - the 'native' format

Anyhow, there is apparently some fixes coming in next App update that will give more user control over the decimal precision of the Slider widgets positional interpretation… so hang in there a little longer :wink:

Personally I am in full agreement of this fact… which is why I suggest using the Step widget for “digital like” precision and the slider for it’s “visually analog” referencing… not for fine, precise movement.

They have two completely different use case IMO. Because with the slider you can send only the “release” value, while steps send all the little increments, which might be a bad behavior in some applications (for example the state machine a user was mentioning). A selectable precision slider is the best solution (again IMO).

If the range of the slider is 23.40-23.60 it is very easy to set 23.51 :wink: it is just a matter of relative resolution.

I agree… A slider is a slider, a simple analog motion to digital value controller… how precise you want it to be depends on the ranges you set (and soon the decimal point option) and how you utilise the data in the sketch… blaming the slider for lack of “precision” is like blaming your calculator for the wrong numbers you type in :slight_smile:

Introducing Dual Blynk Sliders for High Range High Precision values

Hey Gunner, I had the exact same error as you did with NodeJS and the slider. I was going crazy trying to figure out what was causing my servo to kill the Blynk client…then I finally noticed the new update to the app and bingo!
Thank you for posting the fix. My slider is back to normal now.

1 Like

that’s OK, take it as a learning experience as you always do - unless you truly understand your users, any changes can be very inconvenient to them…

BLYNK_WRITE(V38)
{ //in AUTO MODE set intake selector chose between ANY/EXTERN/HOUSE/ROOF
  inletPreference = param.asInt(); // three position slider
  if (inletPreference == 0)
  {
    if (debug)
    {
      Serial.println(F("############# - System = inletPreference slider set to 0 'ANY'"));
      Serial.println(F("------------"));
    }
    roofOnlyUplift = 0;
    houseOnlyUplift = 0;
    externOnlyUplift = 0;
    chooseInlet();
  }
  else if (inletPreference == 1)
  {
    if (debug)
    {
      Serial.println(F("############# - System = inletPreference slider set to 1 'EXTERN'"));
      Serial.println(F("------------"));
    }
    externOnlyUplift = 30;
    houseOnlyUplift = 0;
    roofOnlyUplift = 0;
    chooseInlet();
  }
  else if (inletPreference == 2)
  {
    if (debug)
    {
      Serial.println(F("############# - System = inletPreference slider set to 2 'HOUSE'"));
      Serial.println(F("------------"));
    }
    externOnlyUplift = 0;
    houseOnlyUplift = 30;
    roofOnlyUplift = 0;
    chooseInlet();
  }
  else if (inletPreference == 3)
  {
    if (debug)
    {
      Serial.println(F("############# - System = inletPreference slider set to 3 'ROOF'"));
      Serial.println(F("------------"));
    }
    externOnlyUplift = 0;
    houseOnlyUplift = 0;
    roofOnlyUplift = 30;
    chooseInlet();
  }
}

because 4 = 4 not 4.01 or 3.99

but as long as the slider is between 4 and 5 then the int by Blynk will be 4, right?

2 Likes

err, yeah, but it seems to have stopped working.

i am rapidly upgrading my server (local) and I am embarrassed that it seems a bit behind…

my bad - hopefully it will be better when everything is up to date.

1 Like

i remember way back when we had to ask for the send-on-release option for sliders :wink:

1 Like

Yes @tulo wasn’t around in the old days or when we asked for vertical sliders etc.

Actually since the last update I have noticed the slider performs worse with the addition of float, almost like the pre send on release days.

At the bottom end of the slider range I am getting some nasty jitter.

2 Likes

As aforementioned, I solved the issue by using “menu” instead of “slider”.

And yes it was a little pain in the a…

But honestly we have all, I guess, had problems with “improvements” in our softwares and the more I use Blynk the more I like it so don’t shoot the pianist; thanks to the developers…