Void loop() best practises

Friedl_Basson · January 16, 2020, 8:00pm

Hi -

I am VERY new to Blink, so please bear with me Referring to another topic I have found addressing similar situation:

I read that it is advised to keep the Void loop() clean but I have project that requires the code to calculate current used by a device, so it is not a simple case of reading the analogues value of a sensor. In this case, I have Particle publishing the calculated value to Particle Cloud and via a web hook to Blynk. The publishing code however runs in the Void loop() section.

The challenge I am facing is that when the code does not publish for what ever reason, the code is set to reset the device. This happens very quickly, but I noticed that even though the button remains in the ON position, the device being controlled and measured, will not turn on unless the button reverts back to the OFF position and then back to the ON position.

Here is my Void loop() code… I can post the entire code if needed:

    
    
    Void loop() {
    Blynk.run();
    
    {
      d = digitalRead (led);
      Serial.println(d);

      if (d > 0) {
      digitalWrite (redPin, LOW);
      digitalWrite (bluePin, HIGH);

    }else{
      digitalWrite (bluePin, LOW);
      digitalWrite (redPin, HIGH);
      }
    }

      float sensor_value = getRms();
 
      if (sensor_value >= 0) {

      char data[16];
      snprintf(data, sizeof(data), "%.3f", sensor_value);
      Particle.publish("Amp", String::format("{\"data\":%.3f}", sensor_value), PRIVATE); 
     
      delay(10000);
  
     } else {
      
     System.reset(); 

       }
     }

Is it as simple as moving everything outside of the Void loop() and include Timer function?

Many Thanks,
Friedl.

PeteKnight · January 17, 2020, 4:42am

