Thing UID includes Bridge UID

[jimtng]

• Currently, Things are created with the Bridge UID assigned at creation time, e.g. mqtt:topic:bridgename:id.
• ThingUID cannot be changed after creation
• The bridge, however, can be changed after creation, say I now want to use bridge2. So now that thing UID keeps having the old bridge in its UID.

I have been using text file .things and I've always named my MQTT things without the bridge name, so this naming scheme works.

Should we consider not "burning in" the bridge name into the Thing UID to solve this going forward for newly created Things?

[rkoshak]

There are some use cases where having the bridge ID part of the Thing saves a ton of work. For example, there have been situations where the controller Thing for Zwave needs to be recreated. If you ensure the bridge has the same ID as the old Thing, then all the child Things just work without needing to be recreated and modified in any way. I wouldn't want to lose that as a possibility.

[jimtng]

For example, there have been situations where the controller Thing for Zwave needs to be recreated. If you ensure the bridge has the same ID as the old Thing, then all the child Things just work without needing to be recreated and modified in any way. I wouldn't want to lose that as a possibility.

Could you please elaborate and and give some examples? I'm not familiar with Zwave. I'm trying to picture the actual process and how having the bridge id part of the thinguid can be beneficial.

[cdjackson]

While I'm not 100% sure, I don't think the ZWave binding derives any link to the bridge from the UID.

Personally, I would agree that the thing UID should not be linked to the bridge - this would (theoretically!) allow moving a thing to a different bridge without introducing an inconsistency where the bridge is ABC, but the "bridge part" of the UID is 123.

[rkoshak]

The Thing UID and the Item Name are the keys used in the ItemChannelLink to identify which Item is Linked to which Channel.

When migrating to a new OH instance or when needing to recreate the bridge Thing, if one is careful to use the same ID for the new Bridge Thing, the "child" Things keep their old UIDs (even if they are recreated/rediscovered). Because their UIDs remain the same, the Links remain the same and there is no need to relink all the Channels to the Items. They just work because the IDs remain the same.

I used Zwave as the example but it's not specific to any binding really. I've just dealt with it on the forum the most with that binding. But overall, the main thing is I don't want to force the users to have to relink all their Items because the Things were rediscovered/recreated. How that's maintained I'm less concerned about. Right now, it's maintained by ensuring the UID of the Bridge is the same as the old Things meaning all the discovered child Things get the same UID as the old Things meaning the Links continue to work unchanged.

[cdjackson]

But isn't it true that if you remove the bridge part of this, it still works just the same - or better even since now you don't need to worry about keeping. the same ID for the new bridge - just the same ID for the thing?

[rkoshak]

I'm not arguing that the bridge UID needs to be a part of the child Thing IDs. I'm concerned about some edge cases and I just want to make sure they are not forgotten. For example, what about duplicates of the same Thing under different bridges.

Let's say I have two zwave controllers and node 2 on both just happen to be the same make and model device. Obvioulsy the Thing IDs for these two nodes need to be different. I just want to make sure it's thought out and make sure that how ever cases like that are handled, that the end users have the option to control the UID enough that they can make them the same as what was on an old instance of the Thing so their links still work.

Let's say these two Things are distinguished using a random string. If the end user can't override that random string before the things are accepted from the inbox that will break the links. That's all I'm worried about.

[cdjackson]

Personally I don't mind too much. My only "dislike" is a pet hate of duplicating information. We have a setting in each thing to select the bridge ID, and we also put the bridge ID in the thing UID which seems a poor design choice and as I said above, means that if you change the bridge, then there is confusion as the UID will still be "pointing" to the old bridge.

If the end user can't override that random string

Of course they can do this in the UI - there's the "create thing with custom UID" option in the inbox, but will they, that's a different question :).

I only got involved in this issue due to the comment earlier that seemed to indicate that zwave was doing something strange. I definitely get the point @jimtng is making, and I think it is probably a poor design choice to put the bridge ID into the thing ID due to the duplication of data with one part being changeable, and the other not. However, I'm also not sure it's worth changing...

I think this is really a case of "people have gotten used to the status quo" - probably we'd all be arguing the other way if the bridge ID had never been included and someone wanted to add it :)

[rkoshak]

Of course they can do this in the UI - there's the "create thing with custom UID" option in the inbox, but will they, that's a different question :).

In my experience those who have gone through the pain or relinking all their Items because of a Thing ID change do in fact change it. But even those who are told "make sure the new Thing has the same ID as the old one" tend to do that.

I only got involved in this issue due to the comment earlier that seemed to indicate that zwave was doing something strange.

It was just the first example that came to mind. Zwave isn't doing anything strage, but it tends to be the binding that comes up most frequently on the forum where making sure the Thing IDs are the same when recreating comes up. But it applies to all bindings and all Things, not just Zwave.

I don't care if this changes one way or the other. I just don't want what ever changes to break this. It shouldn't but sometimes changes are done in unexpected ways or have unexpected impacts (e.g. changing DateTimeType to use an Instant instead of ZonedDateTime unexpectedly became a breaking change to Rules DSL users).

[hmerk]

From my experience, it was per design to have the bridgeUID included in the ThingUID, when a bridge was used.
It might have been a relic from openHAB1, but this is how i learned it when I started Binding development. I have used this within the WeMo Binding (WeMo Lightbulbs use a bridge) and have seen this in other Bindings as well.

[jimtng]

@rkoshak brought up a good point about potentially breaking existing installations. One scenario I can think of:

• User had old scheme that includes bridge id. This becomes a part of the link id too, e.g. thinguid binding:type:bridgeid:thingid and channelid is binding:type:bridgeid:thingid:channelid.
• User deletes the Thing in the UI by mistake
• When user recreates the Thing, the new webui doesn't insert the bridgeid, therefore breaking all the links

I think this situation can be avoided by:

• Introducing this change in openHAB 5
• Adding a step in UpgradeTool to rewrite all ThingUID, ChannelUIDs, and LinkUIDs to remove the bridge id. This will cause a problem if after being rewritten, the user then downgrades to openHAB 4, and then the opposite issue described above could happen. But I guess this applies to everything that UpgradeTool touches.

Are there other scenarios where the bridgeid is actually needed in the thinguid / linkuid?

[lolodomo]

We have I believe many bindings reinjecting bridge id in thing UID in their thing handler factory like for example:
https://github.com/openhab/openhab-addons/blob/main/bundles/org.openhab.binding.powermax/src/main/java/org/openhab/binding/powermax/internal/PowermaxHandlerFactory.java#L68
Don't know what are the impacts.

In case changes are done, we should be sure that none of things defined in config files will be broken. So having the bridge id in thing UID should remain a valid option.

[rkoshak]

Not to open a whole can of worms, but if OH had a better way to support changing these IDs across the internal DBs I don't know if this would be an issue. Of course that's a whole other discussion and much much bigger.

Adding a step in UpgradeTool to rewrite all ThingUID, ChannelUIDs, and LinkUIDs to remove the bridge id. This will cause a problem if after being rewritten, the user then downgrades to openHAB 4, and then the opposite issue described above could happen. But I guess this applies to everything that UpgradeTool touches.

I don't think we've ever really supported an in place downgrade like that. And this isn't the first time we've had cases where upgrading wrecked the configs for earlier versions. Restoring a 4 backup to the OH 4 server would be the way to do a downgrade like that.

At the risk of getting off topic, does openHABian, apt/yum perform a backup as the first step of the upgrade process? Docker does but I don't know about the rest. That could be a good way to help users who forge ahead or accidentally upgrade recover.