If you log in to the phone with your existing credentials the project will be available on both devices.
You can also refresh the token from within the app.
Pete.
Ah. The latter makes sense!
Many thanks, as ever Pete.
Okay, I copied my original project into a new one with a new token. I thought it was better for a few hours - then it failed again. I’ve monitored it over a couple of weeks and the server fails to respond for a few hours almost every day. Always seems to right itself after an hour or two. Sadly, this is unacceptable and my ideas for future projects using Blynk are now stopped.
Facts:
- The 4G router is 100% solid connectivity, as demonstrated by the CCTV sharing it working perfectly.
- The router is just a couple of metres from the ESP8266.
- There are no other wifi signals or other interference sources locally (it’s in the back of beyond!)
- The system has worked 100% up until a month or so ago. There have been no changes (other than me swapping out router, ESP, token in an effort to check if anything of mine is faulty).
The cynic in me does suggest that this is Blynk’s way of moving me from the legacy token system to a subscription, but I’m certainly not going to do that if I think it’s going to be this unreliable. It would be good to get to the bottom of the problem, as I love the Blynk format.
I have a couple of projects that I re-designed and re-configured when I migrated to Blynk IoT. Because of the differences, I decided to keep the old Legacy project running for the time being.
That legacy project is connected to the Frankfurt server (the same server that your serial output shows you are using), and is generally very reliable. It did go offline for 2 minutes yesterday between 05:01 and 05:03, but I suspect that was an issue with my router rebooting rather than the Blynk server.
The problem won’t be with the Blynk server, otherwise I’d be seeing these issues, as would hundreds of other Legacy users.
Pete.
Thanks Pete. I remember when developing this project that it was quite thirsty - the location is battery/solar powered. I considered putting the processor to sleep and got familiar with other developers’ problems with maintaining a heartbeat. In the end I left it powered fully up and going for the ‘sensible’ 10 second cycle (when the phone app is not active). Could this be an issue?
Since setting up with the new token, I’ve not actually encountered a time when it’s offline. All I can see is that it has been ‘online since…’ some time a few hours ago - so I know it’s been off, but whether that was 2 minutes or 2 hours, I don’t know, of course.
Difficult to say without seeing your sketch and knowing more about your hardware etc.
But, putting effort into a Legacy project at this stage of the product lifecycle isn’t a good use of resources.
Pete.
I agree, but I need to resolve it before feeling confident to continue with Blynk and the IoT subscription format.
Are you able to help me understand the dialogue below?
This is a segment of the working dialogue.
I’m unclear which ‘side’ is asking and which responding.
Line 1 tells me my ESP is trying to connect.
Line 2 request (by me) or response (from cloud)?
Line 3 ditto
[This is as far as the dialogue goes during the failed interchanges - just repeats lines 1-3]
Line 4 is me sending the token, I think?
Line 5 ack from cloud?
Line 6,7 just statements of progress, I’m guessing. Lines 1-3 similar?
Why don’t you just try the free version?
Yes.
In Debug mode, “<” indicates data sent from the device to the server, like this…
which is a 1D hex (29 decimal) “BLYNK_CMD_HW_LOGIN” request, followed by your Auth token
and “>” indicates data received from the server, like this:
which in this case is a C8 hex (200 decimal) “BLYNK_SUCCESS” response message.
So in effect the device is asking the server for permission to log-in, with the Auth token as the credentials, and the server is responding with Okay.
More info here:
Pete.
Yes, I was just looking at the free version. Presume there’s no expiry time to this for a single device?
Also, I read somewhere that it includes 2 devices.
And somewhere else that extra devices can be added for a one-off $4.99 each (or has that deal gone?)
I’m afraid $4.99/month is beyond my means.
Grateful thanks for your replies. I’d figured that the <,> showed direction. So the statements without are verbose debug from the ESP. So line 3
is presumably getting no response from the server and waits for 10seconds before trying again. What kind of response does it get, as line 4
is the ESP sending the token. I can’t see what acknowledgement triggers that token send.
Unfortunately, you can’t add more devices, if you need more devices you should upgrade to the plus plan or the pro plan.
More details here
No, there isn’t.
Correct.
That is no longer an option.
That (and the second line) looks like a message that comes from turning-on some sort of debugging in the ESP core, via Tools > Debug Level in the IDE, and is simply telling you that a request was sent to the DNS server to obtain the IP address for blynk-cloud.com and the response was that the url resolves to 139.59.206.133 which is the IP for the Frankfurt server.
The connection request is sent by the device to the server, when Blynk.begin or Blynk.connect is processed.
Pete.
Thanks John.
Thanks for all Pete. So line 3 does confirm that there is communication with the web, in order to resolve the cloud’s URL (so not a wifi or 4G issue at my end). Just no response from the URL. So has to be a server issue?
But there is a response from the url…
It responds with a C8 (BLYNK_SUCCESS) then because the device has received this it prints a “Ready” and tells you want the ping time to the Blynk server is (109ms in this case).
The ping is a little long, but okay.
Does that mean that your ISP uses 4G to provide your internet connectivity?
Pete.
Yes, it is a 4G (sometimes 3G) connection via Three. Ping is long - but acceptable on a cellular ISP - to me at any rate…
Just been looking at some debug logs I took last week:
This is the initial setup after re-building the project with a new token:
15:49:28.339 → [211101] IP: 192.168.0.35
15:49:28.339 → [211102]
15:49:28.339 → ___ __ __
15:49:28.339 → / _ )/ /_ _____ / /__
15:49:28.339 → / _ / / // / _ / '/
15:49:28.339 → ///_, /////_
15:49:28.339 → /__/ v0.6.1 on NodeMCU
15:49:28.339 →
15:49:28.339 → [211108] Connecting to blynk-cloud.com:80
15:49:28.339 → [hostByName] request IP for: blynk-cloud.com
15:49:28.339 → [hostByName] Host: blynk-cloud.com IP: 255.255.255.255
15:49:30.168 → pm open,type:2 0
15:49:33.309 → [216109] Connecting to blynk-cloud.com:80
15:49:33.309 → [hostByName] request IP for: blynk-cloud.com
15:49:33.309 → [hostByName] Host: blynk-cloud.com IP: 255.255.255.255
15:49:38.325 → [221110] Connecting to blynk-cloud.com:80
15:49:38.325 → [hostByName] request IP for: blynk-cloud.com
15:49:38.325 → [hostByName] Host: blynk-cloud.com IP: 255.255.255.255
15:49:43.295 → [226111] Connecting to blynk-cloud.com:80
15:49:43.295 → [hostByName] request IP for: blynk-cloud.com
15:49:43.341 → [hostByName] Host: blynk-cloud.com IP: 255.255.255.255
15:49:48.312 → [231112] Connecting to blynk-cloud.com:80
15:49:48.312 → [hostByName] request IP for: blynk-cloud.com
15:49:48.358 → [hostByName] Host: blynk-cloud.com IP: 139.59.206.133
15:49:48.405 → [231216] <[1D|00|01|00] …zYjmioB3
15:49:48.499 → [231299] >[00|00|01|00|C8]
15:49:48.499 → [231299] Ready (ping: 82ms).
15:49:48.499 → [231299] Free RAM: 48192
15:49:48.499 → [231299] >[14|00|01|00]#
15:49:48.499 → [231299] >pm[00]14[00]out[00]16[00]out[00]12[00]out[00]5[00]out[00]2[00]out
15:49:48.593 → [231366] <[11|00|02|00]Hver[00]0.6.1[00]h-beat[00]10[00]buff-in[00]1024[00]dev[00]NodeMCU[00]build[00]Apr 15 2022 17:45:34[00]
15:49:49.577 → [232367] <[0E|00|03|00|0E]ALARM!
15:49:50.749 → [233554] >[00|00|02|00|C8]
15:49:50.796 → [233606] >[00|00|03|00|C8]
Note it initially starts looking for a default URL: 255 etc, before finding the correct server address. But it then picked up okay and ran for hours until stopping overnight.
Still stopped the next morning, I looked at the serial debug and got:
09:55:31.632 → [60053337] Connecting to blynk-cloud.com:80
09:55:31.632 → [hostByName] request IP for: blynk-cloud.com
09:55:33.320 → [hostByName] Host: blynk-cloud.com IP: 255.255.255.255
09:55:36.649 → [60058338] Connecting to blynk-cloud.com:80
09:55:36.649 → [hostByName] request IP for: blynk-cloud.com
09:55:38.337 → [hostByName] Host: blynk-cloud.com IP: 255.255.255.255
09:55:41.619 → [60063339] Connecting to blynk-cloud.com:80
09:55:41.619 → [hostByName] request IP for: blynk-cloud.com
09:55:43.354 → [hostByName] Host: blynk-cloud.com IP: 255.255.255.255
09:55:46.636 → [60068340] Connecting to blynk-cloud.com:80
09:55:46.636 → [hostByName] request IP for: blynk-cloud.com
09:55:48.324 → [hostByName] Host: blynk-cloud.com IP: 255.255.255.255
Note the wrong URL and it seems to be cycling at ~2secs, NOT 10secs.
I hit the reboot at 56:07.299:
09:56:01.626 → [60083343] Connecting to blynk-cloud.com:80
09:56:01.626 → [hostByName] request IP for: blynk-cloud.com
09:56:03.361 → [hostByName] Host: blynk-cloud.com IP: 255.255.255.255
09:56:06.643 → [60088344] Connecting to blynk-cloud.com:80
09:56:06.643 → [hostByName] request IP for: blynk-cloud.com
09:56:07.299 → rl - lots of garbage, then:
09:56:07.299 → rl09:56:07.299 → rl
09:56:07.393 → SDK:2.2.2-dev(38a443e)/Core:2.7.3-3-g2843a5ac=20703003/lwIP:STABLE-2_1_2_RELEASE/glue:1.2-30-g92add50/BearSSL:5c771be
09:56:07.393 → [64] Connecting to H…m
09:56:07.393 → scandone
09:56:08.002 → wifi evt: 2
09:56:10.207 → scandone
09:56:10.207 → state: 0 → 2 (b0)
09:56:10.207 → state: 2 → 3 (0)
09:56:10.207 → state: 3 → 5 (10)
09:56:10.207 → add 0
09:56:10.207 → aid 11
09:56:10.207 → cnt
09:56:10.254 →
09:56:10.254 → connected with H…m, channel 5
09:56:10.254 → dhcp client start…
09:56:10.254 → wifi evt: 0
09:56:10.441 → ip:192.168.8.111,mask:255.255.255.0,gw:192.168.8.1
09:56:10.441 → wifi evt: 3
09:56:10.910 → [3568] Connected to WiFi
09:56:10.910 → [3568] IP: 192.168.8.111
09:56:10.910 → [3569]
09:56:10.910 → [3568] Connected to WiFi
09:56:10.910 → [3568] IP: 192.168.8.111
09:56:10.910 → [3569]
09:56:10.910 → ___ __ __
09:56:10.910 → / _ )/ /_ _____ / /__
09:56:10.910 → / _ / / // / _ / '/
09:56:10.910 → ///_, /////_
09:56:10.910 → /__/ v0.6.1 on NodeMCU
09:56:10.910 →
09:56:10.910 → [3575] Connecting to blynk-cloud.com:80
09:56:10.910 → [hostByName] request IP for: blynk-cloud.com
09:56:11.191 → [hostByName] Host: blynk-cloud.com IP: 139.59.206.133
09:56:11.707 → [4419] <[1D|00|01|00] …FI8sJ2JBgMW
09:56:12.223 → [4928] >[00|00|01|00|C8]
09:56:12.223 → [4929] Ready (ping: 509ms).
09:56:12.223 → [4929] Free RAM: 48736
09:56:12.223 → [4929] >[14|00|01|00|10]
09:56:12.223 → [4929] >pm[00]16[00]out[00]12[00]out
09:56:12.317 → [4996] <[11|00|02|00]Hver[00]0.6.1[00]h-beat[00]10[00]buff-in[00]1024[00]dev[00]NodeMCU[00]build[00]Apr 16 2022 17:10:32[00]
09:56:12.645 → [5328] >[00|00|02|00|C8]
09:56:13.301 → [5997] <[0E|00|03|00|0E]ALARM!
09:56:13.817 → [6528] >[00|00|03|00|0E]
09:56:20.240 → pm open,type:2 0
09:56:23.287 → [15999] <[06|00|04|00|00]
09:56:23.662 → [16353] >[00|00|04|00|C8]
Just for reference, working properly, the phone app is off initially, giving the 10sec poll and response, then the phone app is switched on:
10:01:53.392 → [346066] <[06|00]%[00|00]
10:01:53.486 → [346184] >[00|00]%[00|C8]
10:02:03.378 → [356068] <[06|00]&[00|00]
10:02:03.706 → [356425] >[00|00]&[00|C8]
10:02:13.364 → [366070] <[06|00]’[00|00]
10:02:13.645 → [366359] >[00|00]’[00|C8]
10:02:23.397 → [376072] <[06|00]([00|00]
10:02:23.679 → [376395] >[00|00]([00|C8]
10:02:33.383 → [386074] <[06|00])[00|00]
10:02:33.665 → [386379] >[00|00])[00|C8]
10:02:35.868 → [388578] >[14|1E]b[00|04]
10:02:35.868 → [388578] >vr[00]1
10:02:35.962 → [388645] <[14|1E]b[00|0B]vw[00]1[00]13.756
10:02:36.009 → [388712] <[14|1E]b[00|08]vw[00]5[00]255
10:02:36.103 → [388779] <[14|1E]b[00|08]vw[00]6[00]255
10:02:36.149 → [388846] <[14|1E]b[00|08]vw[00]8[00]255
10:02:36.196 → [388913] <[14|1E]b[00|06]vw[00]7[00]0
10:02:36.899 → [389603] >[14|1E]b[00|04]
10:02:36.899 → [389603] >vr[00]1
10:02:36.993 → [389670] <[14|1E]b[00|0B]vw[00]1[00]13.756
10:02:37.040 → [389737] <[14|1E]b[00|08]vw[00]5[00]255
10:02:37.087 → [389804] <[14|1E]b[00|08]vw[00]6[00]255
10:02:37.181 → [389871] <[14|1E]b[00|08]vw[00]8[00]255
10:02:37.228 → [389938] <[14|1E]b[00|06]vw[00]7[00]0
10:02:37.931 → [390626] >[14|1E]b[00|04]
10:02:37.931 → [390626] >vr[00]1
10:02:37.978 → [390693] <[14|1E]b[00|0B]vw[00]1[00]13.756
10:02:38.072 → [390760] <[14|1E]b[00|08]vw[00]5[00]255
10:02:38.119 → [390827] <[14|1E]b[00|08]vw[00]6[00]255
10:02:38.212 → [390894] <[14|1E]b[00|08]vw[00]8[00]255
10:02:38.259 → [390961] <[14|1E]b[00|06]vw[00]7[00]0
10:02:38.869 → [391548] >[14|1E]b[00|04]
10:02:38.869 → [391548] >vr[00]1
Again, just for reference I killed the router internet connection at 10:16:34, then re-enabled at ~10:17:04 (phone app is off throughout):
10:16:24.902 → [1217617] <[06|00]y[00|00]
10:16:25.137 → [1217816] >[00|00]y[00|C8]
10:16:34.935 → [1227619] <[06|00]z[00|00]
10:16:39.953 → [1232621] Connecting to blynk-cloud.com:80
10:16:39.953 → [hostByName] request IP for: blynk-cloud.com
10:16:39.953 → [hostByName] Host: blynk-cloud.com IP: 139.59.206.133
10:16:39.953 → [1232625] <[1D|00|01|00] …dwFI8sJ2JBgMW
10:16:40.843 → [1233517] >HTTP/
10:16:40.843 → [1233517] Packet too big: 20527
10:16:40.843 → [1233518] >1.1 4
10:16:40.843 → [1233518] Packet too big: 8244
10:16:40.843 → [1233519] >05 [0D|0A]
10:16:40.843 → [1233519] Packet too big: 3338
10:16:40.843 → [1233520] >Conte
10:16:40.843 → [1233521] Packet too big: 29797
10:16:40.843 → [1233524] >nt-Le
10:16:40.843 → [1233526] Packet too big: 19557
10:16:40.843 → [1233528] >ngth:
10:16:40.843 → [1233530] Packet too big: 26682
10:16:40.843 → [1233533] > 0[0D|0A|0D]
10:16:40.843 → [1233535] Packet too big: 2573
10:16:43.857 → [1236538] Bad hdr len: -1
10:16:44.982 → [1237629] Connecting to blynk-cloud.com:80
10:16:44.982 → [hostByName] request IP for: blynk-cloud.com
10:16:44.982 → [hostByName] Host: blynk-cloud.com IP: 139.59.206.133
10:16:44.982 → [1237636] <[1D|00|01|00] …6QdwFI8sJ2JBgMW
10:16:44.982 → [1237640] >HTTP/
10:16:44.982 → [1237640] Packet too big: 20527
10:16:44.982 → [1237641] >1.1 4
10:16:44.982 → [1237641] Packet too big: 8244
10:16:44.982 → [1237645] >05 [0D|0A]
10:16:44.982 → [1237646] Packet too big: 3338
10:16:44.982 → [1237649] >Conte
10:16:44.982 → [1237650] Packet too big: 29797
10:16:44.982 → [1237653] >nt-Le
10:16:44.982 → [1237655] Packet too big: 19557
10:16:44.982 → [1237657] >ngth:
10:16:44.982 → [1237659] Packet too big: 26682
10:16:44.982 → [1237662] > 0[0D|0A|0D]
10:16:44.982 → [1237664] Packet too big: 2573
10:16:47.983 → [1240667] Bad hdr len: -1
10:16:49.951 → [1242637] Connecting to blynk-cloud.com:80
10:16:49.951 → [hostByName] request IP for: blynk-cloud.com
10:16:49.951 → [hostByName] Host: blynk-cloud.com IP: 139.59.206.133
10:16:49.951 → [1242643] <[1D|00|01|00] …dwFI8sJ2JBgMW
10:16:54.968 → [1247645] Connecting to blynk-cloud.com:80
10:16:54.968 → [hostByName] request IP for: blynk-cloud.com
10:16:54.968 → [hostByName] Host: blynk-cloud.com IP: 139.59.206.133
10:16:54.968 → [1247653] <[1D|00|01|00] …P6QdwFI8sJ2JBgMW
10:16:59.985 → [1252654] Connecting to blynk-cloud.com:80
10:16:59.985 → [hostByName] request IP for: blynk-cloud.com
10:16:59.985 → [hostByName] Host: blynk-cloud.com IP: 139.59.206.133
10:16:59.985 → [1252660] <[1D|00|01|00] …QdwFI8sJ2JBgMW
10:17:02.985 → [1255662] Login timeout
10:17:04.954 → [1257662] Connecting to blynk-cloud.com:80
10:17:04.954 → [hostByName] request IP for: blynk-cloud.com
10:17:04.954 → [hostByName] Host: blynk-cloud.com IP: 139.59.206.133
10:17:05.049 → [1257732] <[1D|00|01|00] …QdwFI8sJ2JBgMW
10:17:05.143 → [1257845] >[00|00|01|00|C8]
10:17:05.143 → [1257846] Ready (ping: 113ms).
10:17:05.143 → [1257846] Free RAM: 47584
10:17:05.143 → [1257846] >[14|00|01|00|10]
10:17:05.143 → [1257846] >pm[00]16[00]out[00]12[00]out
10:17:05.236 → [1257913] <[11|00|02|00]Hver[00]0.6.1[00]h-beat[00]10[00]buff-in[00]1024[00]dev[00]NodeMCU[00]build[00]Apr 16 2022 17:10:32[00]
10:17:05.283 → [1257993] >[00|00|02|00|C8]
10:17:15.223 → [1267915] <[06|00|03|00|00]
10:17:15.316 → [1267992] >[00|00|03|00|C8]
10:17:25.209 → [1277917] <[06|00|04|00|00]
10:17:25.350 → [1278029] >[00|00|04|00|C8]
10:17:35.243 → [1287919] <[06|00|05|00|00]
10:17:35.383 → [1288063] >[00|00|05|00|C8]
It does go further and attempt to send the token, which it doesn’t when in the ‘deaf server’ situation.
Pete, this is an imposition, and I really value your patience. Probably gone as far as I can with this, and I only submit the above in case you spot an obvious error.
The real question is whether it’s acceptable to Blynk. If you have a long ping then you may have heartbeat timeout issues and lack of responsiveness to app commands.
It looks like you have a DNS issue, which could simply be a lack of internet connectivity overall, or just a problem reaching the DNS server.
You could try specifying the cloud server IP address in your connection command. If you’re using Blynk.begin that would be…
Blynk.begin(auth, ssid, pass, IPAddress(139,59,206,133), 80);
You could try port 81 as well (change the 80 to 81 in the Blynk.begin command above).
Pete.
Brilliant! Just the kind of insight I needed. I wouldn’t be surprised that the cellular ping time might be quite variable (the 3G signal in the area is very strong, the 4G quite week and the router, in auto mode, will switch between the two - in fact at one time I’d forced it into using just 3G, to prevent it locking onto a weedy 4G signal as the 3G bandwidth is easily adequate for this application), and might go out to unacceptable lengths occasionally. There was a 500ms ping in one of my serial debug strings.
I will modify the code and give it a whirl. Will be a week or two to confirm.
Thank you Pete.
I presume that server IP address is static?
Yes, until it’s decommissioned of course.
Blynk has introduced a nicer solution with their IoT cloud servers, using subdomain names for the individual geographic servers, but with IoT its just a case of hard-coding the IP address.
Sounds like that’s something you should try again.
Pete.
1 Like
Hi Pete.
An update on my project.
I modified the code to directly address the Frankfurt server as you suggested and it works fine. Incidentally, the port 81 did not work - port 80 did.
Also did some comparative tests re the weedy 4G v. the strong 3G.
Pings on the former were often >100ms and, whilst the download speeds were 5-10Mb, the upload speeds (important for my CCTV system) were often down in the 200kb region!
3G was giving 11ms pings and ~10/3Mb results. The router, in auto, was always favouring the 4G mast, so had to be forced into 3G-only mode.
Gone almost a fortnight now with just a couple of half-hour breaks, usually in the small hours, which is just fine for my application.
Just hoping that when the 3G service is terminated, they’ll upgrade the local mast to 4G. Probably will.
Thanks again for your invaluable insight.
Dave
1 Like