@Friedl_Basson please edit your post and add triple backticks at the beginning and end of your code so that it displays correctly.
Triple backticks look like this:
```

Pete.

Friedl_Basson · January 17, 2020, 5:11am

Hi @PeteKnight -

Thank you for taking the time to respond. I tried that as set out in the Welcome section of the forum as the standard " icon as I am accustomed to using in Particle forum yielded the same results.
Nevertheless, I resolve the problem by manual aligning each line and moving the first character couple of spaces away from the first space in each line… strange indeed.

Regards,
Friedl.

PeteKnight · January 17, 2020, 5:19am

What I find strange is that having provided you with triple backticks to copy and paste, you choose to use different characters and wonder why they don’t work, then resort to a work-around that doesn’t produce the desired result either.

Pete.

Friedl_Basson · January 17, 2020, 5:30am

@PeteKnight

My apologies… changed the character, hope is is displaying better now, looks the same on my side though.

PeteKnight · January 17, 2020, 7:09am

It seems that your code is attempting to read your sensor and if it’s successful then publishing g the data and waiting 10 seconds.

If the sensor read is unsuccessful then the device is restarted. I’m not sure about the logic around this rseetting process, it seems a bit clunky to me, so I’ll skip that bit.

While the 10 second delay command is executing, no other code can be processed. The Blynk library needs regular and frequent processor time, to do it’s ‘magic’, which is why Blynk.run is in the void loop and the loop needs to be clean, so that the Blynk.run command can be executed almost constantly - hundreds of tomes per second if possible.
One of the things that Blynk.run does is to check-in with the server to see if any commands have been sent to the device from the app.

If the Blynk server and the device don’t do this handshake at least every 10 seconds then the server will assume that the device is dead, and show it as offline.

Any function that is called by a timer must finish executing before the 10 second timeout period, and preferably much much sooner, to allow the void loop to complete again.

So, simply moving your code from the void loop as it stands and calling it with a timer won’t work, unless you remove the 10 second delay. This should be fine, as the delay will be redundant if the timer is set to run every 10 seconds.

Whether you are doing other dodgy stuff in the rest of your code is impossible to tell.

Pete.

Friedl_Basson · January 17, 2020, 7:42am

Hi @PeteKnight

Thank you fore your comprehensive response. Just some comments;

It is indeed the case. The 10s delay is simply while testing, normally set to 1s as this is the limit imposed by Particle cloud. Or actually 4 publishes per 4 seconds.

it only resets the device if it stop publishing altogether for whatever reason. After the reset (not a full restart) publishing will resume.

I will reduce the delay and see whether it solves the problem. It might, or not… I can see in Particle Cloud event manager that the Particle device stops publishing (for what ever reason) resets and starts publishing again. Maybe with the delay reduced, it will not lose connection to Blynk.

By moving everything outside the Void loop() I also meant the delay and only keep the timer and Blynk.run functions inside the loop.

Not sure what you are implying by “other doggy stuff”… If you are implying that a Delay() or reset is doggy, I must know less about C++ than I though.

Considering my brief experience in this forum, I think I have made up my mind about Blynk though… cannot see how I will pay $6000 per year for the product and this will be the tone of people supporting the product. I made it very clear that I am new to Blynk and by now means an expert, this forum is just not a good fit for me. Not the only reason, but maybe the swing vote…

Please don’t get me wrong, I do appreciate the time you took to respond to my question.

Have a great day further!!

Kind Regards,
Friedl.

PeteKnight · January 17, 2020, 9:09am

I’m not sure how you arrived at the Blynk community forum, or how much research and reading you’ve done prior to signing-up and posting - I guess that some of the basics have passed you by.

This is the community forum, which provides free support for the free (non commercial) product, and the quality of the support you get here is a reflection of the price you’re paying (i.e nothing).

If this is a commercial product that you’re developing then the place to start your journey is at Blynk.io
The staff there will discuss your requirements with you and assist you in developing a solution that meets your needs, including the support SLA requirements, and your budget.
I would doubt that they would recommend a Particle based solution though, as this adds a level of complexity to the process that is, in my opinion, unnecessary in a production environment.

The Blynk.io route would also have led you to this document, which explains why delays don’t work with Blynk.
http://help.blynk.cc/getting-started-library-auth-token-code-examples/blynk-basics/keep-your-void-loop-clean

Although many last programmers do use delays in their code, and many don’t realise why they shouldn’t, it’s a practice that should be avoided wherever possible.
Libraries like BlynkTimer, SimpleTimer and Ticker make it easy to avoid using delays without the need to resort to the use of millis() as a way of checking for elapsed time, but the use of millis() is a perfectly valid alternative if used carefully.

The use of delays will ultimately lead to WDT issues in many situations, especially when the programmer doesn’t understand why delays are problematic.

As I said, the System.reset() command seems a clunky way to overcome a non-responsive sensor, especially if you want a constant high quality/accuracy data stream to store in a database or display via Blynk’s super hart widget, as it would most likely result in a Blynk disconnection/reconnection issue, and data loss. We don’t know which sensors you are using, and which libraries are used to support those sensors - as you haven’t included that information or code, but I would guess that there are more elegant (i.e less dodgy) ways of achieving the desired result when the sensor stops responding.

Good lunch with your quest to find a suitable alternative to Blynk, and with your C++ journey.

Pete.

Friedl_Basson · January 17, 2020, 9:49am

Hi Pete -

I am by no means looking to split hairs over a single post, I am sure both of us has better things to do.

Just some notes;

My journey always starts with the hardware and I am loyal to Particle as I have received nothing but amazing support from them and has, to date, not had any issues which has not ben addressed in a amicable manner, either form support to the forum.

With regards to your question about me posting in this forum, I was advised by Blynk Business to post here as apposed to requesting support via email.

Hi,

questions like that can be answered on our forum: http://community.blynk.cc .

I am not faulting the product, I actually enjoyed using Blynk and could see good value in the service. As you correctly mentioned, using Particle and Blynk does present some complications, but it think many platforms will have some sort of “issue” as they all seem to have many overlapping services. I will however never change my choice to use Particle hardware to better suit any particular software/cloud solution.

With regards to Delays(); I am by no means an expert programmer, not by a long shot, but can honestly say that in my brief IoT journey I have not yet encountered real issues using delays. I noticed the advice/warnings about coding inside the Void loop() section when using Blynk which is what lead me to first contact Blynk.io who then referred me here.

I have had a look at many solutions prior to Blynk and obviously chose it for a reason, but having said that, I am off to a rocky start which made me decide to rather not proceed in this direction… Well of course the sample pool is small as you were the only one that replied

Thanks again, no offence taken, just does not work well for me. When I need help, I hope to be helped, not schooled… We had to start somewhere.

Have a great day further

Kind Regards
Friedl.

Gunner · January 17, 2020, 10:04pm

Of course… Particle charges a pretty penny for their “proprietary” hardware… thus has an “Apple like” following of like minded. With Blynk (their “generous” marketing of “ease” aside), and other free IoT options, until you pay the $$$ they leave most of the “research and development” and it’s “support” up to us “free” experienced forum volunteers… which are a dwindling breed BTW

Don’t know about you… but thankfully my parents “schooled” me right from the cradle (AKA helped == schooled)… that is how I learned to eat, walk, read, program, etc.

This is not to say asking questions is bad… quite the opposite. But when the available information in this forum and documentation already answers 99% of the questions, often in great detail, then one should expect some additional “schooling” when skipping much of the reading and going the “I am n00b, so only perfectly polite help expected” route.

There… I just doubled your sample pool so you can leave justified

Friedl_Basson · January 18, 2020, 5:58am

HI @Gunner -

Thanks for replying. Careful, I might just stick around as I am starting to enjoy the (hopefully friendly) banter

I can buy a whole bunch of Photon’s before I get to the entry level price of US$1990 Blynk charges, just saying, hehe…

Don’t mistake my lack of programming skills (and the way Blynk handles Void loop() ) for a lack of hardware knowledge. I was indeed properly ‘schooled’ in that area If you have taken a product from prototype to production, you will understand my choice of MC. Particle was the last on a list we tested but ended up the one we went with due mainly to good mix of reliability, cost, available support and company values. I am not saying there aren’t other options, simply that this was our choice

Trust me they did and my bum had the proof to show They did not teach me C++ though…

This was exactly my point. I did read about keeping the Void loop() section clean. I did refer to other posts I found on this matter, so I was simply asking (as confirmation) whether it would be as simple as moving everything outside and incorporate the use of the timer function. Again… I have very limited knowledge of programming and that is not an excuse, rather a reason for why I wanted some confirmation on what I found and not sure about empty Void loops()

I get this, but maybe a simple "yes move everything outside of your Void loop() just take note of…" or “no that will not work due to…” would have sufficed. No need to “school” me on the fact that I am using a Delay() and Reset() function which had nothing to do with the question to start with.

Sorry to hear about the dwindling Pro’s in the forum…

Have a great day further and a sincere thank you for your time… Oh and thank you for doubling the sampling pool!!

daveblynk · January 18, 2020, 6:50am

I was “schooled” by my parents and by life that if I say I’m sorry no matter how right or how smart I am I get the farthest…

That’s 3 samples…

PeteKnight · January 18, 2020, 7:35am

Experience of answering this type of query in the past has led to my preference to explain the logic behind why Blynk doesn’t tolerate a cluttered void loop, especially when presents with a snippet of code rather than a complete sketch. I have a feeling that a simple “Yes, but remove the 5 second delay and use a 5 second timer instead” reply would have led to frustrations and follow-up questions later. My parents, my father in particular, would always prefer to explain the reasoning behind an answer; so that it created a better understanding of the situation - something that I also prefer to do.
This is especially true when someone’s opening gambit is “I am VERY new to Blynk”.

As far as your hardware selection process, and the statement that it “always begins with the hardware” is concerned, I don’t think that it’s as black and white as that in reality.
Some people (myself included) like Apple products. It’s difficult to argue with the innovative and sleek design of their iPhone and iPod products from 10-12 years ago compared to the competition at the time. But, you have to consider the operating system, upgradability, interoperability and range of apps available to run on these hardware platforms.
Choosing an MCU is obviously somewhat different, but some thought must also be given to the programming language and libraries that are going to be used with the hardware to ensure that the overall package is able to meet your needs.
There are some considerable advantages to choosing ESP8266 based devices that can be programmed with your preferred language. Not least that they are now embedded a large variety of off the shelf products that can easily be “hacked” to allow them to be reprogrammed to work the way that you want them to. Products such as those available from Sonoff and similar manufacturers are a classic example. They solve the single biggest problem that faces “amateur” small volume makers - that of packaging the hardware in a suitable housing which is aesthetically pleasing and fully functional.
Many people “enjoy the challenge” of making their own WiFi smart switch to turn a lamp on and off, but few achieve anything that’s as nice looking and practical as those available commercially from Sonoff etc.
As your project seems to be about energy monitoring and switching, then off the shelf DIN rail mounted WiFi products or plug-in smart switches with energy monitoring features - all based on ESP8266 technology- may be a better choice. This is of course all speculation and conjecture, as you’ve not shared details of your project, but hopefully provides some good for thought.

Pete.

Gunner · January 18, 2020, 8:16am

Always friendly (sarcasm == friendly in my world)… until someone gets nasty, then I usually ignore them… and/or moderate as needed.

But this is all good here

But they do… they really do matter (and you did include them in the code snippet)

Whether in the void loop(), which is designed to run as many cycles per second as possible, or called from the void loop()… only to then hold up that same main loop while the called function does it’s thing… is basically the same issue.

Blynk expects to get a call home to the server as many times a second, via Blynk.run();, as it can.
And if after a set timeout of no call home (5-10 seconds? I don’t remember and don’t want to look it up ) it then assumes the worst and closes the connection. Game over man!

Enter Blynk Timer… which runs in the “background” (essentially a library for high speed, non-blocking, polling to check milliseconds passed since a marker was made) and keep track of things like … well… time… all without the lackadaisy attitude of delay() which actually halts all the processing until it is finished it’s nap.

thus…

… in the void loop() or in a function that gets called by the void loop() (remember, it is the same thing)… or basically a delay anywhere in Blynkified code is considered bad form.

Could the developers have made Blynk different so all “normal” arduino styled practises of “run the loop as fast as possible… except when not…” been just fine? Who knows, who cares… this is the way it is.

Perhaps Blynk 2.0 (due sometime before 2999) will work differently.

PS, I have honestly been trying to stay away (from this forum) for longer periods of time… for reasons… (mostly due to Blynk design changes, but some due to my overloaded forum patience)… so if I mildly bark at you then don’t appear for awhile, nothing personal… I am probably napping

Blynk_Coeur · January 18, 2020, 10:34am

How many hours do you stay napping ?

Friedl_Basson · January 18, 2020, 11:15am

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.

Friedl_Basson · January 18, 2020, 11:20am

HI @Gunner -

Thank you for the feedback.

I have a better understanding now of the way Blynk works, thanks. As I mentioned in my reply to Pete, the initial code was not written knowing we would end up looking at Blynk for a solution. It was not until we realised it would require major “work arounds” to get some sort of scheduler working in Ubidots, that we stared looking at Blynk.

We will continue to test and see whether we can come up with a working solution.

Enjoy the rest of your day and possible nap

Regards,
Friedl

PeteKnight · January 18, 2020, 11:56am

Trust me, that won’t happen.
Your delay(1000) tells the MCU to do absolutely nothing for 1 second - no background processing.
Moving your code (minus the delay) into a function, and calling that function with a BlynkTimer every second, will result in exactly the same result from your data processing perspective, but allows background processing in the gaps between these 1 second timed function calls.

As far as hardware is concerned, you should look at devices like these:
https://www.aliexpress.com/item/32995570832.html
This example is only a 32A version, but there are higher powered ones.
The Ewelink app probably does most of what you want anyway, and is the same app used by the Sonoff devices (until you re-flash the device with your own firmware).
They are almost certainly ESP8266 based, and there is probably the possibility of replacing the firmware without even opening the case, using something like this:

Another thing to consider is using MQTT as your communication protocol between multiple devices, it’s the way to go with Home Automation projects in my opinion.

Pete.

PeteKnight · January 18, 2020, 4:27pm

BTW, your comments about the weak performance of your currency piqued my curiosity and I checked your location, and the admin page tell me you’re from SA.

As a result, you may want to read this topic, as it may actually be the real nail in the coffin of you using Blynk for some of your rural projects - but it may also be relevant to Particle Cloud comms and if so could save you a lot of head-scratching in future…

Pete.

Friedl_Basson · January 18, 2020, 5:15pm

Hi Pete -

Indeed you are correct yes. Ugh honestly, being in SA seems to be the nail in the coffin for many things tech related

I suppose one can look at a work-around and include yet another pillar in the stack. I know some guys at ThingsStream but as you have rightfully mentioned before, using Particle and Blynk there are already many overlapping features and complexities, adding ThingStream will just bring more. At least it might solve the connection problem as it utilises all networks, but if Vodacom implemented this, the others are sure to follow suit.

I am also not 100% sure how ThingStream will determine which network to use, if it is based on strongest network signal only, I suppose it is back to square one. Seems Particle’s embedded sims is based on the same principal, not sure as I have not used the embedded modules yet, ordered first couple now to test.

I have not had any problems with this so far, fingers crossed. Maybe the 1 post per 1s (or 4 per 4s), will be it’s saving grace in terms of Vodacom blocking access. Due to data costs (by the major providers), I will not very likely take on “live data streams” over cellular connection.

This particular project is fortunately based on WiFi modules, so no Vodacom problems there. I had a look at the link you sent about the Din rail products. I can see how that would be good solutions for Home Automation which is exactly why I am not too keen on even trying to get into that market. It seems to be flooded with decent products and it would be impossible to compete in terms of pricing as some units sell for less than the price of a MCU I would like to think though that this particular device is capable of al little bit more than a “wifi enabled relay” though

Our focus is most certainly on ad-hoc solutions where our devices can hopefully affect change and make a difference. Our area of choice to work in is most certainly agriculture, environmental and wild life, but as IoT is still relatively new here (and monthly subscription charges are highly frowned upon by clients) we need to take on other project as well to keep the lights on, haha

Thanks for the heads-up Pete!!

Regards.
Friedl.