The majority of the code runs on an Arduino mega, and I had it transmit a few basic variables, like temperature and set point, to an ESP32, via an additional serial UART port. The ESP32 then sent those values to the blynk 1.0 cloud. This worked great, and allowed me to execute most of the program in the void loop on the Mega, while having the ESP32 do all the wifi stuff.
As I am a bit more experienced with programming now, I want to simplify the project and only include a single ESP32 and stop using the Arduino Mega. I also obviously need to get everything running on the new Blynk 2.0.
A few of my questions about going down this path are as follows;
I have about 5 physical buttons in this project. When programming push-button presses (real buttons, not virtual), do I always necessarily need to use hardware, or timer interrupts? or can I poll the digital inputs in the main void.loop() and use several millis based delays, to ensure that the button value’s are only read every 10ms second or so?
Are there any reliable methods to allow me to continually run the program, even if the wifi is down, for an ESP32? Last time I heard, Blynk.run() would block the main loop if there was a wifi outage.
Can I get all of this done just using 1 core of the ESP32? The multicore stuff is still a bit confusing to me.
You can’t use blocking delays with Blynk, but you can use a timer to poll your physical buttons.
It depends on the functionality you want, but polling each button once every 100ms is usually more than sufficient to achieve the responsiveness that you’d normally expect.
However, with 5 physical buttons I’d use interrupts.
You will need a bit of debounce code, and a separate debounce tracking variable for each button.
Yes, covered many times in the forum. You need to manage your own WiFi connection then use Blynk.config and Blynk.connect, and only process Blynk.run if Blynk.connected == true
Well, it’s not just one of these millis comparison routines is it, it’s five of them, or preferably 5 timers polling 5 pins in turn. Unless you put everything into one routine, which becomes cumbersome and slow.
Five ISRs, each with a debounce routine is the way I’d do it, much cleaner and more efficient. Just remember to keep your ISR clean and efficient - no serial prints and no non-volatile variables.