Automatic flood prevention?

Ideas
1

It seems to me that quite a lot of new users are going to skim read the FAQs and start flooding the Blynk servers. I’ve certainly done that (er, sorry) and kind of assumed the library would take care of it. My assumption was that virtualWrite() was simply telling the library there is a new value - not necessarily that it should be pushed to the cloud.

Perhaps the library should include some automatic flood prevention? For example, don’t send the new value immediately but do it at the next Blynk.run(). If too many values are being written then ignore updates for 100ms or whatever is reasonable.

It might also be nice to have the server determine the maximum update interval. So, if clients are connected right now allow a faster update speed, but otherwise require a lower rate??

2

@horsedung

Library already has flood prevention =). This is the only reason why you was able to put write within loop =). But even in that case there are some very slow boards (spark core for instance) that could easly crash on virtualWrite in main loop even with flood prevention.

Anyway thanks for ideas. We still looking for way of better flood prevention.

3

Agree, I found when my PIR was HIGH the ESP was continuously trying to send the “Turn on” command through to the other ESP via Blynk server, I changed my coding to check if it had been sent once and then only resend it if the flag had been cleared.

Its not the most efficient way but it “works”:

The first check is to determine if the pin state has changed, the second check is to determine if the digitalWrite was send to the “plug” ESP.

int Check1 = 0;
int Check2 = 1;

void loop() {
    
   Blynk.run();
   // Constantly check the state of pin 2
  // If it is HIGH the sensor is detecting motion
  if (digitalRead(sensorPin) == HIGH) {
     if (Check1 == 0){
     bridgePLUG.digitalWrite(5, HIGH);
     digitalWrite(ledPin, HIGH);
     Check1 = 1;
     Check2 = 0;}
  } else {
    if (two == 0)
    {
    bridgePLUG.digitalWrite(5, LOW);
    digitalWrite(ledPin, LOW);
    Check1 = 0;
    Check2 = 1;
    }
  }
}

Will review it on the weekend and check if there is a more efficient way to do it.

4

Been thinking about this a bit more and for most applications a hybrid time/event/change based API would potentially be awesome. The ability to set thresholds on sensors and then register an interest in changes on other devices.

In @Bobbo_SA’s example the sensor ESP shouldn’t need any special code as the PIR is sending a HIGH, but a debounce(millis) function to ignore state changes below a certain time might be useful. Then on the other ESP simply registering a handler function that is called if a virtual pin, digital pin or remote pin changes FROM_LOW_TO_HIGH - again potentially with the ability to apply an limit, e.g. at most 1 trigger every 30 seconds.

In almost all of my projects I’m not simply looking for a cloud enable digitalRead / digitalWrite.

I might have a go at writing a library…