OK, that’s a third party transformation. There might be a bug there. I’m not sure how where (binding or profile).
Here’s a bit of a deep dive into the different between a command and an update in OH.
A command is something sent to an Item asking an actuator to activate (e.g. turn on the light). Commands do not, by themselves, change the state of an Item. When a command is sent to an Item, that command gets picked up by the binding and sent out to the actual device.
So how does the Item change as a result of a command? There are two ways. First, there’s autoupdate. This is a service in OH that sees the command and predicts what state the Item will become as a result of doing what the command asked. When ever you see “predicted to become”, that’s autoupdate. Autoupdate can be turned off on an Item by Item basis in Item metadata. Autoupdate is turned on by default.
The second way is that the binding waits for the device to report it’s new state and then issues an update to the Item. This should not generate an infinite loop because, unlike commands, updates to Items are ignored by the bindings.
Based on your logs, something is issuing a command to the Item when an update is required. I’d be inclined to blame the multiply profile for no other reason than it’s not used as much by the community and I’ve not seen an error like this reported before. But that’s not definitive.
What if you did a transform profile with ECMAScript profile. This profile lets you set a different transformation based on the direction of the data flow and it is possible to set an inline script so it’s just about as easy to set up.
For the “Thing to Item” transform use
JS(| (parseFLoat(input) / 2) + ' °C')
and for the “Item to Thing” transform use
JS(| parseFloat(input) * 2)
Eliminate all rules that may command this Item for now. You can just disable them by clicking the pause icon at the top right.
The way it’s supposed to work:
a command is sent to the Item from somewhere in OH
command is processed in parallel
a. autoupdate predicts then updates the Item to that newly predicted state
b. link picks up the command, transforms it through the profile, sends transformed value to binding which in turn sends it to the device, device reports back it’s new state to the binding which updates the Item, transforming the value through the profile first.
I know for a fact that autoupdate isn’t sending a command. It seems a pretty basic error for the profile to be sending a command here. The developer of smarthome/j knows better. So now I’m wondering if you might have a rule you’ve not mentioned or something.