Skip to content
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

Open
wants to merge 28 commits into
base: main
Choose a base branch
from

Conversation

andrewfg
Copy link
Contributor

@andrewfg andrewfg commented Jan 20, 2025

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]

@andrewfg andrewfg added the enhancement An enhancement or new feature for an existing add-on label Jan 20, 2025
@andrewfg andrewfg self-assigned this Jan 20, 2025
@andrewfg andrewfg requested a review from J-N-K as a code owner January 20, 2025 18:33
@andrewfg andrewfg marked this pull request as draft January 20, 2025 18:33
Signed-off-by: Andrew Fiddian-Green <[email protected]>
@andrewfg
Copy link
Contributor Author

@jimtng @mherwege for info..

@andrewfg andrewfg changed the title [basicprofiles] Improve StateFilterProfile unit based calculations [basicprofiles] Normalise StateFilterProfile calculations to use the linked Item's Unit Jan 21, 2025
@andrewfg andrewfg changed the title [basicprofiles] Normalise StateFilterProfile calculations to use the linked Item's Unit [basicprofiles] Normalise StateFilterProfile calculations to use linked Item's Unit Jan 21, 2025
Signed-off-by: Andrew Fiddian-Green <[email protected]>
Signed-off-by: Andrew Fiddian-Green <[email protected]>
Signed-off-by: Andrew Fiddian-Green <[email protected]>
@andrewfg andrewfg added the awaiting other PR Depends on another PR label Jan 23, 2025
@andrewfg andrewfg requested a review from jimtng January 23, 2025 18:38
@andrewfg andrewfg marked this pull request as ready for review January 23, 2025 18:38
Signed-off-by: Andrew Fiddian-Green <[email protected]>
@andrewfg andrewfg changed the title [basicprofiles] Normalise StateFilterProfile calculations to use linked Item's Unit [basicprofiles] StateFilterProfile calculations use linked Item's Unit Jan 23, 2025
@andrewfg andrewfg changed the title [basicprofiles] StateFilterProfile calculations use linked Item's Unit [basicprofiles] StateFilterProfile calculations use linked Item SystemUnit Jan 23, 2025
Signed-off-by: Andrew Fiddian-Green <[email protected]>
Signed-off-by: Andrew Fiddian-Green <[email protected]>
Signed-off-by: Andrew Fiddian-Green <[email protected]>
@andrewfg andrewfg changed the title [basicprofiles] StateFilterProfile calculations use linked Item SystemUnit [basicprofiles] StateFilterProfile use linked Item SystemUnit Jan 24, 2025
@andrewfg andrewfg changed the title [basicprofiles] StateFilterProfile use linked Item SystemUnit [basicprofiles] StateFilterProfile uses linked Item SystemUnit Jan 24, 2025
Signed-off-by: Andrew Fiddian-Green <[email protected]>
@andrewfg andrewfg changed the title [basicprofiles] StateFilterProfile uses linked Item SystemUnit [basicprofiles] StateFilterProfile uses linked Item system unit Jan 27, 2025
@andrewfg andrewfg added bug An unexpected problem or unintended behavior of an add-on and removed enhancement An enhancement or new feature for an existing add-on labels Jan 27, 2025
@andrewfg andrewfg changed the title [basicprofiles] StateFilterProfile uses linked Item system unit [basicprofiles] StateFilterProfile now uses linked Item system unit Feb 3, 2025
Signed-off-by: Andrew Fiddian-Green <[email protected]>
Signed-off-by: Andrew Fiddian-Green <[email protected]>
Signed-off-by: Andrew Fiddian-Green <[email protected]>
@andrewfg andrewfg changed the title [basicprofiles] StateFilterProfile now uses linked Item system unit [basicprofiles] Fix: StateFilterProfile to use linked Item system unit Feb 8, 2025
@andrewfg andrewfg changed the title [basicprofiles] Fix: StateFilterProfile to use linked Item system unit [basicprofiles] Fix StateFilterProfile to use linked Item system unit Feb 8, 2025
Signed-off-by: Andrew Fiddian-Green <[email protected]>
Signed-off-by: Andrew Fiddian-Green <[email protected]>
@andrewfg andrewfg removed the awaiting other PR Depends on another PR label Feb 9, 2025
@andrewfg
Copy link
Contributor Author

andrewfg commented Feb 9, 2025

@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?

Copy link
Contributor

@jimtng jimtng left a 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)?

@@ -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;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What is the difference?

Copy link
Contributor Author

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;
}
Copy link
Contributor

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?

Copy link
Contributor Author

@andrewfg andrewfg Feb 9, 2025

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. ??

Copy link
Contributor

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah yes.

Comment on lines +836 to +837
return hasSystemUnit() //
? toSystemUnitQuantityType(state) != null
Copy link
Contributor

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?

Copy link
Contributor Author

@andrewfg andrewfg Feb 9, 2025

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.

@andrewfg
Copy link
Contributor Author

andrewfg commented Feb 9, 2025

how would it handle the scenario when linked to an item with unit, but the condition is OtherItem1 > OtherItem2

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.

@andrewfg

This comment was marked as resolved.

Signed-off-by: Andrew Fiddian-Green <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug An unexpected problem or unintended behavior of an add-on
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[basicprofiles] Calculations over series of QuantityType are based on the wrong Unit
2 participants