HI @PeteKnight
I fully grasp what you are saying, I just felt explaining the project in its entirety would be unnecessarily taking up too much time of who ever wanted to assist. My apologies if this reasoning was flawed.
We are by now means focussing on home automation, rather larger scale projects (pro bona often) involving Environmental and agricultural solutions where there is none available, not easily accessible or simply too expensive mainly due to the weak performance of our currency. In this case, I doubt an off the shelf solutions would have worked due to the criteria determined by the situation i.e. PCB had to be capable of transferring 20A current (and 240V) safely whilst measuring the current and controlling ‘high load’ devices. Further to this, no external wires, capable off withstanding extreme weather conditions, battery and solar backup and and and…
As I mentioned before, our choice in sticking with a single supplier for MCU (and as few other suppliers for the remaining components as possible) is based on my ±24 years of experience in dealing with hardware solutions. IMO… the simpler you can keep the design (fewer suppliers, brands or vendors), the better. Also leans to easier fleet management and client better support.
We have some experience in using ESP8266 tech from earlier days using Arduino and NodeMCU and know it its extremely widely used. I prefer Particle and the new ESP32, but each to his own I suppose… which is also a good thing else what a boring place the world would be.
We have using Ubidots up until now, but the lack of providing a scheduler widget (currently) made this project impossible so we had to look elsewhere, hence settling on Blynk as even I, with my limited programming knowledge, found it quite easy to start and control a device. As we did not start off this project with Blynk in mind as a service provider, the code was never optimised for Blynk. Hence me approaching support and the forum about the Void loop() section.
To be honest, we have not had any problems using delay() as when needed, we enable ThreadEnable mode or use non-blocking delays. Outside of testing, the delay(10000) in this case is actually a delay(1000) which is a much needed delay of 1s as we are also posting to Particle Cloud which as a 1 post per second (or more accurately, 4 posts per 4 seconds) limitation. Leaving out this delay will result in some unwanted ‘data loss’. I simply changed it to 10s during my testing stage unknowingly exceeding the 10s timeout on Blynk whenever MCU restated.
I am most certainly not the lead programmer as you can see, so let me not get involved in something where I am way out of my league
Thanks!!
Friedl.