OH3.1 - Dimmer items not visible on “item to link” list

I am positively surprised that the upgrade from OH2.5 to OH3.1 was painless and majority/key bindings work as before😊. With new OH3.1 I am still on RPI3B+ and it works fine.

A problem I have found is that Dimmer items defined in .item file are not visible/available for Dimmer type channels in OH3.1 on the “item to link” list.
When I select a Dimmer type channel (ex Volume) for a thing and I want to “use an Existing Item” I can not see any Dimmer Type item on the “item to link” list.
On the other side when I select a Switch type channel for a thing I can see Dimmer items on the “item to link” list
I think that also when I create a new Dimer type item directly in OH3.1 UI such an item is not available for Dimmer type channels on the “item to link” list☹

Is it somehow configurable in OH3 which item types can be assigned to which channel types or this is a bug?

It sounds like a bug. Each Channel indicates the type of Item that must be linked to it. If the Channel says it needs a Dimmer, then the list of Items should only show the Dimmer type Items I think. At a minimum it should show the Dimmer Items and not hide them.

Have you confirmed that the Items do in fact exist? You can find them in the Items settings page or in the karaf console or the REST API?

Yes, I have 3 regular Dimmer (Volumes) items + 2 new just created for testing purposes and each of them is visible in Settings->Items OH3 screen but none of them is visible on the “item to link” for Dimmer type channel.

I observed the same behaviour also with other item types. In my case the linking works by opening the item and choosing the corresponding thing from there.

It is not but natural for me to start from item first but it works. Very good “workaround” :slight_smile: Thanks!

I’d think that since linking means to change an item’s properties it won’t or at least isn’t designed to work when the item is read-only which is what items are when you defined them in files.
So even if that workaround should work I’d be wary it’ll keep working after restarts.
As the docs advise you to, don’t mix file and UI. If you define items in files, define links there, too.

This does not seem to be related to mixing file and UI config though as I don’t have any items configured in files. I see the same behaviour with only UI created things and items.

A couple of days ago I tried to setup a clean OH instance, created one thing and one item and it was the same: no items were shown on the thing side but it was working the other way round. In my production instance I get a rather short list of items when trying to link a channel to an item. The shown items do not necessarily match the type required by the thing channel. Other potentially matching items are not shown in the list at all.

Good point. But in OH2.5 I used to copy ID of the linking channel created in UI to .items file. I will keep this habit in OH3.1 and I hope it shall safe me from unexpected behaviour after reboot(?)

And I can confirm that the error itself is irrelevant of the souce of items entry. (UI, .items)

Comment; it gets complicated because use of transformation profiles allows any type channel to any type Item.
I think they were reviewing the UI to some kind of normal suggestions list, but with an ‘advanced’ button for listing every Item.

It should work unless you change things (and their channels with them).
BTW all of this has not changed since 2.X.

But mixing is never a good idea. If you link in UI to a (file-defined) item and later on remove that item from the file, you’ll have a dangling link.