To those who have read this far, thanks. I am a user, a client and a huge fan of Blynk and am motivated in my discussion only with its improvement.
I created a useful wood stove controller that uses a stepper motor to open/close the air flow. I can set a target room temp, stove temp or just choose the air flow % manually.
Here’s the motor, wearing a stainless hat that plugs the air intake:
Now that it is freezing cold in New Hampshire, I dusted off the equipment added some minor code tweaks and reinstalled the controller. When I went to calibrate the actuator, the “Calibrate” button failed to work because of the change in the Blynk Library. I am sure of that and it’s no big deal - I easily could work around it. I was just looking for advice on the cause before I figured it out through my test script.
What I found was somewhat interesting, more from an academic/design perspective than “Oh my god! Help me fix this!”.
If you use a button to send an event to a device, let’s say “calibrate”, then you want to have another button (or the same button in my case) that sends an event to “confirm” (and then another event that says “goHigherUp”, etc), there are different ways to handle that sequence. One method is to call a calibrate() function right from the BLYNK_WRITE method on the button press.
But while your code is twiddling around with the motor, it is not running Blynk.run()… so the device will never receive new events and the device will not get a new signal to “confirm”. So, let’s put Blynk.run() into the calibrate() loop, so it can get that “confirm” event (which is received through the same BLYNK_WRITE function and just flags that the button was pressed again). That worked perfectly well for me until the 0.5.* lib, now I see that Blynk.run() will only run a single BLYNK_WRITE at a time. I never got that confirmation button press, even while looping on Blynk.run().
So, the solution is to leave the BLYNK_WRITE methods in a hurry! You can do that by calling functions using the timer.setTimeout(10,calibrate) technique that I mentioned earlier. This will launch the function through a queue manager and the BLYNK_WRITE function is finished – no strings attached.
Is this the “best practice”? Under these library conditions, I think it is. Can I live with the library change? Sure, now that I know what I am dealing with.
Am I blocking? I don’t think so!
Hope that helps others understand what happens “under the hood”.