Hey @ksprayberry – I totally understand and agree that your experience sounds like a frustrating one. Our intention is for the development experience to be much smoother than what you described.
If you’re willing to share your Device IDs and source code with our developer support team, we can take some of the “troubleshooting” burden off of you to get your devices into a good state. You can do so by shooting a note to our team at http://support.particle.io
I think I just got the Argon flashed with both the firmware and I got the ncp on it. So maybe I’m on a roll. I’m going to use CLI to make sure the Xenons are flashed right now. If I run into issues, I’ll definitely take you up on the offer. Remember OCD is great as long as it’s pointed in a useful direction.
So now I have both the Xenons and the Argon flashed over and breathing cyan again and I was able to ping all of them. I think the next thing I need to do is get a better understanding of how to flash my program using the CLI instead of the Web IDE. If I’m undestanding it all correctly, if I have my ino file and then all the libraries… ccp, .h files, etc. in a directory, any directory, then I can go to that in the command prompt mode and compile it and flash it. that might get me around all this file or directory not found business. On to that next.
You know what would be helpful? I’d really like to see a video or two of the argons or xenons with someone flashing a fairly complicated program with multiple libraries. Either by way of the IDE or using CLI. I don’t know what I’m doing wrong, but I can’t get anything to upload on the web ide that has a library (DHT) and I’ve been trying tonight to upload a DHT11 program (using CLI) and it just stalls out and says something to the effect of …target/workspace.elf failed. On the web ide it always says Missing file or directory.
I’ve left my mesh running since my last post here last night. It seemed to working properly. After 20 hours without touching anything, I started power cycling the xenons while leaving the argon alone. They consistently reconnected flawlessly and took anywhere from 3-6 seconds to get from receiving power to breathing cyan, which seams to be working properly.
The Argon was basically running code printing sensor data from the xenons to an OLED and also printing its uptime. I made it to 23 hours, 45 minutes, 11 seconds and the Argon appears to have hard crashed. The LED is breathing cyan, the OLED is not updating, and D7 which would indicate incoming data from the xenon is stuck on.
The console ping for both devices shows them as unreachable.
The Xenon LED is flashing green and the D7 LED is blinking to indicate it is still running through the loop sending the sensor data.
Edit: After 30 minutes like that, I pressed the Argon’s reset button. After about 25 seconds the Xenon went back to breathing cyan and the system appears to be working again.
My 2 cents… I love it when it works, but v26 isn’t the step forward I was hoping for. I’ve currently got an argon gateway, and 2 xenon slaves. As I mentioned in another post, my gateway (an Argon) rarely makes it more than 8 hours before needing a power cycle. Without the power cycle, I can’t signal or flash either xenon. The argon is running a trivial program (the LED/light sensor with published variables/function example). Pretty sure I could signal the argon before rebooting it, but need another 8 hours to verify that). The xenons were still succesfully communicating between themselves with the mesh.publish/subscribe even though I couldn’t contact them, so pretty sure the problem lies with the gateway.
Thanks for the report. This sounds like a deadlock either in the system code or the user application. Do you use SYSTEM_THREAD(ENABLED) ? Since you are saying that the device is not reachable from the cloud, it sounds most likely that you are not, so adding that should help figure out where the deadlock comes from: system code or the application code. You can also PM me the application and I’ll take a look at anything suspicious.
UPDATE: I’ve uploaded new binaries that enable logging from an ISR.
I would appreciate if you could flash the following debug system firmware. They will automatically log on Serial1 @ 115200, you should not instantiate Serial1LogHandler in the user application. Unfortunately we cannot reliably log from an ISR to Serial. If you don’t have an UART-USB adapter, you can use another device running a simple app and connecting its RX to TX of the device being debugged.
@avtolstoy Thanks for your reply. I’ve sent you the code I’m running on the Argon.
I don’t use SYSTEM_THREAD(ENABLED). Other than a few short delay()'s in Adafruit’s SSD1306 library, I don’t believe I’m blocking anywhere in my code, though I stand to be corrected. It is just a quick simple test program and I haven’t taken the time to do more than quickly scan the libraries I’m using, so it is perfectly possible that my code or the library is getting stuck.
I can add SYSTEM_THREAD(ENABLED), my understanding is that would mean if the Argon becomes unreachable from the cloud again, the problem is in the system code, and if the program locks up but in remains reachable from the cloud, the problem is in the user application, correct?
What DHT library are you using?
I’ve tested PietteTech_DHT with a DHT22 and that works fine for me (just make sure not to expose the input pin to more than 3.3V).
The only thing you might want to change in the DHT_simple.ino (apart from #define DHTTYPE DHT11) is to add a delay(1000); as last line in setup().
Once you updated your device to rc.26 (which can be tricky from Web IDE, due to some rc.25 bug that needs to be overcome first, before actually updating, making the process rather long) you should not have any further issues flashing rc.26 applications OTA with Web IDE.
You can also stick with Web IDE to actually build your application and flash the binary via CLI.
If you hit the symbol next to the project name Web IDE will build your project and download the resulting binary which then can be used for wired flashing via particle flash --usb firmware.bin -v.
But make sure that you actually have selected the correct firmware target in Web IDE
I was able to use CLI to upgrade the firmware to the latest RC.26 for my Argon and the 2 Xenons and updated the NCP or whatever its called for the Argon, so I think I’m good to go there. I am using this DHT1.3 library below. I think I’ve tried everyone of them and it gives me a file or directory not found. Anyways, if you say the PietteTech library has worked, I’ll give that a try then. Did you flash it by way of the Web IDE or using CLI? I’ll give it a try. I have it on the Grove shield with the DHT prewired kit, that has the 3.3 volts routed to it, so I think I’ll be okay and not expose it to more than 3.3, but we’ll see. Thanks for the help, I’ll give it a try.
Thank you so much for having patience. Not only did I get the program to flash, but I was able to add the particle variables and particle publish to the code and get it to work as well. Huge confidence booster. Thanks for putting up with me.
Will give it a try today, a good excuse to hook up the debugger and learn how to make it work At least I assume it will capture the serial output for me… Was in my usual broken state this morning, and can verify that I can signal the argon when in the broken state (but not the xenons). Power cycled the argon, and can now signal and interact with at least one of the xenons. The second xenon was slow to start and complete the green light ‘reconnect to network’ process, and then was still not accessible - although happily running my code and responding to mesh network events. Power cycled the second xenon (had been running 2 days) and its now accessible. Will give the debug firmware a try.
Since last time I posted, my uptime is now 44 hours and there’s been no problems. I haven’t touched the devices and just periodically checked to make sure events are still being published from the Xenon, which they are without fail. I’m running the exact same code as before except that I added SYSTEM_THREAD(ENABLED);.
I’m going to start power cycling the xenon to make sure it reconnects properly, but I doubt that has anything to do with the crashing before.
So it seems, to work now but it’s already proven itself unreliable. How do you get to a point where it can be trusted for anything important?
Hmm, not sure how to take that
Since there were problems in the past (which - as it seems - were addressed and many of them fixed) there will not be any redemption for “past sins” - no matter what, even despite …
By more testing, finding more (previously not found) bugs, fixing the ones not yet fixed and further improving on basis of what we already have.