I’m trying to minimize the amount of data I send OTA when publishing events to Thingspeak, and I was wondering if it is more data efficient to use the Thingspeak library or publish events to the particle cloud and relay them to Thingspeak using a webhook.
It looks like Particle events send their as strings which is uses more data than like a short. Does the Thingspeak library do the same behind the scenes? Also do they have the same data cost for authentication / API keys, etc?
Also, I would like help comparing the data usage of various posting methods (GET, POST, JSON, etc)
(#3) The Publish + Webhook used the least amount of cellular data on an Electron, by far.
My “Typical” publish event updates (3) ThingSpeak Fields, and looks like this: {"1":"253454048.0","2":"360.0","3":"0.00","k":"ZZZZZZZZZZZZZZZZ"}
Where Z = the ThingSpeak API Write Key.
The Publish message is prepared with snprintf()
Sending 13,000 Events Per Day uses 1.6 MB/day of cellular data, currently.
This has increased recently beginning in early May (up from 1.3 MB/day), I suspect due to the Cloud changes introduced.
Out of curiosity, are you saying you send the thingspeak key with every Particle.publish method call? Is that necessary? I was just going to insert that when the Particle cloud relayed the data to Thingspeak.
Also, how do you parse the data packet of the event into its 1:, 2:, etc, pieces before you send it. (I assume you’re POSTing it as JSON data?)
Yes, I use (1) Webhook to handle all my ThingSpeak Channels, so I need to send the API Write Key with every Publish. You could "hard-code" the API Key inside the webhook if you wanted to, but you would need a new webhook for each ThingSpeak Channel.
Here's sample code. The Webhook info is a few posts down.
Something you might consider, if you don’t already. Think about deadbanding your sends. In other words, if data (ex readings, like a temperature) don’t change by a certain amount, don’t send the data, since it may not offer much value. I have this set up in a number of devices and pass a setup parameter that indicates the deadband amount. For me, that’s often 0.5˚F. I also send a setup parameter that indicates the maximum number of consecutive readings the device can skip before it’s required to send an update. Again, for me, it’s often 5 (by default, I attempt to send every minute and I want a reading for sure every 5 minutes). FWIW.