They are Items. You reference them like any other Items, by their name (not the label). What makes them a Point is the tags applied to the Items. There isn’t anything else special about them.
Well, then there is a complete misunderstanding of anything I try to memorize for rules.
The engine confuses me altogether,
Meanwhile, I changed the complete comparison stuff into variables first and still failing the following code:
val temp = Whirlpool_TargetTemperature.state as Number;
logInfo("balboa.HeatUpManually.Before", 'Whirlpool_TargetTemperature: ' + temp);
if (temp < 39)
{
logInfo("balboa.HeatUpManually", ">> Whirlpool_TargetTemperature needs Update");
}
else
{
logInfo("balboa.HeatUpManually", ">> Whirlpool_TargetTemperature is high enough");
}
The output of these commands is:
2021-02-09 08:06:27.449 [INFO ] [.script.balboa.HeatUpManually.Before] - Whirlpool_TargetTemperature: 38.0 °C
2021-02-09 08:06:27.454 [INFO ] [e.model.script.balboa.HeatUpManually] - >> Whirlpool_TargetTemperature is high enough
So in the end, there are two questions left:
why is the content of “temp” now “38.0 °C”, rather than just “38” or “38.0”, it is supposed to be a number ?
This is absolutely and completely Contra-Intuitive.
A Number and it’s textual view have nothing to do with eachother.
I need a simple NUMBER (Decimal, to be more precise) I can use (as in all programming laguages I know) to do math and comparisons with.
What if the Unit is also not fixed as °C, but can be either - depending on another setting be °F as well?
Then there is some error that is causing it to be loaded with a Quantity value.
Most likely you have linked a Number type Item to a number:temperature type channel of a binding?
Or maybe the way you created the Item has produced a Number:Temperature type without you realizing?
but this means that the rules from 2.5 cannot be used with 3.0 anymore and need to be rewritten,
which is a pain in the a** as there is no support - no debugger - no intellisense.
And more problematic, no consistent information anywhere. Just bits and pieces somewhere.
Anyway - I will eventually get somewhere and I will not touch the system for 3 more years.
Yes, that happens with version changes. There are other rule breaking changes too - datetime handling, exec action, etc.
What you seem to be really grizzling about is changes in the binding(s), if they are now supplying different data. Quantity types existed in OH2, but fewer bindings took advantage of them.
You are not forced to change to 3.0 - OH 2.5 continues to do what it does. Unless you have need of some umm change it provides.
I’ve still got an OH1 instance pottering away.
Sorry, that “missing support” was not meant to be from the community, was talking about the documentation.
I apologize. Your input is much appreciated.