HWiNFO has a plugin called "Remote Sensor Monitor" that provides hardware sensor values over a small webserver on the host system (https://www.hwinfo.com/addons.php)

Small example output here (also available here, if formatting below is broken: https://pastebin.com/wPqaf5YQ)

[
  {
    "SensorApp": "HWiNFO",
    "SensorClass": "CPU [#0]: Intel Core i7-8700K",
    "SensorName": "Core #0 Clock",
    "SensorValue": "4099,016",
    "SensorUnit": "MHz",
    "SensorUpdateTime": 1535033257
  },
  {
    "SensorApp": "HWiNFO",
    "SensorClass": "CPU [#0]: Intel Core i7-8700K: DTS",
    "SensorName": "Core #0",
    "SensorValue": "35",
    "SensorUnit": "°C",
    "SensorUpdateTime": 1535033257
  },
  {
    "SensorApp": "HWiNFO",
    "SensorClass": "CPU [#0]: Intel Core i7-8700K: DTS",
    "SensorName": "CPU Package",
    "SensorValue": "36",
    "SensorUnit": "°C",
    "SensorUpdateTime": 1535033257
  },
  {
    "SensorApp": "HWiNFO",
    "SensorClass": "CPU [#0]: Intel Core i7-8700K: DTS",
    "SensorName": "Core Max",
    "SensorValue": "36",
    "SensorUnit": "°C",
    "SensorUpdateTime": 1535033257
  },
  {
    "SensorApp": "HWiNFO",
    "SensorClass": "CPU [#0]: Intel Core i7-8700K: DTS",
    "SensorName": "Core #0 Thermal Throttling",
    "SensorValue": "0",
    "SensorUnit": "Yes/No",
    "SensorUpdateTime": 1535033257
  },
  {
    "SensorApp": "HWiNFO",
    "SensorClass": "S.M.A.R.T.: Crucial_CT525MX300SSD1 (162913483656)",
    "SensorName": "Drive Remaining Life",
    "SensorValue": "98",
    "SensorUnit": "%",
    "SensorUpdateTime": 1535033257
  }
]

By using http://jsonpath.com/ I am able to create a working filter that (as an example) extracts the "CPU Package" value in a specific SensorClass named "CPU [#0]: Intel Core i7-8700K: DTS".

$.[?(@.SensorClass == 'CPU [#0]: Intel Core i7-8700K: DTS' && @.SensorName == 'CPU Package')].SensorValue

As a result I get the following output:

[
  "36"
]

I have created a .template on the PRTG server with the following content:

{
  "prtg": {
    "description" : {
      "device": "192.168.1.51:55555",
      "query": "/",
      "comment": "demo"
    },
    "result": [
      {
        "channel": "Temperature",
        "value": $.[?(@.SensorClass == 'CPU [#0]: Intel Core i7-8700K: DTS' && @.SensorName == 'CPU Package')].SensorValue,
        "unit": "Temperature"
      }
    ]
  }
}

Using this template on the "REST Custom BETA" sensor produces this error:

 16:08:41
	TYRELL	REST Custom BETA	REST Custom	Warning	
Parsing error: { "prtg": { "description" : { "device": "192.168.1.51:55555", "query": "/", "comment": "demo" }, "result": [ { "channel": "Temperature", "value": $.[?(@.SensorClass == 'CPU [#0]: Intel Core i7-8700K: DTS' && @.SensorName == 'CPU Package')].SensorValue, "unit": "Temperature" } ] } } :11:20 - 11:21 unexpected "[" while scanning JSON select expected Ident, "." or "*".

I might be mistaken, but as far as I can tell, this is because there are square brackets in the output of the jsonpath filter used.

So my question is: Is there any way to get the square brackets stripped away without having to use external parsing of the json output? (Or is there something else causing the error here?)


Article Comments

Hi Ivan,

Could you please try the following template and let me know if it works?

{
  "prtg": {
    "description" : {
      "device": "192.168.1.51:55555",
      "query": "/",
      "comment": "demo"
    },
    "result": [
      {
        "channel": "Temperature",
        "value": $[?(@.SensorClass == "CPU [#0]: Intel Core i7-8700K: DTS" && @.SensorName == "CPU Package")].SensorValue,
        "unit": "Temperature"
      }
    ]
  }
}

Andreas Günther
Support Team, Paessler AG


Aug, 2018 - Permalink

Hi there,

I'm still getting the same error. (The double quotes didn't help. Or were there any other changes that I didn't see?)


Aug, 2018 - Permalink

Hi Ivan,

I'm sorry, I've included a previous error there. Could you please try the updated version from my previous post? I changed the double quotes and deleted the ".":

old: "value": $.[?
new: "value": $[?

Thank you in advance!


Andreas Günther
Support Team, Paessler AG


Aug, 2018 - Permalink

Hello again,

Wow, yes now it works. Thank you! You have no idea the amount of time I've spent on troubleshooting this while being entirely focused on how I could get rid of the square brackets - instead of looking at the . operator.

I assumed the first dot after the root $ symbol was needed for the subscript operator [] brackets.

Which brings me to the next questions:

Does this mean the error message PRTG was producing is always about erroneous formatting of the .template file - and not about the .template file's output?

Why do the various online jsonpath evaluators accept the first . operator without giving erroneous output? Is the PRTG .template parsing done differently somehow?


Aug, 2018 - Permalink

Another issue: my channel names are now always ending with an unwanted extra character "0" (zero).

This is the template (used on this example json output: https://pastebin.com/ZDkecsdD ):

{
  "prtg": {
    "description" : {
      "device": "HWiNFO",
      "query": "/",
      "comment": "test"
    },
    "result": [
      {
        "channel": "Fan Chassis1" ,
        "value": $[?(@.SensorClass == "ASUS ROG MAXIMUS X HERO (Nuvoton NCT6793D)" && @.SensorName == "Chassis1" && @.SensorUnit == "RPM")].SensorValue ,
        "unit": "Custom",
        "customunit": "RPM"
      }
    ]
  }
}

And to troubleshoot easier, this is the output from rest.exe

../..
      {
        "channel": "Fan Chassis10",
        "Value": 231,
        "Unit": "Custom",
        "CustomUnit": "RPM"
      }
../..

There is something when using filters that triggers PRTG to add the extra "0" at the end. If I put a static value in the template, the "0" in the channel name goes away.

Even a short filter like this will put a "0" in the channel name:

        "value": $[?(@.SensorName == "Chassis1" )].SensorValue ,

Any ideas?


Aug, 2018 - Permalink

Hi Ivan,

Thank you for your answer.

Yes, the error you're receiving always points to errors from the template itself, not the output of the template. PRTG is in fact parsing JSON a little bit differently yes, we are aware of the situation and are still improving the sensor.

The 0 at the end of channel names is displayed because the JSON parse is actually an array and can report multiple lines.

Could you please try the following line and see if the 0 is still added?

"value": $($[?(@.SensorClass == "ASUS ROG MAXIMUS X HERO (Nuvoton NCT6793D)" && @.SensorName == "Chassis1" && @.SensorUnit == "RPM")])[0].SensorValue ,

Thank you for your reply!


Andreas Günther
Tech Support, Paessler AG


Aug, 2018 - Permalink

Hello again,

Finally I'm seeing a proper channel name without the "0" at the end. Thank you :)

Do you have any suggestion for how to test jsonpath/filters when working with templates, when there is such discrepancy between online jsonpath evaluators and PRTG? (The line you suggested above doesn't give any results in online jsonpath evaluators)


Aug, 2018 - Permalink

Hi Ivan,

That's great to hear! :)

You're right, the usage of online jsonpath evaluators might not work properly with complex JSONPath expressions that PRTG supports.

The REST Custom sensor is an EXE sensor, so you can test and debug your configuration by executing rest.exe with several parameters. You'll find the rest.exe in the \Sensor System subfolder of the PRTG program directory.

Please find additional information here: https://www.paessler.com/manuals/prtg/rest_custom_sensor#usage


Andreas Günther
Tech Support, Paessler AG


Aug, 2018 - Permalink