Sorry - I ended up working on your PR for longer than I thought (most of the afternoon) and then I had to run away so I didnât have time to elaborate on what I did.
Actually I had this idea that this one could warrant its own block, because it is quite different than the others (sum, average, min/max etc.) as it doesnât necessarily return a decimal number, rather a state corresponding to the type of the item. Also there is the quite useful skipEqual
option that could be added as a checkbox on the block. So I removed it with the intent of readding it this week as a separate block.
I saw that you reused the EphemerisDate & EphemerisDay types & blocks in the persistence category to specify the dates, which wasnât quite right. So I renamed them to ZonedDateTime
and DayOffset
. Note that the PersistenceExtensions methods donât accept a day offset, only a ZonedDateTime.
But by having a dropdown with hardcoded values, you arbitrarily exclude other transformations (JS, Jinja, Scale, XPath etc.) from being able to be used, and also the user still has to figure out that the corresponding add-ons have to be installed. So I would prefer keeping it open and reinstating the dropdown when we figure out a way to list only those transformations that can be used. Or figure out an UI that has the suggestions, like with the dropdown, but doesnât limit the available choices to them (I havenât got a solution for that).
I would prefer the original comparison block to work, but I donât know if itâll be possible. The problem is that indeed the oh_getitem_state
block returns a string because it is, in fact, a string, as the API always returns states as strings. But behind it could be any type of state. So at first it could make sense to not set an output type so it becomes compatible with any block. Thatâs basically what happens when you put the state in a variable - you lose the type information.
However thatâs not the best either because while in many cases it will work as expected, due to the way JavaScript handles comparisons, it is not at all guaranteed.
https://javascript.info/comparison#comparison-of-different-types
The 2 last results in the example above are unfortunate.
The other issue is that standard JS comparisons donât work with QuantityTypes i.e.:
var QuantityType = Java.type("org.openhab.core.library.types.QuantityType");
var x = new QuantityType("100 °F");
var y = new QuantityType("35 °C");
var z = new QuantityType("40 °C");
print(x);
print(y);
print(x < y);
print(x < z);
print(x.compareTo(y));
print(x.compareTo(z));
returns:
100 °F
35 °C
false // correct
false // incorrect!
1 // correct
-1 // correct
So in the end we might indeed have to provide a comparison block explicitely for QuantityTypes which would use âcompareToâ under the hood - even though Iâm not very happy about it as it adds to the confusion.