I wish I could reference other items states in an item transform

[Dom-Torro (Domino Torronto)]

Sure I can set rules and go the long-haul route.

However does it not make sense to give transforms a little more dynamic flexibility to be able to ‘read’ states of other items in a transform for some ‘custom logic purposes’ on-the-fly, or is my flexibility-OCD getting in the way of rational thinking?

For example if I use a JS: transform, would be nice if I could reference other items states in the javascript file for my super amazing custom transform logic.

[rossko57]

@Dom-Torro

For example if I use a JS: transform, would be nice if I could reference other items states in the javascript file

That’s a rule in openHAB lingo, not a transformation.
For example, would you expect this ‘transform’ to operate again if one of these other Items changes? Or even just gets an update? This kind of complexity is easily managed in rule triggers, that’s exactly what they’re for.

[Dom-Torro (Domino Torronto)]

Valid point.

I’ll give you a scenario to butcher…

A HTTP thing binding…

For a channel command it hits a specific URL…
but the state for the same channel doesn’t come from a URL, it comes from a totally different thing (sensor via MQTT)…

When I set a rule trigger to update the state of the HTTP binding channel item triggered by the sensor item on update coming from MQTT subscription, it doesn’t update.

So this was where I thought it would be great to be able to do some linkage via the transform.

In general the rule-triggers work across other items, just not having any luck with a HTTP binding channel item state.

Any ideas?

[rossko57]

@Dom-Torro

When I set a rule trigger to

Show your work i.e. Items, rule.

@Dom-Torro

For a channel command it hits a specific URL…
but the state for the same channel doesn’t come from a URL, it comes from a totally different thing (sensor via MQTT)

Sounds like you want to link one Item to a write-only HTTP channel and a read-only MQTT channel. This should not be a problem, no rule required.

You might want to disable autoupdate on the Item as well.

[Dom-Torro (Domino Torronto)]

Yes you are correct, an item that has Google Assistant metadata associated to it too, the reason why I need the item to have both a command (HTTP thing channel) and a state (MQTT thing channel).

I got it working right now via a rule which runs on the update of the MQTT thing channel item, the rule sets the HTTP thing channel item state to the same state as the MQTT thing channel item. I did configure the HTTP thing channel item to a profile of ‘Follow’.

So it does work via rule trigger.

Though I am now intrigued of learning what you pointed out regarding ‘no rule required’, that sounds more efficient.

Unless you mean assigning the same item to both the HTTP thing channel and to MQTT thing channel, write in the former case and read in the latter? - just tried this and this seems to work too, no rule required.

Got there in the end, I get this deja-vu feeling that I did something like this 2 years or so ago, if only memory recall was as good as it was in my twenties.

Thanks @rossko57 - the whole reason why a community like this needs gents like you, sometimes we all need a point in the right direction.

[Dom-Torro (Domino Torronto)]

You mentioned disable autoupdate, there doesn’t appear to be an autoupdate flag in the UI, any pointers?

I see that I can create the item as item file in the items folder, but if the item is created via the UI, how does one change the autoupdate attribute for the item?

Update:

Appears Autoupdate is a Metadata flag in the item via OH3 UI.

More info: Autoupdate - a primer