File-configured item profile is not updated in Admin UI (only after reboot) about openhab-core HOT 25 CLOSED

Is your problem reproducible by just updating an existing item inside an items file by setting the follow profile ?
Or is it the combination of creating a new item and setting the follow profile ?

from openhab-core.

The file configured setting is done 'somehow internally' but it is not reflected in the Admin UI.

Maybe a bug in Main UI ?
Did you try Ctrl+F5 or the reload app link in the about page?

from openhab-core.

I can confirm this issue even the health check is naming the not existing item

from openhab-core.

I can confirm this issue even the health check is naming the not existing item

Hello miloit,

2 questions:

• What do you mean with the non existing item? The item exists in the Admin UI and both of the channels are listed below, but the profile radio button in the UI does not switch accordingly when I add a profile to one of the channels.
• Maybe a bit off-topic, but there is a health check? Where?

Best regards,
Stefano

from openhab-core.

The file configured setting is done 'somehow internally' but it is not reflected in the Admin UI.

Maybe a bug in Main UI ? Did you try Ctrl+F5 or the reload app link in the about page?

Yes, I did. Only a restart of the OH service updated the display correctly.

from openhab-core.

I will try to reproduce an easier use case without MQTT, just adding a profile to an item in an items file

from openhab-core.

I will try to reproduce an easier use case without MQTT, just adding a profile to an item in an items file

Yes, please. And please use one item but two channels from things of different bindings configured in separate things files. I have a knx.things file and a mqtt.things file and one knx.items file that combines two channels into one item by taking one channel from two different things.

I also think that the binding does not matter. I just explained the background.

from openhab-core.

See here

https://community.openhab.org/t/openhab-4-2-milestone-discussion/154316/176?u=milo

Maybe a different topic but the failure behavior looks similar to me

Health check was newly introduced with oh4.2M4

from openhab-core.

A very simple case like this one:

Number TemperatureChambre "Température chambre [%.1f °C]" <temperature> (GSondeChambre,GTemperatureInt) [ "Measurement", "Temperature" ] {channel="rfxcom:temperaturehumidity:rfx:Chambre:temperature" [profile="offset", offset="0.6"] }

When I check the API /links for this item, it returns as expected:

[
  {
    "editable": false,
    "channelUID": "rfxcom:temperaturehumidity:rfx:Chambre:temperature",
    "configuration": {
      "offset": "0.6",
      "profile": "offset"
    },
    "itemName": "TemperatureChambre"
  }
]

But in Main UI, I see that:

@quensen : you are looking at the same screen ?

The profile was not added after OH start but was already there before I start OH. So I did not change my items file.

@florian-h05 : looks like a Main UI bug, no ?

from openhab-core.

Salut @lolodomo ,

yes, I am looking on that display, but I was talking about two items.

Salutations,
Stefan

from openhab-core.

If I create an item in UI and link it with a profile, then the same page is showing the profile:

Here is the response of the API /links:

[
  {
    "editable": true,
    "channelUID": "rfxcom:temperaturehumidity:rfx:Chambre:temperature",
    "configuration": {
      "offset": "0.5",
      "profile": "system:offset"
    },
    "itemName": "TemperatureTest"
  }
]

Interesting, profile is "system:offset" when set in UI while it is just "offset" when set in file.
@florian-h05 : could it be the source of the bug ?

from openhab-core.

yes, I am looking on that display, but I was talking about two items.

Looks like there is a bug already with a very simple use case with just one item linked to a channel with a profile.

from openhab-core.

Interesting, profile is "system:offset" while it is just "offset" in the other case.

I think system: is the default for the profile source. You can also create your own profiles. Then, you need the prefix.

from openhab-core.

I will try to use "system:offset" in my file to see if Main UI is then able to detect and show the profile. That would confirm the bug in Main UI.

from openhab-core.

And that works:

@florian-h05 : there is a clear bug in Main UI, the profile is not detected in case it does not have a prefix.
"offset" => not detected
"system:offset" => properly detected

Do you need another issue declared in webui repo ?

@quensen : as a workaround until Main UI is fixed, please add the prefix "system:" to all your profile definitions and let us know if your use case is then also OK.

from openhab-core.

We could also add system: during link creation when no prefix is present. IMO all these "implicit" prefixes should be added at the first place possible.

from openhab-core.

We could also add system: during link creation when no prefix is present. IMO all these "implicit" prefixes should be added at the first place possible.

In our current case, the link is coming from an items file and the prefix is not present.

When the profile is added with UI, like in my example with item TemperatureTest, the profile name has the prefix.

from openhab-core.

We could also add system: during link creation when no prefix is present.

Or maybe you mean when loading the file ?

from openhab-core.

Exactly, in GenericItemChannelLinkProvider when the link is created.

from openhab-core.

We could also add system: during link creation when no prefix is present. IMO all these "implicit" prefixes should be added at the first place possible.

Agreed - I do not consider it as an UI bug that UI does not display the profile, because UI gets all available profile types from REST (e.g. /rest/profile-types?channelTypeUID=astro:end) and the response is like this:

[
    {
        "uid": "system:default",
        "label": "Default",
        "kind": "STATE",
        "supportedItemTypes": []
    },
    {
        "uid": "system:follow",
        "label": "Follow",
        "kind": "STATE",
        "supportedItemTypes": []
    },
    {
        "uid": "transform:JSONPATH",
        "label": "JSONPATH",
        "kind": "STATE",
        "supportedItemTypes": []
    },
    {
   ...
]

So I would expect to get these profile ids returned for the selected profile and not to have to make any assumptions in the UI.

from openhab-core.

Ok, I am going to fix loading of file, as suggested by @J-N-K , to add system prefix when missing in user file.

from openhab-core.

While I was looking at the code for system profiles, I might have found a bug in class SystemProfileFactory.
The method createProfile handles 24 profiles but the methods getProfileTypes and getSupportedProfileTypeUIDs only consider 21 types, those defined respectively in constants SUPPORTED_PROFILE_TYPES and SUPPORTED_PROFILE_TYPE_UIDS.
The missing profiles in these 2 constants are: BUTTON_TOGGLE_SWITCH, BUTTON_TOGGLE_PLAYER and BUTTON_TOGGLE_ROLLERSHUTTER.
@J-N-K : do you confirm ?

from openhab-core.

They seem to be missing, correct.

from openhab-core.

They seem to be missing, correct.

I tried to add them but in fact I have no precise idea how each ProfileType should be defined.

from openhab-core.

This issue has been mentioned on openHAB Community. There might be relevant details there:

https://community.openhab.org/t/openhab-4-2-updating-an-items-file-does-not-remove-links-to-channels/157331/17

from openhab-core.