Tracker: file download from, say, Google Drive

Hello, I’m using a Tracker One for prototyping a telematics project. I’d like to download a config file (.txt) with a list of PGNs that I want to Tracker One to get data for. This list can be quite large, so using variables/functions is not really an option. Additionally, this list can change over time, and I don’t want to re-code variables/functions/firmware each time the list changes.

The TCP Client library poses a few problems since I will have to create a server inside a corporate firewall which necessitates that I force the Tracker to obtain a static IP address so that my cybersecurity team can open up that IP, which in turn is a major pain to jump through bureaucratic hoops.

While there are a few options to upload files from the Tracker to the cloud, I’m not finding anything where data flows in the reverse direction.

Does the community have any suggestions or pointers for me?

Would something like a webhook to Google sheets work for you?

Incidentally, none of the cellular devices support using a static IP address. Carriers assign a private IP address by DHCP to your cellular device, and many cellular devices share a single public IP address by carrier-level NAT.

Not positive it will work in your application, but if you can convert your list into JSON specific to each Particle device and put it in the Device Notes field using the console or Particle API, you can use the DeviceNotesHelperRK library to have each device download its own list. The per-device data is limited to available RAM, but can exceed 622 bytes.

Ummm, I saw this earlier; I believe I am looking for something where the data goes in the other direction. i.e., from Google Drive to the Tracker.


Hmmm, that’s interesting, and it may suit my application. I will take a deeper look into this.


Hi all, and a Happy New Year. So, I’ve been making some progress with this topic, and thanks to @rickkas7’s code and @eberseth’s suggestions, I’ve been able to interface my Tracker One with Google Sheets. However, I’m having some trouble with parsing the JSON response. Here’s what’s happening:
My JSON response is coming in as a multi-part message. I’ve adapted @rickkas7’s DeviceNotesHelper library to read in this message, but jp.parse() in hookresponsehelper is returning 1 at strange times. Serial log output below. I added Log messages to the devicenoteshelper.hookresponsehandler()
After publish #1:

0003808811 [app] INFO: received response index 2
0003808812 [app] INFO: parse returned 0
0003808831 [app] INFO: received response index 3
0003808832 [app] INFO: parse returned 0
0003808922 [app] INFO: received response index 0
0003808923 [app] INFO: parse returned 0
0003808994 [app] INFO: received response index 1
0003808997 [app] INFO: parse returned 0

After publish #2:
0003889144 [app] INFO: received response index 0
0003889145 [app] INFO: parse returned 0
0003889234 [app] INFO: received response index 1
0003889236 [app] INFO: parse returned 0
0003889237 [app] INFO: received response index 3
0003889238 [app] INFO: parse returned 1
0003889239 [app] INFO: size of zone list: 7 <---- this is a message from my app callback
0003889359 [app] INFO: received response index 2
0003889361 [app] INFO: parse returned 0

In Publish #1, you can see that jp.parse() does not return a 1 even after the 4-part message has been received, while in Publish #2 parse() returns true at the wrong time, after the third packet. I’m using JSONParserGeneratorRK v0.1.4 and deviceNotesHelperRK v.0.0.1.

Any advice/suggestions/thoughts?

Also, in deviceNotesHelper, the hasValidData flag is set to true when parse() returns true, but it never gets reset to false. Is this intentional? Shouldn’t it be reset before the next publish?

I just released DeviceNotesHelper 0.0.2 so it correctly handles out-of-order webhook responses.

0.0.2 (2021-01-07)

  • Upgrade to JsonParserGeneratorRK 0.1.4
  • Use addChunked to support out-of-order multipart webhook responses

@rickkas7 Thanks, that works better (i’m getting the proper zone list values), but parse still returns true for every packet, and my application callback gets called multiple times per publish. How can I tell whether the message is complete? Ideally, I’d like my callback to be called once, when the message is complete.

0000737694 [app] INFO: parse returned 1
0000737694 [app] INFO: size of zone list: 10
0000737807 [app] INFO: parse returned 1
0000737807 [app] INFO: size of zone list: 10
0000737951 [app] INFO: parse returned 1
0000737951 [app] INFO: size of zone list: 10
0000737954 [app] INFO: parse returned 1
0000737954 [app] INFO: size of zone list: 10