Office_Temperature is probably a dimensioned item in the author’s system. I’m rusty with my Python (I actually learned python because of openHAB to use Jython in 2019)
>>> float(str("1.5 °F"))
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
ValueError: could not convert string to float: '1.5 °F'
so the whole .getStateAs(QuantityType).toUnit(ImperialUnits.FAHRENHEIT).floatValue() seems necessary to me, and he probably wanted to make sure he’s working in Fahrenheit even if the item is in celsius.
I suspect it was more a case of “This is the rule that I had written in Jython, and this is how I converted it to JRuby”. I mean, the sets of conditions were pretty uniquely peculiar to start with.
I changed it back to the way the item values were accessed before, to avoid str/float conversion that can break your neck when it comes to locale dependent decimal points and stuff, so now the only significant change is that I replaced the wrong operator with the Python ones
Good enough for a PR though.
I see it was already committed an hour ago, just leave it as it is right now, I’m totally fine with it. I’m happy to help improve the example, and it was a pleasure to play around with the code
This is true in Rules DSL too. I ran into that a long time ago when I tried to use an Item as a key in a Map instead of the name of the Item.
I’m not sure about JS Scripting. I suspect it does something. similar to jRuby, but I never looked.
Both jRuby and JS Scripting try to manage those conversions in the add-on/helper library so you end up working with native Objects that work in typical ways for the language. The developer of the Jython Helper library chose the opposite route and tried to keep openHAB stuff Java, but as a result you have to be careful to know when you are working with Java and when you are working with Python types.
Both approaches have their advantages and disadvantages.
JS Scripting‘s items.getItem is actually calling ItemRegistry.getItem and creating a JS Item from it without any caching.
So as long as you don’t load an Item as constant in file-based rules outside of the rules callback, I don’t suspect that issue to occur.
For UI-based rules that would need to be tested, since the whole lifecycle thing is different there.
Since there is no “outside the rule” in this case, I don’t think there would be a problem. Unless you put it into the cache you’d be pulling the Item from the registry every time the rule runs so it shouldn’t get stale. If you do put the Item into the cache, well that would probably be a problem though, but that’s true in the UI or file based rules.
