I don’t know why they wouldn’t work then, unless they didn’t get registered properly. Do you have all the Particle.variables set up early in setup? Does the link to your Google drive have the code you’re running now? If it is, or you can update it, I’ll take a look at it.
This is the code I’m running now.
https://drive.google.com/open?id=1wRZAA8moTQ4YmlCvf0ioKPSnx83R370Y
The particle.variables are second in the setup, right after my webhook subscriptions.
@Ric actually I figured it out. I accidentally had doubly declared the variables in question; it didn’t matter before I moved the Particle.variables because the particle.variables were located after the variables were assigned values (thus negating the effect of the double declaration).
When I moved the Particle.variables, the double declaration suddenly had a much more profound effect.
Man, this has been a rollercoaster of troubleshooting that has taken me all different directions! It’s been really educational guys, thanks for all your help!
2 Likes
@ScruffR, I was wondering if you could go a little more in depth on why chars are preferred to strings, and why strings may cause the photon to sleep over extended periods?
Thanks!
Although this is discussed in the forum all over the place, I’ll reiterate.
String objects do hold the actual content of the string in a dynamically allocated portion of RAM that’s called the heap. Each newly created String object will acquire a 16 byte portion of the heap (even if it’s only a temporary object). If the string outgrows these 16 bytes, the String class will try to acquire a new block of memory double the previous size and give up the previous space. Also when a temporary String ceases to exist it’ll also give up its space. But since these spaces are small and scattered all over the place chances are that this given up space won’t be of any use for other objects either and hence the free space will be ever decreasing over time - this is called heap fragmentation.
And if your program is running long enough you might find yourself in a situation where the heap is so fragmented that a new attempt to allocate memory will just fail, often resulting in a system crash (mostly due to user code not expecting this and hence not guarding against it) or - as is for system functions - just fail gracefully by just returning a non-success code without a crash. And that can manifest itself in the inability to reestablish a lost cloud connection.
With char arrays the user code is much more in control of matters and hence such issues won’t happen or will at least be much easier to pin down while debugging.
3 Likes
Thanks for taking the time to explain that; sorry for asking rather than searching, I got a little too comfortable in this one thread. Thanks for all the help everyone!