Need help with Blynk Project with devices that randomly go offline

[PeteKnight]

@mphillips

Is it still possible for that sensor to pull that pin high on boot without receiving a ‘P’?

Yes. Even pulling the pin top an intermediate “floating” state can be enough to prevent booting.

@mphillips

What I have done right now is uploaded a blank edgent template which just has edgent.run and edgent.begin functions to one of the devices to see if it stays online. Then I can enable one module at a time to see which one causes the disconnects. If it is truly their network disconnecting my devices or blocking me, then I would know from the disconnect on the blank edgent template on that device. This will be a bit of a slow process, but will help me get a solution remotely.

Good idea.

@mphillips

What is the max time a process should take to be considered a blocker? I know if it’s longer than 10 seconds, Blynk considers the device offline.

Anything that’s approaching 10 seconds is potentially a worry.

In this topic, I was doing some tests of HTTP versus HTTPS calls to the Blynk server to use the Blynk API as a method of transferring data between devices (like the old Bridge functionality in Legacy).
As you’ll see, HTTPS API calls could take between 2.5 and 40+ seconds, whereas HTTP API calls were taking sub 100ms…

Webhook widget

Okay, I’ve been doing some testing this afternoon. I’ve been using an ESP32 and the HTTPClient.h library. I’ve not tested with an ESP8266 and the ESP8266HTTPClient.h library, but I wouldn’t expect the results to be much different. I’ve managed to use the HTTPS API call with both the BlynkSimpleEsp32.h and BlynkSimpleEsp32_SSL.h libraries, however, the response times from the HTTPS API call are much longer than when using the HTTP API call. I guess this is what was causing @Blynk_Coeur’s -5 err…

The delays come from the negotiation/authentication process necessary with HTTPS connections.

Pete.