[danfossairunit] After upgrading from 3.1.1 to 3.2.0 my Danfoss Air A2 does not provide the renamed manual_fan_step channel

sonnin commented 2 years ago

I just upgraded from 3.1.1 to 3.2.0 and renamed my manual_fan_speed channel link to manual_fan_step. But when I look at the danfossair thing I do not see the manua

Expected Behavior

The danfossairunit thing to have a manual_fan_step channel as described in the documentation

Current Behavior

I see not "main#manual_fan_step" channel

Possible Solution

?

Steps to Reproduce (for Bugs)

Context

Your Environment

Docker with OH 3.2.0 image running on ubunto Linux openhab3 5.4.0-89-generic #100-Ubuntu SMP Fri Sep 24 14:50:10 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

lolodomo commented 2 years ago

Very interesting. @jlaur : that's for you ;) It looks to me like what I mentioned it could happen. I am interested by the conclusion of this issue... for the future.

jlaur commented 2 years ago

@sonnin - thanks for reporting this issue. A few questions for trouble-shooting:

Is your thing configured in UI or text file?
How did you rename the channel:
If UI, I would assume by removing linked item(s) and creating new ones?
If text, did you simply rename the channel and saved? In this case I suspect openHAB have an issue, and I think you would first need to comment the item and save, then uncomment with new channel name, so it would be two steps.
Can you provide a screenshot showing what you mean by not seeing the new channel?

jlaur commented 2 years ago

For reference, here are the related issues:

10621
11667

sonnin commented 2 years ago

The thing was autodiscovered in earlier version. UID: danfossairunit:airunit:-1407909348 label: Danfoss HRV thingTypeUID: danfossairunit:airunit configuration: host: danfossair.xxx.yy refreshInterval: 10 updateUnchangedValuesEveryMillis: 60000

Items linking to the channels is written in files.

After upgrading I updated my item(s) to match the new channel and data types (like temperature).

When I say that I cannot see the channel. I mean that it does not show up in the UI: Screenshot_20220216_130919 Checkings the logs I do however not see any statements that the item is linked to an unknown channel.

I will try to change play with the items and perhaps remove the thing and re-add it. And revert back.

jlaur commented 2 years ago

@sonnin - before doing anything else, can I ask you as first thing to try to simply restart openHAB?

sonnin commented 2 years ago

Restarting openhab was my attempt to resolve this issue, it did not change anything. I have now removed the thing and re-added in via UI and now I see the manual_fan_step channel. And am able to control the fan speed of the unit. It is strange, I do recall the channel to be there right after the starting openhab after the changing to the new docker image. How or why it has gone missing is unclear to me.

If the channel disappears again I will let you know.

jlaur commented 2 years ago

@sonnin - thank you, and sorry for the trouble. It should not happen again. But it seems like an auto-discovered thing is behaving differently than a thing created manually, even from UI. So I have something to further investigate now, as I believe my previous investigation was based on a manually added thing (through UI and file), binding upgrade and openHAB restart. I'll close the issue as unfortunately the change cannot be reverted as this would cause a similar issue when upgrading to 3.3.

lolodomo commented 2 years ago

So the solution was exactly the same as for the hue binding, the thing has to be removed and added again. That is something to mention in the release notes.

@jlaur : once it is clear for you when it is required or not required, please consider updating the release notes for all PRs this was not done because you said it was useless. And these PRs should be marked as not backward compatible.

lolodomo commented 2 years ago

I reopen the issue. It could then be closed when the release notes mention this requirement.

jlaur commented 2 years ago

@lolodomo - sure. For 3.3 this is expected to introduce the same issue, so this is what I'll make sure to mention: #12277. First I'll verify if this is a behavior specific to auto-discovered things so I can be more specific in the release notes about when user attention is needed.

wborn commented 2 years ago

It's a known issue that things need to be recreated when thing type definitions change. You'll also run into this when new channels are added to thing types. See https://github.com/openhab/openhab-core/issues/1924

jlaur commented 2 years ago

It's a known issue that things need to be recreated when thing type definitions change.

What exactly is considered a thing type definition change? In this case channel type id was changed, i.e. channel type was replaced by a 100% compatible channel type. I verified this scenario:

Thing was created in text file.
Linked item was created from UI with old version of binding.
Binding updated to new version.
openHAB restarted.
After the restart everything was okay.
For reference: https://github.com/openhab/openhab-addons/pull/11668#discussion_r764135912

I guess my mistake was testing the item migration, not the UI thing migration. So in this case things created from text files don't appear to be affected? I'll try again testing the scenario where thing was created with a version before changing channel type id.

You'll also run into this when new channels are added to thing types.

I have never experienced any problems when new channels are simply added? In this case we would have quite a lot of breaking changes from major version to major version?

wborn commented 2 years ago

So in this case things created from text files don't appear to be affected?

Yes things stored in .things files are always fully recreated using current thing type definitions. But the so called "managed" things (created using the UI) are restored based on the data in the JSON Storage. So the managed things can be out of date and are currently not updated.

What exactly is considered a thing type definition change?

Everything derived from thing/channel types, config descriptions etc. that is stored in userdata/jsondb/org.openhab.core.thing.Thing.json

In this case we would have quite a lot of breaking changes from major version to major version?

It is indeed a common an annoying issue for many users of managed things.

jlaur commented 2 years ago

@lolodomo - I did some initial tests:

Installed version prior to #12277
Restarted openHAB.
Created thing using UI.
Installed version from #12277
The humidity channel disappeared, but the outdoor temperature channel still existed and worked.
Restarted openHAB.
No change.

In both scenarios the channel type id was changed, but for humidity the previously used locally defined channel type was also removed.

I then repeated the test, but this time preserving the locally defined humidity channel type, although it was no longer referenced. This time it worked.

Last, I tried adding a new channel referencing an already existing locally defined channel type. This channel didn't appear - so you are also right about that, @wborn.

I guess we still need to mention breaking changes like this in release notes, but I'm wondering about which specific types of problems should be mentioned. A new channel not appearing is not a breaking change, but it's still quite annoying, and users having read about new features might waste some time not finding them and asking for support. So maybe this is worth mentioning too? But that would probably mean that a lot of things would need to be mentioned then. WDYT? @kaikreuzer - you might have an opinion here also.

jlaur commented 2 years ago

@lolodomo - see https://github.com/openhab/openhab-addons/pull/12277#issuecomment-1042308916.

openhab / openhab-addons