-
-
Notifications
You must be signed in to change notification settings - Fork 3.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[basicprofiles] Fix StateFilterProfile to use linked Item system unit #18144
base: main
Are you sure you want to change the base?
Conversation
Signed-off-by: Andrew Fiddian-Green <[email protected]>
Signed-off-by: Andrew Fiddian-Green <[email protected]>
Signed-off-by: Andrew Fiddian-Green <[email protected]>
Signed-off-by: Andrew Fiddian-Green <[email protected]>
Signed-off-by: Andrew Fiddian-Green <[email protected]>
Signed-off-by: Andrew Fiddian-Green <[email protected]>
Signed-off-by: Andrew Fiddian-Green <[email protected]>
Signed-off-by: Andrew Fiddian-Green <[email protected]>
Signed-off-by: Andrew Fiddian-Green <[email protected]>
Signed-off-by: Andrew Fiddian-Green <[email protected]>
Signed-off-by: Andrew Fiddian-Green <[email protected]>
Signed-off-by: Andrew Fiddian-Green <[email protected]>
Signed-off-by: Andrew Fiddian-Green <[email protected]>
Signed-off-by: Andrew Fiddian-Green <[email protected]>
Signed-off-by: Andrew Fiddian-Green <[email protected]>
Signed-off-by: Andrew Fiddian-Green <[email protected]>
Signed-off-by: Andrew Fiddian-Green <[email protected]>
Signed-off-by: Andrew Fiddian-Green <[email protected]>
Signed-off-by: Andrew Fiddian-Green <[email protected]>
Signed-off-by: Andrew Fiddian-Green <[email protected]>
Signed-off-by: Andrew Fiddian-Green <[email protected]>
Signed-off-by: Andrew Fiddian-Green <[email protected]>
Signed-off-by: Andrew Fiddian-Green <[email protected]>
Signed-off-by: Andrew Fiddian-Green <[email protected]>
@jimtng good news that all your PRs have all now been merged; which means that this one is also now ready to go: => could you please have a look at it? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Very nice refactorings!
One thing I'm wondering about is how would it handle the scenario when linked to an item with unit, but the condition is OtherItem1 > OtherItem2
(i.e. nothing to do with the linked item)?
.../src/main/java/org/openhab/transform/basicprofiles/internal/profiles/StateFilterProfile.java
Outdated
Show resolved
Hide resolved
@@ -603,7 +635,7 @@ public int getWindowSize() { | |||
// the previous state is kept in the acceptedState variable | |||
return 0; | |||
} | |||
return windowSize.orElse(DEFAULT_WINDOW_SIZE); | |||
return windowSize.isPresent() ? windowSize.get() : DEFAULT_WINDOW_SIZE; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What is the difference?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It eliminates the yellow squiggly underline compiler warning in Eclipse IDE :)
@@ -342,6 +354,9 @@ public boolean check(State input) { | |||
if (rhsFunction.alwaysAccept()) { | |||
return true; | |||
} | |||
if (rhsFunction.getType() == FunctionType.Function.DELTA) { | |||
isDeltaCheck = true; | |||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This does seems like a better place for it, so can we remove the same code further down, i.e. line 415-418?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
can we remove the same code further down
Umm not sure. The first sets isDeltaCheck
if LHS is a function, and the second does it if RHS is. ??
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not talking about the lhs (line 404-406). I'm talking about line 415-418 - that's also rhs.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah yes.
return hasSystemUnit() // | ||
? toSystemUnitQuantityType(state) != null |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we avoid calling toSystemUnitQuantityType repeatedly? It was already done in isAllowed
and also it's called a lot in other places. Do we need to cache the result?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a very valid question. The thing about toSystemUnitQuantityType
is that it converts incoming QuantityType
to the system unit, but returns null if the conversion fails or if the incoming State
is not a QuantityType
. So in input
, newState
, acceptedState
and previousStates
I think we cannot store the result after toSystemUnitQuantityType
but must instead store them in original raw form. I suppose we could create parallel variables input
, newState
, acceptedState
and previousStates
to cache post conversion states. ?? Or we could convert input
, newState
, acceptedState
and previousStates
rather than holding a single State to hold an Entry<State, State>
that contains both original and cached post conversion versions. But that would be quite hairy code, so I elected to convert everything on the fly.
Good question. If I recall correctly I think the code converts 'OtherItem' to the string representation of its State, and then the string is handled in the same way as one hard coded in the condition LHS / RHS. So if 'OtherItem' was a QuantityType we would attempt to convert it to the systemUnit. And in the case 'OtherItem1 < OtherItem2' .. if either or both would not convert to systemUnit we would have an error -- which I guess means that the input State is rejected?? PS in any case I will add some JUnit tests.. => EDIT: I see that there are actually already many such tests .. and they all still pass. |
This comment was marked as resolved.
This comment was marked as resolved.
Signed-off-by: Andrew Fiddian-Green <[email protected]>
Resolves #18122
There is a bug whereby the calculations over a StateFilterProfile set of time series state values are based on the Unit of the first member in the set of values. There are two problems: a) the order of the state values is not relevant, and b) the Unit of the incoming state values is not definitive to the Unit of the expected result. Therefore these calculations do produce variable and unexpected results.
This PR fixes the bug by normalising the calculations so that they are all based on the Unit of the target Item to which the StateFilterProfile is linked.
Furthermore this PR allows conversion between non- inverted and inverted Units so invertible conversions (e.g. Kelvin <=> Mirek) are supported.
And finally it also provides better support for cases where the binding may provide state updates in different mixed formats e.g. a mixture of QuantityType with different base units, UndefType, and various States that can yield a DecimalType value.
Signed-off-by: Andrew Fiddian-Green [email protected]