Items with channels REGEX and JSONPATH

[Josar]

I try to wrap my head around transformation and have some trouble getting it done.

As i try to read out GPU values explained here a had want to make the solution as neat as possible.

When i apply an Thing like this and add an Regex to get an jsonpath string containing { “temp” : <value> }.

Thing exec:command:gpuTemp [
        command="/opt/vc/bin/vcgencmd measure_temp",
        interval=10,
        autorun=false,
        transform="REGEX(s/(.*?)=(.*?)'C/{ \"$1\" : $2 }/g)"
        ]

And i set up a rule to transform this jsonpath string to a number

rule "System CPU Temperature"
  when
     Item gpuTemp_out received update
  then
      logInfo("JSONPATH test", transform("JSONPATH", "$.temp", gpuTemp_out.state.toString ).toString )
end

I get following log output which leads me to the conclusion that the transformation works as intended.

[INFO ] [marthome.event.ItemStateChangedEvent] - gpuTemp_out changed from { "temp" : 52.1 } to { "temp" : 50.5 }
[INFO ] [smarthome.model.script.JSONPATH test] - 50.5

Removing the rule and applying the description for jsonpath transformation from the docs results in no change for the values.

Number System_Temperature_GPU "Temperature GPU [JSONPATH($.temp):%.1f °C]" <temperature> (System_Temperature_Chart) { channel="exec:command:gpuTemp:output" }

What do i miss?

[rlkoshak (Rich Koshak)]

My first guess would be that the result from your script isn’t strictly a JSON formatted string. Therefore it cannot be parsed with JSONPATH.

So your REGEX on the Thing extracts just the JSON and the Rule extracts the value from the JSON.

If I’m correct, there will be no way to do this in one transform unless you implement it in JavaScript.

[Josar]

I think it is not a problem with the JSONPATH string,

The JSonPathTransformationService just returns a string, no matter what the content is.

the documentation states different Transformations
Which states that the return value of the JSonPathTransformation can be placed into the Number item.

Number  Kitchen_Temperature_C    "Temperature [JSONPATH($.temperature):%.1f °C]" {/*Some Binding*/}

I solved the problem differently as Grafana supports plotting of string values i just use the regex to get the value and change the item to a String instead of Number.

Thing exec:command:gpuTemp [
        command="/opt/vc/bin/vcgencmd measure_temp",
        interval=60,
        autorun=false,
        transform="REGEX(temp=(.*?)'C)"
        ]

String  System_Temperature_GPU "Temperature GPU [%s °C]" <temperature> (System_Temperature_Chart){ channel="exec:com$

Had to drop the database and recreate it to get the old database entry to change from float to string.
But now I have a neat clean minumum solution with only 1 Thing and 1 item.

@Kai It would be great to be able to define the return value type when using JSONPATH as it may contain different types of data. Defining the expected return value would match the item type and so the example could work.
The same would be nice for the Regex transformation. This would reduce the file count and the rules overhead by keeping things together.

[rlkoshak (Rich Koshak)]

@Josar

The JSonPathTransformationService just returns a string, no matter what the content is.

You miss my point. If String being transformed isn’t valid JSON it will not be able to parse it and return the value indicated by the JSONPATH.

@Josar

Which states that the return value of the JSonPathTransformation can be placed into the Number item.

That is correct so long as the value returned by the JSONPATH can be parsed into a Number. This means no spaces and no symbols (e.g. %).

But again, you missed my point. You cannot link a Number Item to the output channel of an Exec Binding Thing.

@Josar

@Kai It would be great to be able to define the return value type when using JSONPATH as it may contain different types of data. Defining the expected return value would match the item type and so the example could work.

This is something that would be implemented by the Binding, not in the core, I believe. And, like I said above, the problem wasn’t with the transform. You can use a JSONPATH (or any other) transform on a Number Item. I do it all over the place for parsing the JSON from Wunderground. Your problem was that the Exec binding only allows you to link the output channel to a String Item.

[Josar]

@rlkoshak now i get that i can not add the channel of Exec to an Number item. I just tried to follow up your suggestion, which leaded me to this problem.

@rlkoshak

If you apply the REGEX transform to your GPU temperature thing you can eliminate the Rule entirely.

So basically the Problem is the Exec Binding channel which returns a string and this can not be casted to a Number item. See the documentation.

So that is obvious now.
The return value of the exec binding channel will be stored in the item with applied Regex. In both cases it will be a string. Which can not be stored in the Number item.

Thank you for your time and help, i lost sight of the assignment.

@rlkoshak

@Kai It would be great to be able to define the return value type when using JSONPATH as it may contain different types of data. Defining the expected return value would match the item type and so the example could work.

This is something that would be implemented by the Binding, not in the core, I believe.

That is apparent, so correcting my thought from above, it would be nice to have an or multiple additional channel at the exec Binding which allows to retrieve a casted value from the returned string.

[rlkoshak (Rich Koshak)]

What you can do, if you need it in a Number Item, is create an Unbound Number Item and a Rule that populates the Unbound Item and then use that Number Item in your Rules and persistence.

Number Temp

rule "Update Temp"
when
    Item System_Temperature_GPU received update
then
    Temp.postUpdate(System_Temperature_GPU.state.toString)
end

This will give you a Number version of the temp.It may not be as clean as it could be if the output channel was able to post to a Number Item directly but it isn’t terrible either.