Widget vertical slider ... (flip axis) issue in case of reverse preset

Hi Blynkers and our community !

What happening with the vertical slider? If we set the range with reverse numbers (high value for bottom, low value for top) then each time Blynk app open the number of the slider indicated its set max value.

Why do I do / need this?
I am using an ultrasonic sensor to measure the water level in my water tank at home aimed to trigger the water pump. I used 2 vertical sliders to preset for H/L levels. Since the sensor assembled on the top of the tank so it measures from the top down to its current water level. I also want the said vertical slides preset reverse like that. It will look practically as per the water tank and be easy to see / use.
Can it have “flip axis” like the widget Level H?

Any ideas on it.

I also expected the axis to flip,but it did not. So what I did was hide the value then subtract the slider value from a constant equal to the max value. Mine is a speed control but the same problem.

const int MAXSPEED = 200; //max of slider

BLYNK_WRITE(V2) {    // speed control
  int dspeed = MAXSPEED - param.asInt() ;
  // do stuff with dspeed
}  // V2

It already does… what are your value ranges set for and are you trying to get it to look like?

image image


@Gunner: Thanks for your concern but the one you mentioned it is level H, not vertical slider. Hope Blynk to consider this case to revise the vertical slider with flip axis as it is really necessary in reality.

1 Like

Yes thanks for your advice. I thought of this already. Actually I want a flip one physically to look similarly to sensor operation.

It doesn’t work like that in the iOS app.
Setting a vertical slider with values 100 → 0 results in 100 at the bottom, zero at the top.
Putting the app into Run mode and moving the slider to say 55% then killing the app and re-staring it results in the slider still being set at 55%

Are you sure you’re not doing a Blynk virtual write to the pin to change it’s value?


What we expect in that case is 100 at the top and zero at the bottom.
In other words the leftmost value in the widget edit screen should always be at the top of a vertical slider. This gives us the ability to have the slider do both behaviors, simply by setting the range appropriately.

@PeteKnight: I dont think the issue with my code since it is quite normal as I have done so far. To be honest and not conservative, I share it as below:

  byte pinL = param.asInt();
  L_level = pinL;

By the way I recorded a short clip what I am doing that hope you could find something … yeah I could be wrong … hair changing more than a half already :grinning:

I think I’m looking at thus from a different perspective. For me the vertical slider mimics the sliders you get on a mixing desk. The bottom position means 0 VU and the top means Max VU. So, you’d normally have 0 at the bottom and say 100 at the top.
Therefore I’d expect the leftmost number to be at the bottom and the rightmost to be at the top, but if you want it to work the other way round (slide downwards for a larger number) then you put the larger number on the left.


@dunghnguyen I tried the same thing on iOS and it remembers the slider value when changing from one tab to another, so it looks like an Android bug.


Must be, as I can reproduce this on my phone (Galaxy S5). Switching project will cause the issue as well. But it only occurs when the number on the left is larger than the one on the right. When the number on the left is smaller this does not occur.

@PeteKnight: I dont think so … we are facing to the widget of Blynk’s that you suppose the reason coming from a bigger issue … android bug :slight_smile: … I am sure this could be captured by Blynk programmer who created that widget and he or she should consider this with serious clarification before raising this to further.

So … it seems I need to remove the sensor then plug it up from the bottom … really afraid of making a drill underneath as leakage should be a big bigger issue :grinning: … joking …

If we cannot move next with a solution then I suppose to follow the advise from @DaleSchultz … measure how high the water is rather to detect when the water go overflowing :joy:

When I said “Android bug”, I meant a bug in the Android version of the Blynk app, not a bug in the Android OS itself - we all know that could never happen :wink:

@BlynkAndroidDev, have you seen this thread?


1 Like

Thanks for the report, I’ll check


Actually I was showing the Level V, but yes sorry, I saw the reference to the level display and your need for measuring so I just thought the slider reference was a typo.

Yes, I can see some potential to having a slider run in opposing directions as normal. But I would NOT want it to do so simply by inverting the MIN MAX, as there are plenty of reasons for having a HIGH to LOW or negative to positive slide control.

I don’t think its lack of availability is a bug, as sliders never had such flip axis option, but does sound like a job for the Roadmap Vote - https://portal.productboard.com/blynk/tabs/2-all-your-ideas

I’ve uploaded new beta build containing a fix to this issue. It will be available soon.


Now that’s what you call service, and on a weekend too!


@Gunner: I got all what you mean but many application in real life we need it.

@BlynkAndroidDev and @PeteKnight: I tested it again, ie…low level with high value and high level with low value = actually it works perfectly = correct value as we selected after release. It is just about after we switch between widget Tabs its indicated value is the max value, not the value we selected / after release.

Have a nice weekend Gentlemen :grinning:

Have you tried the beta fix for this?


1 Like