BLYNK
BLYNK.IO       📲 GETTING STARTED       📗 DOCS       👉 SKETCH BUILDER

Slider (or similar input widget) only send to MCU after a confirm button is pressed?

Need Help With My Project
#1

Hi All,

I am looking for a way to be able to adjust a value on the console or app without sending it and then when a “save” or “update” button is pressed the value gets sent to the MCU. Is this possible under the current architecture? I currently have a workaround where there is a data stream for the current value and the slider on the datastream for the new value and on pressing a button it makes the current value the new value.

I just see that the slider widgets send the value after letting go. This seems like a lot of extra comms especially if someone is using the fine adjustment.

#2

The slider widget has the option for send on release, or constantly sending the new values as it’s moved.
If you want to add an “apply” button then you’d need two datastreams, and capture the slider value from one, then utilise this value when a button attached to a second datastream is pressed.

Pete.

#3

Thanks Pete always so quick to reply.

I have the setup where it only sends on release but further to my point where the user is pressing the fine control ( “+” and “-” ) buttons there is a significant amount of data that is just being sent for no reason.

I currently have a second datastream connected to a button that uses the latest value when pressed. My question is whether there is a way, to not send the data unless a button is pressed OR queried by the MCU? (I thought this was maybe what BLYNK_READ() was for but I was mistaken and now understand it is for a different purpose)

This might seem a bit nitpicky but I feel like its a significant amount of unnecessary data packets.

#4

No.

If you ever figure-out a good reason to use BLYNK_READ() then let me know, it’s still a mystery to me!

That’s not going to be an issue unless you’re using GSM or an internet connection that charges for inbound data, and even then the numbers are very small.
If it is a real issue then why not use a numeric input widget instead of a slider?

Pete.

#5

The numerical input is probably a better way to go about it but not sure how it handles the limits. I guess it would bound it by the datastream min and max. More testing for me…

I think the BLYNK_READ() might be deprecated in Blynk 2.0 as it seemed to relate to timers in the legacy on the console or app side that generated a call to the BLYNK_READ() for a pin. So periodically (a period set on the Blynk server side through widget settings) the server would call the function and run whatever you have there. So equivalent of putting a Blynk.virtualWrite() function call in a timer running on the MCU side you could place it in the BLYNK_READ() and the server would call it when it’s timer expires.

#6

I understand that, but still don’t see a use for it. In fact, with most controls, all you’d be doing ins increasing server data traffic this way, as it would create a “has anything changed” message each time the timer executes, as opposed to a positive “something HAS changed” whenever that slider value does actually change, which would be rarely in most use-case scenarios.

Why is data traffic such an issue for you?

Pete.

#7

That’s why I think it may soon (if not already) be deprecated. I agree with you with the methods they promote for communication using timers this is no longer useful. I also haven’t seen the ability to set these timers in Blynk 2.0 but I may be wrong…

I’m just personally bugged by inefficiency. It’s all this data being generated and the calls being sent by a server which is fine for little old me and my one system but multiply that at scale and it’s a significant waste of energy and resources on the server side. Anyway not sure how active the developers are in this forum anymore. Seems like It’s just a chat group with the same collection of users :joy:

#8

It’s the way that Blynk is designed to work, and it’s that constant communication across an always-on connection that allows Blynk to work the way that it does.

The developers tend to keep an eye on things, and contribute when needed. The primary developers are still living in the Ukraine, so as you can imagine day-to day life has a somewhat different focus to what it did 18 months ago, so getting involved in non-critical discussions doesn’t happen as much now.

The forum has a small group of active contributors. If you’d like to contribute more yourself you are more than welcome, that’s how community groups work.

Pete.

#9

I’m aware of their unusual predicament of being based in Ukraine. Don’t blame them just merely a comment. Will try to help out as and when I can. I’m also only just scratching the surface of what Blynk can do but as I learn and gain experience would love to give back.

1 Like
#10

Hello. You can program that on hardware side.
When slider is moved (or any other widget changes the value) you accept it in:

BLYNK_WRITE(Vx) {
   intermediateSliderVal = param.asInt();
}

You accept it. But you don’t apply it.
Now, when the “Save” button is pressed. You do the next:

BLYNK_WRITE(Vy) {
   int saveButtonState = param.asInt();
   if (saveButtonState) {
      appply(intermediateSliderVal);
   }
}

Does that make sense?

#11

Thanks @Dmitriy this is what I have implemented. Was just wondering if there was a more efficient way.
Thanks for the reply