makeJsonRequest() with long Mongolab-URL: Error Code 404

Thank you for all of your considerations.
I found a solution: I reformat with a litle php-scipt on my webspace the response from mongolab (eliminating the square brackets) and everything works fine.

I saw something similar to this in the simulator and on the device (error 400) when my response contained multiple blocks that were not separated by commas.

Using the OP's example, the following will fail with an error 400 in the sim on 1.1.2:

[ { "date" : 1432333009000 , "sgv" : 150 , "direction" : "Flat"} { "date" : 1432333008940 , "sgv" : 148 , "direction" : "Flat"} ... ]
The following will fail with an error 400 on a device (in this case, vivoactive v3.00):

{ "date" : 1432333009000 , "sgv" : 150 , "direction" : "Flat"} { "date" : 1432333008940 , "sgv" : 148 , "direction" : "Flat"} ...
[ { "date" : 1432333009000 , "sgv" : 150 , "direction" : "Flat"} { "date" : 1432333008940 , "sgv" : 148 , "direction" : "Flat"} ... ]
It's been reported and is being investigated.

After some time I will ask again (with the similar problem but with other results and another code) - is there a solution?

This works well in the simulator, but not on my device (vivoactive, 3.26/iq 1.2):
var url = "api.mongolab.com/.../entries";
var mongolab = "xxx";

