[SOLVED] JSONPATH transform to item error

Hello all.
I’m looking to convert an incoming string from my Tasmota TH16 to items via an openhab rule, but am having a JSONPATH error. I haven’t really forrayed into this form of transformation before, so I have to admit I could be missing something fundameltal here.

My incoming string is a variation of this:

The string is stored in sonoffCNCRoom_Sensor_Raw via MQTT. This is working,

My rule triggers on sonoffCNCRoom_Sensor_Raw change, but throws an error.


rule "CNCRoom Sensor Transform"
	Item sonoffCNCRoom_Sensor_Raw changed
	var sJSONBLOB = sonoffCNCRoom_Sensor_Raw.state.toString
	var sTemp =	transform("JSONPATH","$.Temperature", sJSONBLOB)
	var sHumid=	transform("JSONPATH","$.Humidity", sJSONBLOB)
	// var updateTime = transform("JSONPATH","$.Time", sJSONBLOB)
    // will cheat and just use now.toString.

items definitions:

Number sonoffCNCRoom_Humidity "Humidity [%.1f]"  <humidity> (S_GeneralShop, gHumidityItems) 
Number sonoffCNCRoom_Temp "Temperature [%.1f °C]" <temperature> (S_GeneralShop, gTemperatureItems)
String sonoffCNCRoom_Sensor_Raw "Sensor" (S_GeneralShop, gTemperatureItems) {channel="mqtt:topic:6da4d316:Sensor"}
DateTime sonoffCNCRoom_LastUpdate "CNC Room Sensor Last Update [%1$tm/%1$td %1tH:%1tM]" <clock>

Relevant excerpt from the log:

2019-12-16 22:03:37.001 [vent.ItemStateChangedEvent] - mqtt_topic_6da4d316_Sensor changed from {"Time":"2019-12-16T22:02:36","SI7021":{"Temperature":15.4,"Humidity":57.3},"TempUnit":"C"} to {"Time":"2019-12-16T22:03:36","SI7021":{"Temperature":15.4,"Humidity":57.3},"TempUnit":"C"}

2019-12-16 22:03:37.005 [vent.ItemStateChangedEvent] - sonoffCNCRoom_Sensor_Raw changed from {"Time":"2019-12-16T22:02:36","SI7021":{"Temperature":15.4,"Humidity":57.3},"TempUnit":"C"} to {"Time":"2019-12-16T22:03:36","SI7021":{"Temperature":15.4,"Humidity":57.3},"TempUnit":"C"}

==> /var/log/openhab2/openhab.log <==

2019-12-16 22:03:37.010 [DEBUG] [.internal.InfluxDBPersistenceService] - got String value {"Time":"2019-12-16T22:03:36","SI7021":{"Temperature":15.4,"Humidity":57.3},"TempUnit":"C"}

2019-12-16 22:03:37.015 [DEBUG] [.internal.InfluxDBPersistenceService] - got String value {"Time":"2019-12-16T22:03:36","SI7021":{"Temperature":15.4,"Humidity":57.3},"TempUnit":"C"}

2019-12-16 22:03:37.028 [WARN ] [rthome.model.script.actions.BusEvent] - Cannot convert '{"Time":"2019-12-16T22:03:36","SI7021":{"Temperature":15.4,"Humidity":57.3},"TempUnit":"C"}' to a state type which item 'sonoffCNCRoom_Humidity' accepts: [DecimalType, QuantityType, UnDefType].

2019-12-16 22:03:37.036 [WARN ] [rthome.model.script.actions.BusEvent] - Cannot convert '{"Time":"2019-12-16T22:03:36","SI7021":{"Temperature":15.4,"Humidity":57.3},"TempUnit":"C"}' to a state type which item 'sonoffCNCRoom_Temp' accepts: [DecimalType, QuantityType, UnDefType].

Any pointers/suggestions? I’ve wandered many JSONPATH documentation sites, with little direction.
I’m guessing it may have something to do with how the temperature/humidity is nested within the string.


