Experience is what we call our mistakes. As I advance, I hope I’m to make a trail for others. Age teaches us that we are seldom alone in our problems. Many of my errors are misinterpreting the documentation; so my missteps may lead to documentation improvement as well. My experience includes a Photon tweeting the water tank level and data based on a ultrasound sensor.
-1. I’m using an HP Envy laptop with USB ports and Windows 10. The Electron shows up as COM3 and using Tera Term for problem free I/O. Just remember to Disconnect before flashing --serial.
-2. Occasionally I have to restart my PC because of screwed up serial interface
-3. Some as of now unknown errors are screwing up my Electron… I have to go SAFE mode to flash it.
WHAT I LEARNED IS: ignore the PROTIP to get blinking BLUE. Just flash it while in SAFE mode.
-4. The WEB IDE compile error messages are a mess. The line #'s and the displayed cmd line don’t match. It appears to be just whatever text happened to be in some buffer.
WHAT I LEARNED IS: a) focus on the line #; and b) the errors cascade so fixing one or two at the top will often fix many of the others that are not true errors.
-5. Based on the D7 blue led on board, the user app doesn’t run when the Electron is turned on with the reset button. It doesn’t start blinking until the green flashing stops and normal breathing mode is indicated. DOES THIS MEAN that my app will stop if the cell connection is lost? This could be bad because I’m controlling a critical function.
Thanks for sharing your experiences!
- 2, If you haven’t already done so, try restarting the program, rather than the entire machine. That often suffices.
- 3, There are different ways to flash your electron. During ‘normal’ operation, you can do this OTA. In ‘blinking blue’ (listening mode), you can do this over Serial. In ‘blinking yellow’ (DFU mode), this can be done by using DFU-UTIL. Safe mode just doesn’t run user firmware but acts as ‘normal’ mode, thus should accept OTA flashing, which is what it’s made for. If, however, you want to save data, you’re better of using either of the other two methods, one of which will require blinking blue, thus the Pro Tip.
- 4, Agreed, the Web IDE isn’t as pretty as it could be, but this is being taken into consideration, and change will hopefully happen soon.
- 5, Pressing the reset button is the same as power cycling, so there’s nothing ‘special’ about that. Depending on how you coded it to act, it may, or may not, wait for a connection before executing your user code. Should you which to change this behavior, have a look at both System Modes and Threading.
Thanks
-5 a separate system thread sounds perfect. Because of beta status and my development status I’ll wait till things are stable. But w/o it being blocked while system is looking to connect is a killer.
-3 the error killed connection so, no OTA. serial flashes failed until I did the serial flash while in safe mode ignoring PROTIP.
System Modes will fix the “blocking when not connected” problem. I highly recommend you follow the link that @Moors7 provided on the topic. Thanks.
-6 well I found one cause of strange weird behavior. I noticed that I had less problems when my electron was standalone. I was grabbing power off the 3.3v pin for the power track on my bread board. I screwed up and had one LED ground going to the + track instead of the grnd track. There was enough voltage difference to light the LED; but the error caused all sorts of problems in the Electron. So watch for wiring errors if your Electron starts doing weird things.
No, thank you; will do
Is "System Thread" already working reliably?
In the documentation we still read:
System Thread
Please note: The System Thread feature is in Beta - we advise only using this in production after extensive testing.
This is a known (but still annoying) issue caused by the wiring preprocessor.
The line number and the code excerpt of the error message show a constant displacement (no buffer residues), since the preprocessor adds several code lines "translating" the .ino file into a .cpp.
If you use #pragma SPARK_NO_PREPROCESSOR and add #include "Particle.h" and any required forward declarations, you'll find the line number and code excerpt will mach up again.
On the Photon I am using the threading since a long time and never had a single issue with it. On the Electron it does not exist, yet.
Define "reliably" 
It works very reliable (where it exists - see above post) common use, but you can always break it if you e.g. try to grab a shared resource (as WiFi, Serial, ...) in a non-cooperative way.
@ScruffR OK! I have no such destructive intentions… So, good enough for me!
I definitely need to test this, as it will probably improve the stability of all Photons I use. Now, often they start blinking for quite some time, trying to establish a connection and the loop() stops!
For #3, I’ve been using the DFU-UTIL but have only been able to get the “breathing green light” after flashing it. If I were to flash it in safe mode, you’re saying it would “breathe cyan” and connect to the cloud? Or did you mean you tried putting it into listening mode and it failed to flash? I had that happen for awhile and that’s why I switched to DFU-UTIL.
Thanks in advance.
I can see #3 is less than clear. My electron got in a very confused state - no connection and every color light blinking. I couldn’t download my previous software version that I knew worked. I thought SAFE MODE might kill my suspect latest software. So I tried a particle flash --serial. It gave me a PROTIP to get the blinking blue. But, I wanted SAFE MODE so I just hit entered and my Electron was salubrious once again. So all I can say for sure is one can ignore the PROTIP and particle flash --serial in safe mode. By the way, I must be getting senile, because I don’t really understand the difference between particle flash and DFU-UTIL. I need some enlightenment here.
-6 As I mentioned earlier, I confused my Electron with a connection error. I used the 3.3V pin to power a breadboard buss ( the whole edge - is buss the right term?). I mistakenly grounded an LED (the LED worked!) in the power buss instead of the gnd buss. Does it make sense to use a diode to ensure no feedback ( is that the right term?) to the Electron 3.3V pin? If it does, that simple precaution could save hours of frustration.
wow double wow. It works! I'm so happy and it's not even 9:00am. Thanks, thanks, thanks.
can you explain why quotes in "Particle h." and the angle brackets for math.h
Depending on which method you choose particle flash --serial or particle flash --usb you're either using a Serial connection, or DFU-UTIL to flash firmware. DFU-UTIL is a tool to flash devices in DFU mode, and the CLI makes use of that.
-7 the reference manual section on time doesn’t pass the idiot test (me). I can’t figure out how to Serial.print the formatted time example Time.format(Time.now(), “Now it’s %I:%M%p.”);
Great example, but, not complete (completeness is impossible so how about one or two more steps please?).
-7 The example in the manual could be better.
String str = Time.format(Time.now(), "Now it's %I:%M%p.");
Serial.println(str);Putting Serial.println() around it wouldn't have hurt to try
Serial.println(Time.format(Time.now(), "Now it's %I:%M%p."));
The difference is the search path the compiler uses to locate the header file.
With double quotes the compiler starts searching in the project directory and after that transitions to the toolchains own paths till it hits the first occurance of that file.
With angled brackets the compiler won't search the project folder.
More info here
The C Preprocessor: 1. The C Preprocessor
These are usually refered as rails but bus is OK(ish)
You can use it. If you want to add a protection diode in the 3.3 line, you should go for a schottky since you want the lowest possible forward drop (0.2V for Schottky 3.3 -> 3.1V)
Printing the current time is even easier than the given suggestions
Serial.println(Time.format("Now it's %I:%M%p."));
And for possible other formats have a look here
http://www.cplusplus.com/reference/ctime/strftime/