This is to be considered a discussion issue and a follow-up to #3330 (comment). I thought it would be more clean to have a distinct issue for tracking this.

Recently there were some discussions in this forum thread that triggered me to come back to this topic:
https://community.openhab.org/t/come-back-and-learn-how-to-use-file-based-configuration/147067

The issue (as I see it) is the difference between managed things:

{
  "danfossairunit:airunit:-1062731542": {
    "class": "org.openhab.core.thing.internal.ThingStorageEntity",
    "value": {
      "isBridge": false,
      "channels": [
        {
          "uid": "danfossairunit:airunit:-1062731542:main#current_time",
          "id": "main#current_time",
          "channelTypeUID": "danfossairunit:currentTime",
          "itemType": "DateTime",
          "kind": "STATE",
          "label": "Aktuel tid",
          "description": "Aktuel tid rapporteret af air unit\u0027en",
          "defaultTags": [],
          "properties": {},
          "configuration": {}
        }
      ],
      "label": "Danfoss Air Unit",
      "configuration": {
        "host": "ccm.local",
        "refreshInterval": 10,
        "updateUnchangedValuesEveryMillis": 60000
      },
      "properties": {
        "modelId": "w2/a2",
        "serialNumber": "xxx",
        "thingTypeVersion": "2",
        "vendor": "Danfoss"
      },
      "UID": "danfossairunit:airunit:-1062731542",
      "thingTypeUID": "danfossairunit:airunit"
    }
  },

[...]

and file-based things:

Thing danfossairunit:airunit:a2 "Danfoss HRV" [host="ccm.local", refreshInterval=10,
updateUnchangedValuesEveryMillis=60000]

For managed things there is some information stored which is not stored for file-based things:

• Label
• Description
• Properties
• Channels (including label, description, channel type UID, auto update policy and properties)

All this is redundant. In my experience redundancy usually will haunt you because of bugs in synchronization, i.e. failure to
properly maintain the redundant data.

This seems to be the case here also.

In 4.0 channel migration is partially solved by #3330 thanks to a massive effort by @J-N-K. With "partially" I mean no disrespect, but we still have at least these issues:

• Thing upgrade gives different result than recreating thing #3569
• Thing migration: channels order is lost #3584
• thing upgrades: missing support to add/change/remove channel properties #3610
• Auto update policy on channel level cannot be updated
• Removal of channel type at the same time of removing last usage (with instructions provided) causes a two minute delay and a warning: "[core.thing.internal.ThingManagerImpl] - Channel types or config descriptions for thing 'xxx' are missing in the respective registry for more than 120s. In case it does not happen immediately after an upgrade, it should be fixed in the binding."

And this would have been avoided:

• Framework sends DecimalType instead of QuantityType to Thing handler #3669
• [mqtt.espmilighthub] Fix upgrade instructions openhab-addons#16127

Example - migrated Thing:

Recreated Thing with correct channel order and new channels in configured language:

Additionally, even with this migration mechanism in place, contributors are required to provide upgrade instructions for maintaining managed things (they are not needed for file-based things). These instructions are redundant themselves, since actually all information is already available. Otherwise file-based things wouldn't work. They are also error-prone and need proper testing for each binding removing/updating or adding channels.

It seems also that there is a lot of complexity for being able to synchronize/maintain things.

Therefore, I'm wondering if managed things could be simplified by aligning with file-based things in the sense that the redundant information is removed from jsondb and instead created runtime - similar to how this works for file-based things. I'm suggesting/asking this only from a logical standpoint - I'm not familiar with the code.

When re-reading #3330 (comment), if I understand it correctly, this comment assumes that we have to deal with this redundancy. I understand this can be difficult, and just to be clear: I do not suggest to complicate it even further, but actually to completely remove everything from jsondb which is redundant.

The benefits would be:

• Simplification - leading to fewer bugs.
• Easier and less error-phone for contributors to add/update/remove channels.
• Existing bugs/short-comings would be automatically resolved, for example the three mentioned above.
• One benefit of using file-based things would be eliminated - the argument that managed things from time to time might need to be recreated to be fully correct would disappear.
• Changing language would have effect on labels and descriptions (at least after a restart).

I don't know if this is feasible at all and/or complete nonsense, and maybe it has already been discussed in the past?

Cc @J-N-K, @lolodomo, @kaikreuzer - tagging you directly as you probably have some direct feedback on these thoughts.