[SOLVED] Why sync pins only on the first connect?

Solved
1

All of the examples I’ve seen for using Blynk.syncAll() use a flag to only sync on the first connect

bool isFirstConnect = true;

BLYNK_CONNECTED() {
  if (isFirstConnect) {
    Blynk.syncAll();
    isFirstConnect = false;
  }
}

What is the reason for this? What’s wrong with synchronising on every connect?

BLYNK_CONNECTED() {
  Blynk.syncAll();
}

I’m worried that if I change the value of a pin from an app widget during a time when the hardware has lost connection (after previously being connected), it will not sync to the new value when the connection is established again.

1 Like
2

http://docs.blynk.cc/#blynk-firmware-virtual-pins-control-blynksyncall

you can do it anytime

3

So what is the reason the examples go to the extra trouble of making sure the sync is only done once on the first connection?

4

The purpose of the sync commands is to update your device with whatever the latest virtual pin values where… on the assumption that some changes were made from the App side while the device was disconnected.

Thus if your device is stably connected, it gets all App changes right away, no need for additional sync as the answer will be the same, just wastes connection “resources”.

Think entering a meeting late and asking “What did I miss”, once… as opposed to asking the same question every few seconds while still in the same meeting :stuck_out_tongue_winking_eye:

5

@Gunner,

I just finished performing the following experiments:

My phone with the app is on a different WiFi network than the device (an ESP8266). Both networks provide internet access to the Blynk cloud server.

The app has a step control widget on pin V2. It is handled on the device with the following code:

int alertTempLow;

BLYNK_WRITE(V2) {
  alertTempLow = param.asInt();
}

With the following code:

bool isFirstConnect = true;

BLYNK_CONNECTED() {
  if (isFirstConnect) {
    Blynk.syncAll();
    isFirstConnect = false;
  }
}
  1. App and hardware are connected to their respective networks and communicating via the cloud server. When the hardware connected for the first time, it acquired the value of the step widget via Blynk.syncAll() so alertTempLow is correct.
  • I then power off the router providing WiFi to the device, so the devices connection goes down. The app, on a different network, is still online and indicates the device is offline.
  • I change the value of V2 using the step widget (while the device is still not connected).
  • I then power the device’s WiFi router back up and the device re-connects.
  • Because Blynk.syncAll() is only called on the first connection (due to the isFirstConnect flag), alertTempLow is never set to the new value (that was changed while the device connection was down).

If I change the Blynk.syncAll() handling code to simply:

BLYNK_CONNECTED() {
  Blynk.syncAll();
}

then the V2 value set by the app while the device’s router was unplugged is properly updated. The device gets only one BLYNK_WRITE() call for V2 after the connection is re-established, not continuous BLYNK_WRITE() calls.

So I’ll ask again:
Why would you want to use the isFirstConnect flag to only call Blynk.syncAll() once on the first connect?

Think entering a meeting on time, but then falling asleep and then waking up and asking “what did I miss while I was asleep?”. :stuck_out_tongue_winking_eye:

6

Simple… not everyone sleeps during meetings (or at least makes it obvious if they do :wink: )

Basicly your use-case of a (battery powered?) sleeping device is different than what might perhaps be considered “normal”, e.g. a device that is line powered and runs all the time.

As @Pavel said, you can run the sync anytime… so figure out a way to incorporate it at device wakeup as well as first connect if you wish.

7

Hope this isn’t TL;DR
I seem to be having trouble either making my point or understanding the responses.

No, my use case is what I would consider the most common case, where the device is intended to remain fully active 24/7, whether battery or line powered. (For this specific case, it’s a thermometer that is line powered, possibly on a UPS. The step control widget on pin V2 allows me to change a temperature alarm set point). Sorry if my “sleeping during a meeting” analogy was taken to mean I’m putting my device into a sleep mode. By “sleeping during the meeting” I meant the device lost connection to the internet.

I guess powering down the router that provides the WiFi internet connection to the device is a bad example, which could be confusing because it involves powering stuff down. Instead, let’s say something further upstream (offsite) goes down to prevent internet access to the Blynk server, but the Wifi link between the local router and the device, and the device itself, remain active (and nothing goes to sleep). Note that at no time does the internet link between the app and the Blynk server go down.

I want to be able to change the value of the step control and know that the device will start using this new value as soon as possible. If I change it while the internet link to the device is down, obviously the device can’t be told to change it, but I want it to update as soon as the link comes back up.

  • If you follow the examples, where an isFirstConnect flag makes it so Blynk.syncAll() is only called on the first connect after device power up or program reset:
    If the device’s internet link goes down after the first connect, and I change the value using the step control widget during that time, then Blynk.syncAll() isn’t called when the internet comes back up, so the device’s V2 value won’t change unless I change it to something else and then back again in the app after the device is back online.

  • If you eliminate the isFirstConnect flag logic, so that Blynk.syncAll() is called every time BLYNK_CONNECTED() is invoked:
    If the device’'s internet link goes down after the first connect, and I change the value using the step control widget during that time, then Blynk.syncAll() is always called and V2 gets back in sync.

