I developed a couple of Photons to control my home automation a few years ago, I’ve finally got around to getting some PCBs printed so thought I better sort out one or two bugs / niggles.
The problem I have is after a period of time, one of my Photons starts to run slowly, e.g. one of the functions is to switch on a Hue bulb using a wired PiR. When the Photon first boots, it switches the light on in a second or so of activating, after a period of time (perhaps 20-48hrs) it can take upto 5-10 seconds to activate.
I expect I have some code which is causing it to slow down / loop… my problem is how do I track the dodgy code down? I’ve looked at Particle Console when it’s running slow and the message to switch on the light is being delayed when slow running so I can rule out certain functions related to Hue control etc but have never delved into this kind of debugging before…
Is there a way to hook the Photon up via USB to look what it’s doing? Or anyone have any suggestions on how to track the dodgy code down or see what it’s doing externally?
One thing you should keep an eye on when you have such delayed symptom development is System.freeMemory(). You may be seeing some memory leak.
The next thing could be heap fragmentation which is more difficult to pinpoint.
And finally you may have some problem with the overall logic which can only be tracked down by looking at the code itself.
The first thing to debug such an issue would be to add a bunch of log statements at strategically useful places and monitor relevant variables and states - that output can then be monitored via USB.
Thanks for the pointers, it’s been 18+ months since I touched the code and whilst I can pick things up quite quickly, never actually done any of this before. (Always just used the web interface to do everything)
Can you point me to how to implement the logging and reading of logs via USB? - I’ll then Google your other pointers to get a better understanding of what that actually means and add appropriate logging of variables etc after scanning my code! (some of it is in library’s which will probably be more difficult, but hopefully if I can “see” something via logs I can narrow it down! )
P.s. The Photon is powered via a track on a PCB and separate PSU, if I plug in USB, will that cause any power related issues? (Don’t want to blow the USB on my MacBook!)
There is a diode between USB and Vin that prevents back-feeding voltage from Vin to USB.
If you were powering the Photon via the 3v3 pin you may want to use a USB cable that breaks the Vcc line between Photon and computer.
Thanks @ScruffR, that’s most helpful (it’s powered via Vin)!!
I’m cleaning up my code now and splattered several if(DEBUG){} sections to hopefully allow me see what’s going on! - In my haste to tinker, I’ve also managed to damage my PSU powering the PiRs but whilst I wait for a replacement, I’m running the following every 15 seconds to see if that changes over the next few days.
Currently its stable at 47976 - After googling Heap Fragmentation, I now better understand it and have cleaned up parts of my code. In the event that I can’t track the cause down (or it’s in one of my library’s), would a system.reset() each night fix Heap Fragmentation as an interim fix? or is there a less severe way to clean it?
If it's heap fragmentation then a regular reset should help that.
The best would be avoiding anything that regularly allocates and frees heap space (e.g. String) but other than that there is little you can do when your own code is not the owner of the dynamic entities.
Just an update for anyone reading this in the future, I went through my code, tidying it all up and optimising various parts, I left one section with a comment of “This needs a lot more work” and unsurprisingly, after commenting out that section from my loop(), the slowdown has stopped and the Photon has been running normally for 48hrs !
The code in question is to control a keypad, via a MCP23017 chip, using two different libraries (Keypad_I2C & Adafruit_MCP23017) and some code I’ve copied from somewhere. I’m going to wait for my printed PCBs to be delivered before debugging further and likely starting again with that keypad code!
(some of it is in library’s which will probably be more difficult, but hopefully if I can “see” something via logs I can narrow it down! 
)
- In my haste to tinker, I’ve also managed to damage my PSU powering the PiRs but whilst I wait for a replacement, I’m running the following every 15 seconds to see if that changes over the next few days.
