Request: Particle endorsed Semi Automatic, Thread mode test case .ino

You are correct, I used to have more code in the if statement to ask my server if I should go into safe mode (and tell me it is doing so) or keep running code.

1 Like

Hi @UMD, a COIN project is a nice idea, and effectively historically how Particle has operated. Which obviously isn’t good enough when a) their code stops working and takes a year for bugs to be resolved (ie mac.address) b) it’s becoming reasonable to now assume that there isn’t actually internal test cases already operating to validate firmware as part of CI or cloud operation. That’s bad news.

Particle needs to provide their test case code for semi automatic, system thread with particle cloud reliably connecting, subscribing and publishing. Community maintained is useless when Particle firmware keeps changing, cloud behaviour changes and bugs are running rampant.

Let’s presume B) is true, the cupboards are empty. We can accept that and move on quickly. A particle employee should put up their hand and admit as much, then thrash out some code with the guru’s in the Particle team and offer it up in a repo for validation.


Let’s tag a few more people. 16 days radio silence with no code offered is a concern and it’s apparent it’s not just the crazy australian who is keen on some official movement.

@zachary CTO
@will community
@avtolstoy as he’s a legend who knows the code well and fixed the most recent 1.4.2
@mdma as the original genius behind all the HAL and low level coding a few leagues beyond my skills

Hi. To get things rolling (it’s awkward that we have to do this…) but here’s a COIN like repo for comment/advancement. I do anticipate we’ll have someone from Particle step up to the plate but maybe this will help them flesh out what we’re trying to validate.

@mterrill, let’s get this show on the road!

Will review particle-skeleton and contribute when I can and hopefully others will also get behind the project.

I do note that a lack of good sample code seems to be a common problem within the embedded controller industry.

1 Like

Hey folks,

Good conversation here, and want to make sure that you know the lack of response from Particle has not been avoidance of the conversation – simply a lot going on internally and didn’t get the ping until you tagged me 16 hours ago :smile:

We have been (re-)developing a sample application model that can act as both a common reference app for evaluating device performance across Device OS versions as well as providing an instructional model for customers who want to know how best to implement thread-safe publishing on the Particle platform.

It’s not quite ready to release yet, but already exists and should get there in the next handful of weeks or so given our current team event and travel schedules. @rickkas7 has been driving development. Our intention is absolutely to make it available to customers and to the community.


The list of examples is still being refined, but there will be several. I’ll be sure to include the features in the original post. There will also be examples using cellular in various modes with various sleep modes, with information about power and data usage trade-offs and of course working code.


Great stuff. If you compile my code you’ll observe that the last publish statements in the setup block don’t actually publish. I did the hacky subscribe / publish in the loop because it seems cloud registration timing and reliability has changed. Our beta code using 1.4.x firmware stopped reliably connecting / publish / subscribe.

While other more rounded examples will certainly help the community, selfishly I’d really love honing in on the core process of wifi connection / cloud connection / subscribe / publish. That behaviour has changed dramatically since 1.1.x with how Particle.connect now needs wifi.connect, and I presume the recent cloud registration issues are due to timing and changes to the backend.

The code I provided is quite stripped down, it has some necessary weight due to test functions but aside from that is quite minimal.

Juggling the sections around to your recommendations or adding recommended recovery / watchdog / waitfor logic should be pretty easy I hope!

For customer context, I’m currently held up by 3 weeks, waiting to release firmware features to my customers after observing the subscribe / publish cloud issues. If they don’t reliably work then we’ll have devices that don’t retrieve their configuration or listen to configurations actively sent to them.

Thanks Will for jumping in. To be fair, it would be a matter of ten minutes for Particle technical staff to code a basic sketch of connecting, publishing, subscribing from scratch. Aside from being able to code that off by heart, there surely must be some code sitting on a network drive or github repo being used right now to validate Particle firmware.

A broader sample application is a noble goal, but just the stripped down core processes would be sufficient. Editing my posted code and sharing with the group their forked code would be a fast starting point and open the conversation to the talent participating in this thread.

Last comment. I think the core of the topic is:
“What’s the Particle recommended code between Particle.connect and .subscribe() and the first .publish() ?”

It could just be a 10 second delay. It could be ‘check for Particle connected in the loop, just like you’ve done in your code sample‘.

That’d be enough to keep us going and release our new firmware with satisfactory confidence and I’d wait with interest for the sample application.

I did some more research and experimentation with the skeleton code. Using system mode automatic and system thread enabled I was able to connect, register, publish reliably.

Also was able to do our customised method of interrupting particle.connecting and trigger listen mode so users can configure wifi creds via softap so it’s not stuck hammering a set of known wifi credentials and it not working.

So in the automatic mode code it correctly connects, subscribes, publishes. So I guess the challenge is to surface that approach into userland code for semi-automatic.

