We’ve been using particle.functions triggered by input from the cloud console to configure field devices for a long time. Typically these devices are running 0.8.0. This process has been very reliable until today.
This afternoon I needed to change come configurations and attempted to run the functions as I have in the past and was greeted with the “Bummer! Failed to call” timeout response. This is odd as we have a specific stage in the firmware where the application listens for function calls and has no competing processes etc. As I ran repeated attempts to successfully fire the function, I finally received a ‘spark/status online’ event, and immediately the next function calls all worked flawlessly. One unit updated… Now I go to work on a second, so far (after 5+ attempts when the e-series wakes up out of deep sleep) I haven’t succeeded in getting a function to succeed.
In this instance, the second unit has shifted into a faster wake/sleep cycle, and I’m not receiving ‘spark/status online’ until after the e-series has woken, published, and returned to sleep. I can see all of this on the console, but have not ability to interact through functions. I believe when the longer stage wake up occurs tomorrow I’ll get my config update in, but this is a new frustrating situation.
- Has something in the cloud function delivery changed lately that could explain the odd delay?
- Is there a better way (existing or planned) to deliver functions calls to a sleeping cellular node?
…I know we could write an elaborate method ourselves for handshaking and then calling the function, etc. But if we don’t receive the event fast enough (within 1 minute or less of connection) it won’t help anyway, or it will force us to bleed battery unnecessarily while we wait for the cloud to acknowledge the connection event.