UPDATEall of the below boils down to tinker not working on this one device; not working meaning the functions were not showing up in the particle cloud. Somehow the device was locked out. By some miracle overnight the lock out was cleared and tinker now works.
On an ELECTRON (HIGHLAND-ROAD1) both before and after firmware 5.0 (see WEB IDE screenshot), I lost the ability to see my particle functions on IFTTT. I now used a debug dashboard (see screenshot) and the function is still AWOL (MIGHT-MOUSE is a Photon with Tinker; they show up nicely).
The sketch is from the reference document with added Serial.println to show it’s running (see screenshot; it prints every minute).
I notice what might be a clue. HIGHLAND-ROAD1 keeps its on-line status on Dashboard even though it was powered off completely for 3hrs. I logged off and on to ensure the display was updated. Curiously, the problem from the IFTTT side is that the device is dim ( I assume unavailable). Because the dashboard is wrong, I’m assuming the problem is in the Particle cloud. The sketch run was flashed using --serial. The compile was using WEB IDE and I used extreme care to prevent any mixup with .bin file. I only have 1 email address so there is no registration problem ( IFTTT sees all my published events from HIGHLAND-ROAD1). I’ll try flashing tinker on the ELECTRON to see what happens. But, regardless something isn’t right.
(in other testing I’ve verified that the return status for Particle.function is 1).
UPDATE******
I just setup a new ELECTRON. The tinker functions showed up as they should right away on the Spark dashboard (after a display refresh). Can someone at Particle take a look the particle cloud and see why HIGHLAND-ROAD1 (now renamed MATH-DOG) is locked up?
UPDATE******
Using WEB IDE, I compiled and flashed tinker. no functions appear on SPARK dashboard, mobile device says online non-tinker.
Try registering the Particle.function() before the delay(5000).
That’s known behaviour due to the connectionless UDP transport used on Electrons while WiFi devices use TCP.
Last heard is a better indicator of online status for the Electron.
- Thanks. Will do. Also going through the 5.0 firmware post to be sure I did everything.
- I don’t hold out much hope as tinker doesn’t work on this device either. I’ll use the tinker flash procedure in firmware update post to make sure.
- I also added link to a post as you recommended. I fell in to the trap of assuming hyperlink was for external references.
- I put myself on watch for the firmware update thread. This was my first update; and I really didn’t understand the firmware update process. And in truth still don’t understand the difference between a --serial flash and a DFU flash. I thought the DFU flash from the batch file you gave me would update the firmware?
particle flash --serial is mainly solution for convenience since you just need the the standard serial drivers, where
particle flash --usb requires you to have dfu-util and the respective drivers installed.
But if you have DFU set up already, I’d always go for this as it is also safer.
With serial you could even attempt to flash incompatible files (even just a text file) and would only see (or not even) that your old firmware just persists, but DFU would explicitly tell you about that fact.
That is true for the application firmware (your code), but the system firmware is stored at two other locations in your device and hence has to be flashed seperately - you’ll notice that the system firmware comes in two seperate files too (part1 and part2).
BTW:
- What colors does your RGB LED report?
- Can you OTA flash a very small sketch, just to check the connectivity?
- What does
particle serial inspecttell? - Could you swap the SIMs between your Electrons?
FYI and future reference. Everything is working great today. The brew function example runs great. I made no changes no updates. Last night no go; my mobile device said non-tinker. The spark dashboard that JordyMoors gave me showed no functions for my device (yes I refreshed display). This morning everything is working exactly as it should. My guess ( I’ve been programming systems since 62 including first ever GUI, first ever multi cpu system, first ever micro processor programmed it by cutting diodes off the board) is Particle did an update or has a daily or weekly clean up that unlocked my device at midnight. thanks for all the help - actually my old world experience makes it hard to switch to the cloud world. The errors stay the same though.
- You suggested putting the Particle.function() before my delay(5000). I did and no luck. But you’re on the right track; it is a time or state dependent error.
- I started with the basic brewcoffee example in the reference. it worked. I added small increments of my code testing at every increment.
- Everything worked great until I added some substantial delays before the Particle.function(). My code may be non-optimal and perhaps illogical, but my delays should not impact Particle.function().
- I have lots of debug. I like to time tag my debug records. So right up front I put the loop to wait for a valid year (>2000). I also put while(!Particle.connected()) and while(!Cellular.ready()) waits. Goodby Particle.function.
- Then I moved it right up to the start of setup() and I had my function once again on the atom cloud functions tab or pane (yes I always refresh the display by selecting the device anew). This is all somewhat illogical to me because time, connected, ready, appear to me as prerequisites for putting my function on the cloud. Waiting for one shouldn’t harm any of the others.
void setup()
{
int i;
debug_status = true;
Serial.begin(9600);
Particle.function("XFN", PFunction); // register the cloud function
waitAwhile(5.0);
Particle.connect(); // be sure connected
//----------------------------------------------------------------
//wait until time is avaialble from cloud
int y = Time.year(); // test to see that Particle has obtained time from cloud
bool wait = true;
i = 0;
while(wait)
{
i ++;
s = String(y) + ", " + String(i) + " in setup() waiting for time";
Serial.println(s);
waitAwhile(1);
if (y < 2000) Serial.println("no good");
if (y >= 2000)
{
Serial.println("good" );
wait = false; // all done time is initialized
}
y = Time.year();
}
while (!Particle.connected())
{
if(debug_status)
{
Serial.print(Time.format(Time.now(), "%I:%M%p "));
Serial.println("in setup() waiting for cellular connected");
}
waitAwhile(1);
}
while (!Cellular.ready());
{
if(debug_status)
{
Serial.print(Time.format(Time.now(), "%I:%M%p "));
Serial.println("in setup() waiting for cellular ready");
}
waitAwhile(1);
}
The above snippet works; if the Particle.function() is moved to the end the function doesn’t appear in the cloud. waitAwhile is a while loop that uses millis() to run out the delay arg *1000. (1 = 1000 ms).
You can already register a Particle.function() even if you have no cloud connection, since this registration only happens on the device.
The cloud will (currently) - once connected - pull in the info about what Particle.xxxx features got registered - but only once (or maybe twice) a few seconds after the connection got established. If you haven’t registered it by then already, you’d need to disconnect, wait a few sec and reconnect again.
But late-registration and triggering the cloud to pull the new set of exposed functions, variables and subscriptions is planned.
BTW, heavy delays will also affect the responsibility of your code for cloud calls.
wow thanks. that should be in reference. I wasted much time. But I learned much along the way.