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

[knx] Thing channelTypeUID isn't displayed correctly when using *-control channel #9462

Closed
udo1toni opened this issue Dec 22, 2020 · 3 comments
Labels
bug An unexpected problem or unintended behavior of an add-on

Comments

@udo1toni
Copy link
Contributor

Expected Behavior

If using a *-control channel Type, "Control" should be displayed in addition to the general Type (Switch, Dimmer...)

Steps to Reproduce (for Bugs)

Create a *-control Channel in a knx thing and save. Look at the configuration...

This issue is available in openHAB2.x as well as in openHAB3 :)

@udo1toni udo1toni added the bug An unexpected problem or unintended behavior of an add-on label Dec 22, 2020
@Confectrician
Copy link
Contributor

Confectrician commented Dec 26, 2020

Related to openHAB 3:

I have faced a similar issue during configuration.
At least for the DateTime Control channel it is correct.

Example:
image

For the configuration part it seems to look good except for the DateTime Control channel type.

image

But that's just i wrong xml definition which i have checked some minutes ago in the repo.

Edit:

Wrong xml definition for DateTime Control can be found here:
https://github.com/openhab/openhab-addons/blob/main/bundles/org.openhab.binding.knx/src/main/resources/OH-INF/thing/device.xml#L146

holgerfriedrich added a commit to holgerfriedrich/openhab-addons that referenced this issue May 10, 2022
Control items are correctly added to json config and properly displayed.
Fixes openhab#9462.

Signed-off-by: Holger Friedrich <mail@holger-friedrich.de>
holgerfriedrich added a commit to holgerfriedrich/openhab-addons that referenced this issue May 11, 2022
KNX addon provides two channels types with different semantics for each
data type. The channel description has been updated to allow
distinguishing the channels with same type in the list of channels in
UI. Refers to openhab#9462.

Signed-off-by: Holger Friedrich <mail@holger-friedrich.de>
holgerfriedrich added a commit to holgerfriedrich/openhab-addons that referenced this issue May 11, 2022
KNX addon provides two channels types with different semantics for each
data type. The channel description has been updated to allow
distinguishing the channels with same type in the list of channels in
UI. Refers to openhab#9462.

Signed-off-by: Holger Friedrich <mail@holger-friedrich.de>
holgerfriedrich added a commit to holgerfriedrich/openhab-addons that referenced this issue May 11, 2022
KNX addon provides two channels types with different semantics for each
data type. The channel description has been updated to allow
distinguishing the channels with same type in the list of channels in
UI. Refers to openhab#9462.

Signed-off-by: Holger Friedrich <mail@holger-friedrich.de>
holgerfriedrich added a commit to holgerfriedrich/openhab-addons that referenced this issue May 11, 2022
KNX addon provides two channels types with different semantics for each
data type. The channel description has been updated to allow
distinguishing the channels with same type in the list of channels in
UI. Refers to openhab#9462.

Signed-off-by: Holger Friedrich <mail@holger-friedrich.de>
@holgerfriedrich
Copy link
Member

This is how the items are displayed at the moment:

grafik

You can check the conversation I had with @kaikreuzer in #12710 on improving the textual description.
The outcome was not the change it.

@udo1toni @kaikreuzer shall we close this ticket?

@kaikreuzer
Copy link
Member

Yep, let's close it - since the description shows the fact that these are control channels, the user is able to distinguish them.

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 a pull request may close this issue.

4 participants