I am designing an app wherein a menu selection will cause an update most of the other widgets on the screen and the data for those changes has to come from the hardware side via Blynk.setProperty(); and virtualWrite(); calls.
In other words I expect to send at least 14, probably 23 widget updates at once, and then none for some time. It would look awful and add a lot of complexity if I delayed the screen updates to avoid flooding the server. Usually floods are due to people calling setProperty within a tight loop and usually all the calls are too the same virtual pin, which makes little sense. What I would like to propose is that the flood control shuts off the server when the same virtual pin is called too fast, and let batches of updates pass through OK when they are updating different pins.
For example the limitation could be imposed to something like this:
- No more than n updates per second (measured over 1 second) per pin.
- No more than nn updates to different pins per second (measured over 1 second).
E.g. n = 5 nn = 50
If either condition is exceeded, the server will disconnect.
This would ensure that coding runaways can be shut down, but allows legitimate, SetProperty() and virtualWrite() spikes to occur as needed by the app.