Your account, project, and corresponding auth code(s), sits on just one server. In your case this is the New York server at 18.104.22.168
Your nearest server geographically is the one in Frankfurt on 22.214.171.124
When you create a Blynk account from your phone, it will normally be created on the Blynk server that’s geographically nearest at the time. If you did this while you on a business trip and were bored whilst sitting in your New York hotel room, then it would almost certainly end-up on the New York server.
But, there are other reasons why your account could be on the New York server. If your mobile ISP’s DNS servers resolved the New Your IP address rather than the Frankfurt one then it may be that they choose to do some slightly odd things with their DNS settings. I’d say that mobile communications companies based in the Middle East, China or parts of Asia are likely to be the main culprits for doing things a little differently.
When your mobile app tries to connect yo your project, no matter where you are in the world, it will do some clever stuff in the background to ensure that it connects to the server where your project lives. When your NodeMCU connects to the Blynk server it will also do some clever stuff to redirect the connection top the correct server, and produce the messages that you’ve seen in the serial monitor.
The only time that this clever redirection doesn’t work is when using the API calls, and in that case it’d important to specify the IP address of the server where your project lives. This is what is generally referred to as the “Geo DNS issue”.
Getting your account moved to a different server probably isn’t going to happen. You could create a new account on the Frankfurt server if you wish, and I guess you could force this by putting the Frankfurt IP address n the Custom Server fields of the app before you sign-up.
If you want to ping from the NodeMCU then this library is probably the best one to use:
You can install it directly from the “Manage Libraries” option of the Arduino IDE.
There is a bug in the library that always returns ‘true’ even if the ping fails (see #11), but the ping times seem okay (although the percentage loss numbers are also a bit questionable in case of a ping failure).
Ultimately, anything that involves the internet is going to give variable latency. Consider the round-trip of the phone talking to the server (across the internet) then the NodeMCU polling the server asking for updates (across the internet) then the response being sent from the server to the NodeMCU (across the internet). There’s an awful lot of scope for delays in that process, before the NodeMCU has any chance to act on the change of status of a widget in the app.
A local server, and your phone connected directly to the same network, is the only way to cut-out the variables introduced by the internet and the ISP’s providing the connectivity.