(OH 2.4 on RPi3B extended onto a large SSD, MQTT working well with several other devices)

Hello Ben,

Hey are you using a rule at all for the sensor readings? You could do the transformation in the channel setup!
How are you doing it, file or PaperUI?

Hi Jürgen,
I am using the rule that is quoted in my above post (nothing else in this particular rule file at this point), and the item file also quoted above. Both are defined in the text files. The only related thing is the mqtt thing, created in paperui (that part is working, as can be seen in the log).

Your question reminded me that I had also tried to set up a transform in PaperUI in the Tasmota MQTT thing configuration - and had only configured one called Temperature. Incidentally, this one isn’t working either (with the shown configuration in the screenshot, or with “JSONPATH:$.SI7021.Status.Temperature”

and here is the current output from the device per PaperUI (some duplication given the text-defined items). As you can see, the UI-configured value isn’t working either. I like text-defined, as I am able to persist and back them up more reliably/reproducibly. I imagine this might change with 2.5 and future releases.

Thanks for your input/suggestions!

It is because the JSONPATH is incorrect. It should be (As I said in other thread BTW):


I strongly recommend the Binding approach instead of the rule
2 channels, one for each value, Temperature and Humidity.
Incomming transformations are:

Good luck


Thanks @vzorglub
I must have missed that comment - not sure which other thread it was, but I was crawling through a lot to try to put this together, so it’s certainly possible.

This is exactly the transformation I needed.

Now, I’m sure this is documented somewhere, but if I’m not going to use text files for this, I’ll need to find out how enable influxdb persistence for this paperui-defined item.

Influxdb operates on Items. It does not care how you defined them, or how you populate them.

So I see that the Temperature and Humidity variables are automatically persisted in influxdb, so that, I suppose, gets around how to enable persistence for a PaperUI-defined thing/item. No need to update my infludxb.persist file.

The next problem, though, becomes using the information. Text-defined items just seem so much more usable - perhaps because they’re just inately simple and overt.

Reading through this, for example, seems to suggest that a thing/channel isn’t very useful in rules other than to trigger a rule.

My current understanding is that the channel within the thing is largely equivalent to an item, only if it involves colons, it needs to be in quotation marks (ie “mqtt:topic:6da4d316:LowerTemp”)
In my reading, I don’t see it explicitly discussed, and I am wondering if channels can use .status, .sendCommand or .postUpdate. Perhaps it would be “mqtt:topic:6da4d316:LowerTemp”.postUpdate(15) , for example.

Several threads almost approach this issue, then go off in a different direction.
Some threads make it seem like channels aren’t much use in rules at all, ie:

So, can someone please clarify if I am incorrect that items textual descriptions are still needed for use of robust rules? I imagine some of these other threads are based on older versions of OpenHab and things may have changed.

(In my case, I’m planning on having a virtual switch “usingShop”. When it’s changed, the rule triggers. If it is ON, then the temperatures are set to 16-20 C, and if it is OFF, the temperature limits are set to 9-11 C. Currently I have these upper and lower limits defined in both PaperUI (MQTT thing) and items text files (referencing MQTT channels). I may even get fancy and throw an expiry binding in there, or make the switch get set to off every midnight. )

Nope, you’ve not grasped it.

Items are the key working parts of openHAB. Rules operate on Items. UI display Item states, UI send commands to Items. UI chooses icons based on Item states. Persistence stores and recovers Item states.

Everything else is there to support Items.
Things are a model of some external device or service.
channels are the links matching abstract Items to real world Things.

openHAB does not care if you define your Item from a text xxx.items file or from the PaperUI administrator’s interface. Either method results in an Item.

There are of course frilly bits added on to that, for example trigger event channels that don’t link to any Item, but these can be regarded as extra convenience parts.

What is the “Binding approach”? Could you elaborate please?

Doing the “icoming value transformation” on the channel directly instead of using a rule.