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

ProfileTypeBuilder.withSupportedChannelTypeUIDs is ignored by StateProfileTypeImpl #4293

Open
obones opened this issue Jul 2, 2024 · 4 comments · May be fixed by #4325
Open

ProfileTypeBuilder.withSupportedChannelTypeUIDs is ignored by StateProfileTypeImpl #4293

obones opened this issue Jul 2, 2024 · 4 comments · May be fixed by #4325
Labels
bug An unexpected problem or unintended behavior of the Core

Comments

@obones
Copy link

obones commented Jul 2, 2024

When writing an addon that provides a transformation profile one will most likely use ProfileTypeBuilder to get an instance of ProfileType to be returned by the ProfileTypeProvider.getProfileTypes implementation.

This is can be done with code like this:

            return ProfileTypeBuilder
                    .newState(uid, "Label")
                    .build();

With the code above, the transformation profile is usable for any item and any channel, which may not be desirable and so one may want to call withSupportedChannelTypeUIDs to limit the transformation profile to a given channel type.

Expected Behavior

When withSupportedChannelTypeUIDs has been called on ProfileTypeBuilder, the created transformation profile should only appear on item links that are between any item and a channel only of the given type UID.

Current Behavior

Sadly, the profile above is shown for links on any channel, there are no filtering done.
This is because ProfileTypeBuilder.newState sets up a callback that ignores leSupportedChannelTypeUIDs at this line

Possible Solution

I would suggest changing StateProfileTypeImpl to accept supportedChannelTypeUIDs in its constructor and override getSupportedChannelTypeUIDs just like TriggerProfileTypeImpl does.
Note that this would only fix the current issue, but I believe both StateProfileTypeImpl and TriggerProfileTypeImpl should override the three possible filtering sources, not two each like now.

Steps to Reproduce (for Bugs)

  1. Create an addon that implements a ProfileTypeProvider service
  2. Use ProfileTypeBuilder.newState alongside withSupportedChannelTypeUIDs
  3. See that the transformation profile is not filtered out and available on all channel links

Context

I'm currently trying to offer transformation profiles for Air Quality Indicator channels in my OpenMeteo binding and would like them to be limited to channels they apply to.

Your Environment

  • Version used: openHAB 4.2 snapshot
  • Environment name and version : Java 17
  • Operating System and version : Windows 10-11
@obones obones added the bug An unexpected problem or unintended behavior of the Core label Jul 2, 2024
@J-N-K
Copy link
Member

J-N-K commented Jul 14, 2024

I see your use-case. I think there never was a discussion about filtering StateProfiles by ChannelTypeUID. I would vote for adding that.

@J-N-K
Copy link
Member

J-N-K commented Jul 18, 2024

Can you prepare a pull request?

@openhab-bot
Copy link
Collaborator

obones added a commit to obones/openhab-core that referenced this issue Jul 22, 2024
…o the ProfileType interface so that StateProfileType and TriggerProfileType can both take the three filter lists given by ProfileTypeBuilder

Fixes openhab#4293
obones added a commit to obones/openhab-core that referenced this issue Jul 22, 2024
…o the ProfileType interface so that StateProfileType and TriggerProfileType can both take the three filter lists given by ProfileTypeBuilder

Fixes openhab#4293

Signed-off-by: Olivier Sannier <[email protected]> (github: obones)
obones added a commit to obones/openhab-core that referenced this issue Jul 22, 2024
…o the ProfileType interface so that StateProfileType and TriggerProfileType can both take the three filter lists given by ProfileTypeBuilder

Fixes openhab#4293

Signed-off-by: Olivier Sannier <[email protected]> (github: obones)
Signed-off-by: OBones <[email protected]>
@obones
Copy link
Author

obones commented Jul 22, 2024

I have submitted PR #4325, I hope it's fine as I could not find any related unit tests.

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 the Core
Projects
None yet
3 participants