[SOLVED] Particle Variable and Function registration when using THREADING

Troubleshooting
1

If another post I asked:

Is anyone having problems with 0.4.7 not always registering variables/functions in the Particle Cloud? In other words, Particle CLI list does not show any Variables or Functions (and the device is online). ....

I now say:

The problem only occurred for me with SYSTEM_THREAD(ENABLED), when DISABLED it registered okay in the cloud. The problem was not consistent across devices, ie it worked okay on some devices.

The same issue came up with firmware 0.4.6.

The fix was to move the registration calls early on in the setup() function, not down amongst it where I was waiting for Particle Cloud connection to come up before registration.

Case closed!

1 Like
2

Glad to hear you got it working, although I’d still like to see your code to reproduce the issue. The functions and variables should appear no matter where they are in startup.

3

@mdma, the code (some 7000 lines of it) is pretty complicated (and no doubt the issue)!

Hopefully I will be able to set up some test code that reproduces the fault and get this to you if it does.

Note that I was waiting for WiFi connected and Particle Cloud connection before registration. Did this because prior to v0.4.6, I found that when there was no WiFi connection, the function registration blocked for some time. Have not checked if this block occurs with 0.4.6.

Back shortly.

4

@mdma, I said:

I found that when there was no WiFi connection, the function registration blocked for some time.

FYI just measured how long it blocks for, around 100 secs. This is a bit long.

5

When calling system functions, like Particle.variable() the application thread still has to block waiting for the system.

In the meantime, a workaround is to use SEMI_AUTOMATIC mode, and have:

void setup()
{
    Particle.variable(....);
    Particle.connect();
}

We can avoid this by taking additional steps to make some of the internal code truly thread safe so it’s run on the calling thread, rather than always on the system thread. This will happen in a future release. (Multithreading is still beta so we can work out these issues.)

6

@mdma, yep, have a define for enabling SEMI_AUTOMATIC mode!

I had originally had it in this mode and then changed to AUTOMATIC with the upgrade to 0.4.6.

Now see, with thanks, that I should have left it the way it was.

Am getting on with the reproduction of the original issue (and of course, no issue so far…)

7

@mdma, of course, could not reproduce the fault with my scaffold…

I will report back if ever I come across it again and have more information.

Conclusion: not reproducable, not worth chasing at the moment.

Thanks @UMD

8

Thank you for investigating - much appreciated!

9

Hey guys, I’m migrating an old app to use multithread and I’m experiencing this issues running 0.5.1.

Once I moved the Particle.variables and function declaration to the top of the Setup{} the problem goes away.

10

For what it’s worth, this issue still exists in 0.6.2. I have to move my function declarations to the top of Setup() to get them to register (semi_automatic / system thread enabled). Glad this thread existed, but I wouldn’t quite call it [SOLVED] yet.

11

I can confirm this issue still exists - my setup was like this:

SYSTEM_THREAD(ENABLED);
SYSTEM_MODE(MANUAL);

void setup() {
    Particle.connect();
}

void loop() {
    if (Particle.connected() && !hasRegisteredCloudFunction){
        bool result = Particle.function("asdf",asdf);
        hasRegisteredCloudFunction = true;
    }
}

The function did not register even though result was being returned as true. I had to move the function registration to the top of my setup function prior to the call to Particle.connect() for it to show up in the particle console.

12

Here is the github issue for this:

Basically the message to the cloud that describes all the functions and variables is currently sent once and asynchronously with respect to user code during setup().

This requires both the firmware side and the cloud side to change in order to fix it and there is an easy work-around (declare early) so I don’t think this is currently scheduled.