API, content=channels and Ambiguous JSON/XML output

IIRC the JSON output requires &usecaption=1 in the call to also output those properties. JSON is often use internally and does not need those captions for the internal processing. Let me know if that did the trick :)

Kind regards,
Stephan Linke, Tech Support Team

I tried adding &usecaption=1 to the query string, but the resulting JSON was the same.

API call:

/api/table.json?content=channels&output=json&columns=name,lastvalue_&id=<SENSORID>&usecaption=1

Results:

{
	"prtg-version": "18.2.41.1652",
	"treesize": 0,
	"channels": [{
		"name": "Downtime",
		"lastvalue": "",
		"lastvalue": ""
	}, {
		"name": "Traffic In",
		"lastvalue": "2,148 MByte",
		"lastvalue": "300 Mbit/s"
	}, {
		"name": "Traffic Out",
		"lastvalue": "612 MByte",
		"lastvalue": "86 Mbit/s"
	}, {
		"name": "Traffic Total",
		"lastvalue": "2,760 MByte",
		"lastvalue": "386 Mbit/s"
	}]
}

I believe "&usecaption=1" only applies to retrieving historic data.

My observation has been that it appears to be an implementation detail that the values are always ordered volume, then speed.

If you do

http://<server>/controls/table.htm?tableid=channeldisplaytable&content=channels&columns=lastvalue_&count=*&id=<id>&username=<username>&password=<password>

Replacing <server>, <id>, <username> and <password> respectively, you will get the "Last Value (volume)" and "Last Value (speed)" columns that are displayed on the normal sensor page. If you change the "lastvalue_" column to simply "lastvalue" you only get one column - the volume channel.

Based on that, I'm not sure Stephan whether you're able to confirm whether the handler controls/table.htm delegates to simply asserts that the second value must be the speed value?

I was able to recreate this, seemingly my JSON prettyprint plugin stripped the duplicates ô_Ô Lordmilko, consider it confirmed that the speed/volume sensors do it like that. So [0] is volume, [1] is speed. Even though it's invalid JSON :/ The next API iteration will hopefully not have quirks like that.

Kind regards,
Stephan Linke, Tech Support Team

When is this next API iteration coming? I want to make my own interface in html that will receive json and plug the data into google charts, but the duplicates and lack of labeling etc is making this a pain. For example, when I get (from a memory sensor):

{  
   "prtg-version":"18.4.45.1898",
   "treesize":0,
   "channels":[  
      {  
         "name":"Available Memory",
         "lastvalue":"7,600 MByte",
         "lastvalue_raw":7969386496.0000,
         "lastvalue":"7,600 MByte",
         "lastvalue_raw":7969386496.0000
      },
      {  
         "name":"Downtime",
         "lastvalue":"",
         "lastvalue":""
      },
      {  
         "name":"Percent Available Memory",
         "lastvalue":"37 %",
         "lastvalue_raw":37.0000,
         "lastvalue":"37 %",
         "lastvalue_raw":37.0000
      }
   ]
}

Besides having the duplicate keys, you have to go through the array of channels to find the one you are looking for. Take advantage of JSON and use objects (even if you leave the name in the object), so it would be more like:

{  
   "prtg-version":"18.4.45.1898",
   "treesize":0,
   "channels":{  
      "Available Memory":{  
         "name":"Available Memory",
         "lastvalue":"7,600 MByte",
         "lastvalue_raw":7969386496.0000
      },
      "Downtime":{  
         "name":"Downtime",
         "lastvalue":""
      },
      "Percent Available Memory":{  
         "name":"Percent Available Memory",
         "lastvalue":"37 %",
         "lastvalue_raw":37.0000
      }
   }
}

So now if I were to look at the value of arrayName["channels"]["Percent Available Memory"]["lastvalue_raw"] it would equal 37.0000. Currently to get this, I would have to loop through the channels array, checking the name value for each item until it equaled "Percent Available Memory".

This means a lot more coding and resource usage.

@MicWit I'm afraid it's still quite off, no ETA yet :(

PRTG Scheduler | PRTGapi | Feature Requests | WMI Issues | SNMP Issues

Kind regards,
Stephan Linke, Tech Support Team