OH3: Is there a best way to dissect JSON into item values?

  • openHABIAN 3.3.0 on rPi4

I get that best means different things to different people…

However, I am asking here for some guidance, if there is a good way to dissect JSON strings?

The background:
I have a bunch of RF433 devices that send messages at a rate of 15 strings per minute.

On my OH2 rPi, a rev 3, I had to lock the rule, to process the rule completely before the input changed (with the arrival of another JSON message, potentially ignoring others in the process (I never tested hits, and also did not notice a negative impact, as in loosing messages).

On my rPi4 OH3 machine, processing does not seem to be an issue.

However, I have two rules, dealing with the same message, but filtering for different senders.
E.g, one rules does the weather station, th other all temperature, door and window sensors.

So I wonder, should I merge the two rules, or create even more rules dealing with specific actions.

Also, is it the right approach to update an item with the JSON string and then process it, or is there a faster way?

Any hints or commentary appreciated.

JSONPATH analyse utility is one of the available transformation services.

Yes, thanks, I should have stated that; e.g.:

val String model = transform("JSONPATH", "$.model", rtl433_json)

I have since combined the two rules into one.
So far so good :slight_smile:

This is no longer necessary. Only one instance of a given rule can run at a time in OH 3. Subsequent triggers of the rule will be queued up and run in sequence. The locking and queueing will be handled for you. If you’ve any rules that still use locks, remove the locks.

However, if the Item is updating fast enough, you’ll probably want to use the implicit variables rather than the Item’s states. See Rules | openHAB. Presumably the triggering Item will contain the full JSON string and the rule is triggered by update or changed so you’d use newState instead of MyJSONItem.state to get the state of the Item that triggered the rule at the time that the rule triggered.

What ever is easiest for you to maintain. Your brain cycles are worth way more than RAM and CPU.

The best way is to do it in the Channel(s). Many bindings, particularly those that let you manually create Channels (e.g. MQTT) you’d create a separate Channel for each piece of data in the JSON you want to parse out and send to an Item. Then each of those Channels will subscribe to the same topic. This lets the binding parse and process the JSON for you.

Failing that, the next best place is using the transform profile on the link. You would link multiple Items to the same Channel. Each would have a separate JSONPATH transform to extract just that Item’s value.

In some cases where the processing is complex (e.g. you have an array with variable length that needs to be parsed through to calculate something) a rule is going to be your only option.

2 Likes

Awesome! Thank you!

Great input; yes, I use a proxy item to hold the JSON so it won’t change when updated during processing :slight_smile:

The rule is awfully long; hence, I will check out your suggestions to have multiple channels.

You do some additional process in there it seems than just transferring the parsed out value into an Item so the rule may be required anyway. It’s hard top tell with it rolled up like that.

And if that bln433ReceiverLockIsOn variable is your lock, that’s not a very good implementation of a lock. It is possible that the timing would work out where two rules test == false before it’s set to true and you’d have had two rules running at the same time. A ReentrantLock would work better because it actually blocks the other rule from evaluating that test if there is another rule already evaluating the test.

But this is all academic. You do not need and should not use the lock anyway. It adds complexity and isn’t needed.

But keep in mind, in your previous implementation if the rule was triggered a second time while it was running it would skip that trigger. Now it will queue up and process that trigger once the first instance is done running. That’s different behavior you might need to account for.

1 Like

Thank you! :slight_smile:

The lock has been removed (back then) as suggested.
I saw a re-entrant lock commented out; much have experienced a problem with it and ditched it.