UI fails to get Channel-Type when creating Items

[andrewfg]

Issue

The issue is in Main UI when I try to create an Item linked to a structured dynamic channel, it does not find the respective Channel-Type data. Which means that the UI lacks the full information to properly create the Item.

The UI gives fore warning of such issue by marking the channel UID with a ? mark indicating that the type information cannot be found..

Intro

I am working on a PR to implement a HomeKit client in OH and I am facing a difficulty which to be honest I am not sure is an issue in OH Core, Main UI, or the binding itself. But I am posting it here first in order to at least start somewhere :)

Background

The HomeKit architecture has three levels -- namely 'Accessory' entities which represent devices, where each Accessory implements multiple 'Service' entities, and each Service implements multiple 'Characteristic' entities which represent a single data point. The binding models Accessories as Things, Services as Channel-Groups, and Characteristics as Channels.

Code flow

In step 1 of initialization, the bridge handler fetches the full tree of Accessory, Service, Characteristic and builds a list of Channel-Types from the Characteristics, and a list of Channel-Group-Types from the Services. These types are persisted via an AbstractStorageBasedTypeProvider overridden class. The bridge handler also builds child accessory discovery results from the Accessories and places them in the Inbox.

Channel Group Types in AbstractStorageBasedTypeProvider overridden class

``` { "homekit:channel-group-type-lightbulb": { "class": "org.openhab.core.thing.binding.AbstractStorageBasedTypeProvider$ChannelGroupTypeEntity", "value": { "uid": { "segments": [ "homekit", "channel-group-type-lightbulb" ], "uid": "homekit:channel-group-type-lightbulb" }, "label": "Channel group type: Light Bulb", "channelDefinitions": [ { "id": "on", "uid": { "segments": [ "homekit", "channel-type-on" ], "uid": "homekit:channel-type-on" }, "label": "On", "properties": { "format": "bool", "iid": "9", "perms": "pr,pw,ev" } }, { "id": "brightness", "uid": { "segments": [ "homekit", "channel-type-brightness" ], "uid": "homekit:channel-type-brightness" }, "label": "Brightness", "properties": { "format": "int", "iid": "10", "maxValue": "100.0", "minStep": "1.0", "minValue": "0.0", "perms": "pr,pw,ev", "unit": "%" } } ] } } } ```

Channel Types in AbstractStorageBasedTypeProvider overridden class

``` { "homekit:channel-type-brightness": { "class": "org.openhab.core.thing.binding.AbstractStorageBasedTypeProvider$ChannelTypeEntity", "value": { "uid": { "segments": [ "homekit", "channel-type-brightness" ], "uid": "homekit:channel-type-brightness" }, "label": "Channel type: Brightness", "advanced": false, "itemType": "Dimmer", "kind": "STATE", "tags": [ "Brightness", "Setpoint" ], "category": "light" } }, "homekit:channel-type-on": { "class": "org.openhab.core.thing.binding.AbstractStorageBasedTypeProvider$ChannelTypeEntity", "value": { "uid": { "segments": [ "homekit", "channel-type-on" ], "uid": "homekit:channel-type-on" }, "label": "Channel type: On", "advanced": false, "itemType": "Switch", "kind": "STATE", "tags": [ "Power", "Switch" ], "category": "switch" } } } ```

Then in step 2 of initialization, the child accessory handlers build their Channels dynamically, with reference to the previously created Channel-Types and Channel-Group-Types that have been created and stored in the AbstractStorageBasedTypeProvider.

So in summary we end up with the following tree:

=> Thing instances created from Inbox
==> Dynamic Channel-Group instances referring to an AbstractStorageBasedTypeProvider entry
===> Dynamic Channel instances referring to an AbstractStorageBasedTypeProvider entry

Tests confirm that issue is in OH Core or OH UI and not the binding

The binding Junit tests confirm that the dynamic channel definitions do indeed link to the created Channel-Types and Channel-Group-Types. And furthermore I have now added code into the binding so that it successfully loads both the Channel-Types from the OH ChannelTypeRegistry and the Channel-Group-Types from the OH core ChannelGroupTypeRegistry.

[andrewfg]

PS I have been snooping the UI web traffic, and I can see that when the UI loads the channels, it does indeed get the full data about the channel (see below) including the "channelTypeUID": "homekit:channel-type-brightness". However in the 'Link Channel to Item' screen it nevertheless 1) displays the '(?)' flag, and 2) does not pass some of the Channel-Type information to the new Item being created. It seems that the Item Type is not passed, but the tags and icon/category are passed. Very strange.

