[MainUI] Channels without channelType are not visible in the UI

[marcelrv]

If a dynamic channel is created without the .withType(channelTypeUID) part it is not shown in the channel list of the item in MainUI.

Channel channel = ChannelBuilder.create(channelUID), itemType)
                .withLabel(label).build();
updatedThing.withChannel(channel);

Same channel created with type is shown. As channelType is not mandatory, the channel should be visible either way

[ghys]

are there cases of channels created without a channel type?
(genuine question, I'm struggling to understand)

[marcelrv]

Unless there are special needs, that would require a type, I think dynamic channels are created without type.

[lolodomo]

Do we have an example somewhere of a channel without channel type? I am currently working on a new binding that require building channels dynamically, so I am very interested by this point.

@kaikreuzer : can we have your vision on this question? Is a channel type something optional for a channel? Is it a binding bad implementation to not define it? Or not?

[marcelrv]

I think would indeed be good to have the perspective of @kaikreuzer
I did quick search for "ChannelBuilder.create" in the addons repository, on the first page of search results, there are already several bindings that create it without a .withType... so if that is required there is quite some work ahead.

[kaikreuzer]

Hm, I cannot really give you a good answer here.
The initial idea was definitely to use the channel types merely as a kind of template and have the channels be "self-contained" and not require a type definition at runtime anymore. But afair, over time new stuff came into the channel types, which were not reflected in the channels themselves and so there were situations already where access to types was required. I also remember having had a discussion before whether types have to be mandatory, but I cannot remember details nor find a reference to that discussion (@wborn and @cweitkamp, maybe you were involved as well and have better memories?).

But since @marcelrv says that there are several bindings creating channels without a type, our assumption should (still) be that this is valid. @ghys Is this causing some bigger issues for the UI or is it something that can be dealt with?

[cweitkamp]

I cannot remember a discussion about channel types to become mandatory too. The last thing which came to my mind was a fix for OHC which handles a NPE when updating a thing with channels that have no channel type via REST interface. Therefore we implemented openhab/openhab-core#1346. For OHC it is still valid to have channels without channel types. Even if I would recommend to define a channel type because - as already mentioned - it contains metadata like state or command description which can be useful for UIs.

[ghys]

@ghys Is this causing some bigger issues for the UI or is it something that can be dealt with?

A little yes, there are a lot of places where the channel type is supposed to be present, as I (apparently wrongly) assumed it was an essential part of the channel definition, and info is often taken from the type rather than the channel.

[kaikreuzer]

A little yes

I take this expression as "I can deal with it and let us stick with not requiring types for channels".
If this is a false assumption, speak up loudly, please 😉 .

[ghys]

It was along the lines of "I have to check, there 154 references to the term ChannelType in the code so it's going to be a little tedious, but I'll guess we can make it work" :)

@marcelrv do you have a reproductible case of a binding making channels with no type, please?

[marcelrv]

I noticed the issue while testing my miio binding, as some of the channels did not show up. I traced the issue back to the missing channeltype.

I see other places as well e.g.
https://github.com/openhab/openhab-addons/blob/cafa8fdcff63f6efd9301a413f800d21e98ca66a/bundles/org.openhab.binding.somfytahoma/src/main/java/org/openhab/binding/somfytahoma/internal/handler/SomfyTahomaBaseThingHandler.java#L77

but there are less instances than I originally thought, as most of the examples I initially found with search were testCases rather than normal binding files.

Note as a thought to simplify the solution... maybe instead of fixing the 154 references, the framework can return some generic channeltypes (e.g. based on the acceptedItemType) for channels that are created without one (or with a null channeltype)