Migration of Things between old and new bridge API versions

I am adding support for the new Hue CLIP 2 API v2 to the existing binding, and I need some ideas from developers about migrating existing user’s Things to the new API.

In the old API v1 there are fourteen different types of Thing (seven varieties of light, plus seven varieties of sensor). Whereas in the new CLIP 2 API v2 there is a single Thing type (a ‘device’) which dynamically has different Channels according to its particular capabilities.

I am wondering if there is some way that, if the user has existing Thing’s defined, then (for example) the binding discovery process can parse the list of existing API v1 things, and create respective matching, but new, API v2 things in the Inbox, taking over as many as possible of the attributes of the old existing Things. At minimum it would be great to take over the existing Thing labels, locations, and maybe some properties. (note: insofar as a match exists).

Also, I am wondering if there is some similar way of migrating existing Items from being connected to the old API Thing Channels to the respective matching new Thing Channels. (note: insofar as a match exists).

1 Like

I figured out a way to do it, using the ThingRegistry. If anyone is interested in the details, please let me know.

I am :slight_smile: similar approach for modbus 4.0 version would be most useful

Following are two code links…

  • Discovery code that searches for existing legacy things, and if found, adds information from the legacy thing to the newly discovered thing, in form of a property.
  • Thing handler code that when the newly discovered thing is instantiated, reads the property from the legacy thing, and applies it to the new thing itself.
1 Like

@ssalonen in a second iteration, I added code to search the ItemChannelLinkRegistry to find items that are linked to the legacy thing’s channels, and replicate those links between the respective items and the new thing’s equivalent channels.