---

---

 "channels": [
        {
            "linkedItems": [],
            "uid": "homekit:accessory:8e2a9e4bff1:73418603:lightbulb#brightness",
            "id": "lightbulb#brightness",
            "channelTypeUID": "homekit:channel-type-brightness",
            "kind": "STATE",
            "label": "Brightness",
            "defaultTags": [],
            "properties": {
                "maxValue": "100.0",
                "iid": "10",
                "unit": "%",
                "format": "int",
                "minStep": "1.0",
                "minValue": "0.0",
                "perms": "pr,pw,ev"
            },
            "configuration": {}
        }
    ],

---

EDIT: I can see that it also downloads the Channel-Type record (see below) .. so that explains why it can get the tags and the icon .. however it does not explain why the channel UID is flagged with '(?)' nor why the Item creation page does not take the 'itemType' .. curioser and curioser..

{
        "parameters": [],
        "parameterGroups": [],
        "label": "Channel type: Brightness",
        "category": "light",
        "itemType": "Dimmer",
        "kind": "STATE",
        "tags": [
            "Setpoint",
            "Brightness"
        ],
        "UID": "homekit:channel-type-brightness",
        "advanced": false
    }

[andrewfg]

@mherwege or @florian-h05 I wonder if either of you could kindly help me to debug this? The issue is that when I try to create a new item linked to a channel which is linked to a channel type, the UI shows (?) and the offered Item type is always "Switch" instead of (in this case) "Dimmer".

I have been trying to debug the UI code, but since I don't understand it at all, I am really struggling to make any progress. The issue is caused in 'link-add.vue' where apparently the UI either not getting the channel itself (unlikely) or not getting the channel accepted item type. And because of this the selection in 'item-form.vue' is not properly initialized.

I am logging my ChannelType provider and that proves that OH Core is calling getChannelType() for the given channel, and it is definitely returning the correct channel type, and that channel type does definitely have an accepted item type. So I think this is most probably a bug in the UI code where it fails to establish the connection between the accepted item type of the ChannelType and the respective accepted item type of the actual Channel.

2025-10-08 17:06:07.412 [TRACE] [rnal.persistence.HomekitTypeProvider] - getChannelType(homekit:channel-type-brightness-b2eeee30e799) homekit:channel-type-brightness-b2eeee30e799

[andrewfg]

.. just for info .. when I try to create/link an Item to a Channel whose ChannelType is defined via channel-type xml then it looks perfectly OK .. so the issue seems only to occur when linking to a Channel whose ChannelType is defined via a custom provider. So maybe it is a caching issue .. just a thought..

[mherwege]

@andrewfg Sorry for the delay, I am quite busy at the moment.
It looks to me like the UI is only looking at the channel for the itemType, and not at the channelType. This could probably be changed, but I don’t know all consequences yet. The interesting question is if somewhere the itemType is automatically added to the channel in core for xml based definitions, and missed for the abstract provider, and why that is. Because if it works for static definitions, it must be that the channel itemType is set somewhere (looking at the UI code). Until we understand that, I am reluctant to change it in the UI.

[andrewfg]

@mherwege many thanks for the comment. It helped me a lot, by triggering a chain of thought. Indeed a Channel has four fields (acceptedItemType, channelKind, defaultTags, and autoUpdatePolicy) that could be provided by the ChannelType or could be provided by the builder. My assumption had been that when building a Channel dynamically using a ChannelBuilder if .withType(channelType.getUID()) had been called, it would automatically cause those four fields also to be populated from the channel type. But my assumption turns out to be wrong: one must in fact call all of the relevant the '.withXYZ' setters explicitly.

ChannelBuilder builder = ChannelBuilder.create(channelUID)
   .withAcceptedItemType(channelType.getItemType()) 
   .withAutoUpdatePolicy(channelType.getAutoUpdatePolicy()) 
   .withDefaultTags(channelType.getTags()) 
   .withKind(channelType.getKind()) 
   .withType(channelType.getUID());

I don't know why this is the case. And I don't know even if it is a good or bad thing. Maybe it is an architecture discussion for others above my pay grade??

the UI is only looking at the channel for the itemType, and not at the channelType. This could probably be changed, but I don’t know all consequences yet.

Good point. Apparently the UI defaultTags come from ChannelType. But perhaps you check Channel for tags, and fall back to ChannelType if missing?

By contrast icon/category and state description come from ChannelType since the Channel does not carry such fields.