Take a look at the ‘humble’ Arduino community - their IDE, when installed, provides a standard set of examples that will work on any of their boards and they have a way more complicated mix of products than Partilce. These examples provide the “go-to” reference to make sure the boards function work as expected. This would be of immense value for developers staring out with particle’s platform - it very easy to forget (when your skills are way up there) that for anyone starting out (and even for the pros from other platforms) - that what is trivial for you is totally foreign to them.

So don’t try to make an all inclusive monster app that showcases everything - it will be impossible for follow and isolate sections that someone wants for a particular reason/project. Also use basic to mid-level C complexity (i.e. avoid pointers :slightly_smiling_face: and rather call libraries that have all the clever C++ bits, again this makes it much easier to follow for both beginner or experienced coders.



Re Particle authored sample code, great news!

@mterrill can’t help on your .subscribe() woes - the last time I looked at it was 2015… yep, five years ago… it was problematic for me back then…

@mterrill see if this code helps you. It is called once in setup().

/// Connect with WiFi and Particle Cloud
int EstablishComms(void)
		// -------------------------------------------
		// Wait for acquisition of WiFi AND IP address
		// -------------------------------------------"W.conn");
		WiFi.connect(WIFI_CONNECT_SKIP_LISTEN);  // NOTE: No need to ever call again, it keeps on trying

		if (waitFor(WiFi.ready, 30000L))
		{"W.rdy-wait IP");
				if (waitFor(WiFi.localIP, 5000L))
						// Good to go for Intranet"IP OK");
						Log.error("W.rdy-NO IP");

		// Have both WiFi.ready() && WiFi.localIP()
		// ----------------------------------------

		// Following moved to WiFiStateMachine()
		// char szWiFiDetails[150];
		// LogWiFiDetails(szWiFiDetails, sizeof(szWiFiDetails));

		if ((configs.fMode2 & MODE_2_FLAG_INTRANET_ONLY) &&
		{"!INET P.con NO call");

#if defined(MANUAL_MODE) || defined(SEMI_AUTOMATIC_MODE)
		// Need to actually kick off a connection with Particle in these two modes"P.con");
		// Connects the device to the Cloud.
		// Automatically activate the *Wi-Fi connection* and attempts
		// to connect to the Particle cloud
#endif  // MANUAL_MORE || SEMI_AUTOMATIC_MODE"wait4 P.con");
    if (waitFor(Particle.connected, 5000L))
    {"EC->P.con OK");

        // ---------------------------------------------------------------
        // We are connected to the Particle Cloud!!
        // ---------------------------------------------------------------
        // ---------------------------------------------------------------
        // Potentially register interest in Particle Cloud generated 
        // events here.....
        // ---------------------------------------------------------------

        // Following moved to WiFiStateMachine()
        // gbLoggedWiFiDetails = true;	// Only want to report once per session

    }   // if (waitfor(Particle))
				// timed out waiting for Particle Cloud connection
				Log.warn("Tmout cloud con");

				if (configs.fMode2 & MODE_2_FLAG_INTRANET_ONLY)
						// Stop WiFi from being disconnected all the time
						// due to Particle Connect behaviour"Intranet W.rdy %d P.disc", WiFi.ready());


} // EstablishComms()

Hi @UMD, thanks for the code, but Particle need to provide the code that actually works on their cloud. It’s like a million monkeys writing hamlet, there are only fragments available.

It seems the validation code for semi automatic system thread does not exist, though it’s something that Particle are working on in the background.

@mterrill, got it.

Sounds like we should close down the skeleton code project then?

PS - The example code should, IMHO:

  • handle NO CLOUD connection
  • keep WIFI up for intranet only applications
  • continue to try and connect to WiFi and the Cloud without undue blockages

This points to the use of a connection state machine… (as @rickkas7 has shown in the past)

There will be a several code examples, to be determined. We’ll probably publish those sooner rather than later. The second part of this will be integrating these examples into the end-to-end tests run on Device OS releases, to make sure that new releases don’t break the recommended model.

1 Like

Would it help for me to file bugs on the github? Currently the code doesn’t work if you put everything in sequence, and after 3 weeks it seems it’s not known at HQ how to structure logic to make sure it works. By process of elimination that means it mustn’t be working, ie the code is faulty.

I’m currently testing turning off semi-automatic mode as it’s been 3 weeks and I need to ship features.

Edit: BTW back in the day we used to need semi-automatic mode to directly influence listening mode with ISR’s etc with @peekay123’s timer libraries. At the moment it seems I can get most functionality without semi-automatic and the sequential list of commands works. Hence my comment that’s actually a software bug with semi-automatic.

I tripped over the particle test case directory when checking out some of the commits/patches for the latest 1.5.x production release.

They’re all sitting here:

There’s a skeleton semi automatic test:
(edit: but it doesn’t cover cloud functions etc etc)

There’s a rather old cloud test app from 4 years ago, which wouldn’t work with semi auto:

An interesting test that checks system processing and listening mode:

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.