[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]

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]

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]

@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]

For reference, here are the related issues:

• [danfossairunit] Inconsistency in channel name: main#manual_fan_speed #10621
• [danfossairunit] Provide more elegant deprecation of channel main#manual_fan_speed #11667

[sonnin]

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:

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]

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

[sonnin]

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]

@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]

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]

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

[jlaur]

@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]

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 openhab/openhab-core#1924

[jlaur]

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: [danfossairunit] Remove deprecated channel main#manual_fan_speed when unlinked #11668 (comment)

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]

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]

@lolodomo - I did some initial tests:

• Installed version prior to [danfossairunit] Use system channel types for humidity and outdoor temperature #12277
• Restarted openHAB.
• Created thing using UI.
• Installed version from [danfossairunit] Use system channel types for humidity and outdoor temperature #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]

@lolodomo - see #12277 (comment).