class nightscoutgarminView extends Ui.View {

//! URL abfragen
function frageURL( ) {
Comm.makeJsonRequest( url, { "l" => "1", "s" => "{'date':-1}", "f" => "{'sgv':1,'direction':1,'date':1,'_id':0}", "apiKey" => mongolabApi }, {}, method(:verarbeiteWerte) );
return true;
}

//! Abfrage auswerten
function verarbeiteWerte( responseCode, data ) {
Sys.println("Data: " + data);
Sys.println("ResponseCode: " + responseCode);

if(responseCode == 200) {
// BZ-Wert
wert = "" + data[0]["sgv"];
// Tendenz (Pfeil)
richtung = data[0]["direction"].toString();
if( richtung.equals("") ) { pfeil = 0; }
if( richtung.equals("DoubleUp") ) { pfeil = 7; }
if( richtung.equals("SingleUp") ) { pfeil = 6; }
if( richtung.equals("FortyFiveUp") ) { pfeil = 5; }
if( richtung.equals("Flat") ) { pfeil = 4; }
if( richtung.equals("FortyFiveDown") ) { pfeil = 3; }
if( richtung.equals("SingleDown") ) { pfeil = 2; }
if( richtung.equals("DoubleDown") ) { pfeil = 1; }
Ui.requestUpdate( );
} else {
Sys.println(responseCode);
Sys.println(data);
verzoegerung = "Fehler: " + responseCode.toString();
Ui.requestUpdate( );
}
}


In the simulator I get following output (and the handling of the array works fine):

Data: [{date=>1445243387904.000000, sgv=>139, direction=>Flat}]
ResponseCode: 200

On the device it will not work:

Data: null
ResponseCode: 0

If found no entry in the CIQ-Log.

If I adress my request at my own Server with a php-Script that that asks the same json-request and reformat it without square brackets (no array), everything works fine.

Thanks for your assistance
Andreas

The issue reported before was due to malformed responses (the responses looked like an array of responses, but there were no commas between each of the elements). I think the answer in this case is to remove the square brackets from the response, although I believe that what you're receiving is valid JSON.

For example:

[{ "one": 1 }]

...is a valid response. The problem before was a response like this:

[{ "one: 1 } { "two": 2 }]

But now it works as it should in the simulator ...
That's the difference to IQ 1.1.2.

??? Andreas

Json issue and nightscout

Hi there,

I have this problem too, I solved it by writing the function

function fixArray (array)
{ //Due to the nested array in the dictionaries,
// this pulls a dictionary out of an array for use.
//sys.println(array.size());
if (array.size() == 1)
{
return array[0]; // some data is not an array of dimension one this is to handle that.
}
else
{
return array; // just send the original back just in case.
}
}

And then calling it in my code thus:

cgmdata.lastBGdict = fixArray(data["bgs"]);
//cgmdata.lastCalsdict = fixArray(data["cals"]); //Pulls out cals dictionary from json only use in the future
cgmdata.lastStatusdict = fixArray(data["status"]); //Pulls out status dictionary from json


If you are interested:
https://apps.garmin.com/en-GB/apps/00bde42c-44b6-474e-975c-7c593c6a3bcb

but I'll have to compile you a vivoactive version if necessary because the text picker doesn't work

R.

json arrays of dictionaries.

The issue reported before was due to malformed responses (the responses looked like an array of responses, but there were no commas between each of the elements). I think the answer in this case is to remove the square brackets from the response, although I believe that what you're receiving is valid JSON.

For example:

[{ "one": 1 }]

...is a valid response. The problem before was a response like this:

[{ "one: 1 } { "two": 2 }]

Hi Brandon,

Is this malformed?:
{"status":[{"now":1445549636002}],"bgs":[{"sgv":"13.1","trend":5,"direction":"FortyFiveDown","datetime":1445549303000,"filtered":228992,"unfiltered":220928,"noise":1,"bgdelta":"-0.4","battery":"63"}],"cals":[{"slope":854.844019138756,"intercept":14664.298564593308,"scale":1}]}

It seems to have commas, but has a similar issue. I just fudged a solution, but it did feel like I was working round something that shouldn't behave that way.

R.

That appears to be valid, but I wonder if it has to do with the single element arrays (e.g. [{"key" : value}] ). I'll do some additional testing to see if I can verify that this is the issue.

I mocked up an API to test a few of the messages in this thread that are failing, and I never had any issues in the simulator or on the device. I'm testing on vivoactive 3.26 and compiling with the 1.2.0 SDK, similar to andreas-may.

The only difference is that I'm using an internal test build of Garmin Connect Mobile that is not publicly available, but it's very similar to 3.0, which was just released.

I can confirm that the following all work fine for me on a device:

• [{ "one" : 1 }]
  
• [{"date" : "1445243387904.000000", "sgv" : "139", "direction" : "Flat"}]
  
• {"status":[{"now":1445549636002}],"bgs":[{"sgv":"13.1","trend":5,"direction":"FortyFiveDown","datetime":1445549303000,"filtered":228992,"unfi ltered":220928,"noise":1,"bgdelta":"-0.4","battery":"63"}],"cals":[{"slope":854.844019138756,"intercept":14664.298564593308,"scale":1}]}
  

I will have to keep testing to see if I can force a failure somehow using properly-formed JSON.

JSON feed

I mocked up an API to test a few of the messages in this thread that are failing, and I never had any issues in the simulator or on the device. I'm testing on vivoactive 3.26 and compiling with the 1.2.0 SDK, similar to andreas-may.

The only difference is that I'm using an internal test build of Garmin Connect Mobile that is not publicly available, but it's very similar to 3.0, which was just released.

I can confirm that the following all work fine for me on a device:

• [{ "one" : 1 }]
  
• [{"date" : "1445243387904.000000", "sgv" : "139", "direction" : "Flat"}]
  
• {"status":[{"now":1445549636002}],"bgs":[{"sgv":"13.1","trend":5,"direction":"FortyFiveDown","datetime":1445549303000,"filtered":228992,"unfi ltered":220928,"noise":1,"bgdelta":"-0.4","battery":"63"}],"cals":[{"slope":854.844019138756,"intercept":14664.298564593308,"scale":1}]}
  

I will have to keep testing to see if I can force a failure somehow using properly-formed JSON.

Hi Brandon, thanks for the reply and for agreeing to look into it.

I realise that I am cross-posting on someone else's post, so if you want another thread opened, feel free. If you want to consume data from the endpoint that I took that data from is
https://xxxxx.azurewebsites.net/pebble
or
https://xxxxx.azurewebsites.net/pebble?units=mmol

It looks like Andreas May is trying to do a similar thing to me and hopefully we can collaborate. My pebble endpoint is almost certainly taking data from an identical document structure in mongodb to Andreas'.

What would be even better is if you at Garmin can take this application development forwards. What we are PoCing is an outstanding showcase marketing opportunity for you for the platform. I am happy to elaborate if you can help on this front or can put me in touch with someone who might take this forwards.

If you can obfuscate xxxxx when you moderate this it would be great, as it is real data and I'd rather it wasn't on this site in plain text.

In time I will post my sourcecode one github.

Regards,

R