This meeting analogy you made the first time is not pertinent. “What did I miss?” (meaning Blynk.syncAll) isn’t asked every few seconds (meaning frequently) in either of the above two cases.

Think entering a meeting late (meaning I’ve changed the value in the app while the device was powered down) then asking “What did I miss?”. Later, you leave this meeting in progress to take an important phone call (meaning the device’s internet connection goes down but the device is not powered down, reset, or put into sleep mode, and I change the value in the app while it’s down) then returning and again asking “What did I miss?”.

Would you want to be told:
We can only tell you what you missed at the start, while you were late, but we can’t tell you what you missed during your phone call.
(This is how the examples using isFirstConnect work.)

Or would you want to be told:
Here’s what you missed during the time you were late, and here’s what you missed during your phone call.
(This is how eliminating the isFirstConnect logic works.)

So I still have the same question about this example (which is also widely used elsewhere, such as here):
Why, for most normal use cases, would you want to only do a sync after powering up or resetting, instead of also syncing after re-establishing a lost connection? (Given that the app can change pin values at any time, even when the device is offline either powered up or not.)

It just seems to me that the behaviour of the examples (syncing only on first connect, not on subsequent reconnects) isn’t what would be desirable for the majority of cases (and specifically mine).

Again, sorry if I’ve gone into too much detail and been repetitive to state my points.

8

Yes, apparently I didn’t fully understand the “what” of your question, nor really yet understand the “why”… I saw your question and answered it as best as I could. I will end my discussion with this…

The examples are just that… examples. If you want to run your code differently, then do so… sync something or everything whenever you want (beware of flooding)… first reconnect, every reconnect, on a timer, only on Tuesdays… Whenever. You. Want. :wink:

9

@Gunner, Thank you for being patient with me. You don’t have to respond any further if you don’t know the answer.

I guess that’s gist of it. I think that examples, especially those like the one I was referring to, which is one of the “official” examples, should give details or be self explanatory, on what they do and why. If they don’t, then I would hope that someone could elaborate if asked on this forum (after I do extensive RE-SEAR-CH to try to find the answer myself, as I did).

Obviously, the author of this particular example added specific code to use a flag, to make sure Blynk.syncAll() isn’t called on every reconnection, only on the initial connect. There’s even a comment included stating this:

// Keep this flag not to re-sync on every reconnection
bool isFirstConnect = true;

However, I am (still) unable to find a more detailed explanation of what the purpose of this is.

What is the down side of eliminating the flag and simply doing

BLYNK_CONNECTED() {
  Blynk.syncAll();
}

so that it does re-sync on every reconnection?

What issues could occur that the use of this “once only” flag is intended to prevent?

If there aren’t any down sides, shouldn’t the example(s) be updated with this simpler solution, which works better for my purposes, and I suspect, (at least no worse) for the majority of cases?

10

@MLXXXp please submit a pull request on GitHub of your fully documented version for consideration by Blynk.

11

I don’t mind answering questions… we all learn better with some dialog. I just don’t want to beat a dead horse too much :stuck_out_tongue_winking_eye:

:wink: :+1:

Since BLYNK_CONNECTED() seems to be a boolean command, as in if connected it returns a TRUE/1, then if Blynk is connected every time that command structure is called, it will synchronize every available virtual pin.

So either put it on a timer or some other conditional loop, otherwise the downside is that it is constantly screaming its equivalent of “What’s your 20? Over.” and bogging down the communications (analogies are a great teaching tool, until you have to explain them).

As for why that particular example and not something else, probably because it is the most common use-case in the author’s experiential history.

However, you can follow @Costas suggestion… and create a fully documented and tested example that works for you, so that the Developers don’t have to take their limited time away from other stuff, and perhaps they will add it into the Sketch Builder.

12

Done. The conversation can now continue using comments for the pull request.

14

@MLXXXp I have commented on the pull and consider it an essential adjustment for novice Blynkers, and after all they are the ones using the examples and Sketch Builder.

As it’s currently written, with the bool, they will think it is syncing when it’s not.
Thanks for submitting the pull request.

Edit: the pull has now been merged into the master by @Dmitriy

2 Likes
15

@MLXXXp to answer your basic question my assumption is that the Developers are very busy developing stunning new features rather than spending time fine tuning examples. Ergo Blynkers are expected to submit pull requests as and when the need arises.

2 Likes
16

OK, following all the GitHub stuff as made something clearer to me… aside from the SyncALL() command questions, which is straightforward: run the command whenever you want, it does what it says.

The additional confusion for me was that there is a BLYNK_CONNECTED() (Uppercase) Boolean function that gets called everytime the device connects, but only then.

I have no need for that in my use-case, so I wasn’t clicking onto the fact that is was an identically named (but differently displayed) “command” to the Blynk.connected() (Lowercase) command that can be called up with a timer, etc. to test the connection status… that is the one I use to monitor, every 10 seconds, if my USB-link gets disconnected, and was the “command” I was referring to all along.

So I still stand by my assertion that it doesn’t matter how you call SyncALL() just as long as it works as required (and the basis of the OP question). But I do apologize for any confusion I added as a result of dyslexic like oblivion of the two same, but differently displayed “commands”. :stuck_out_tongue:

1 Like