Your account, project, and corresponding auth code(s), sits on just one server. In your case this is the New York server at 45.55.96.146
Your nearest server geographically is the one in Frankfurt on 139.59.206.133
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.
Pete.