I’m working on a binding to integrate external modules where each module has its own internal ID provided by the vendor.
The module ID can be read by the binding via vendor proprietary protocol. Unfortunately the module internal ID is a very long string and there is no public domain info on how it is generated.
What is the best practice in this case, when creating a newly discovered thing via discovery service ?
I mean, here:
ThingUID thingUID = new ThingUID(thing type ID, bridge ID, thing ID);
Is it better to use the full external module ID in any case ?
Is there a built-in way in OH to generate a unique thing ID in cases like mine above, starting from the external module ID ?
I did some research, found few threads however none of them was useful in the end…
On my side, I would use the externally generated ID - maybe not convenient due to its length but easier to match when debug is needed, or thing file configuration is used.
I mostly use a small part of the id. Like 4 or 6 characters. Similar what git/GitHub also does. Either from the beginning or end of the string. Sometimes ids have the same pattern at the begin and then using the first part of a string would result in the same id.
It is fairly good question since it can occur anywhere. For most of situations bindings use random identifiers which are assigned by framework. In case if your binding supports discovery you can always use representationProperty to overcome issue with different thing ids having same serial number.
if your identifier are long then think of people who will try to use your binding with textual configuration - do you really want them to type this serial number everywhere or let them assign their own “alias”.
From options you have - you can use thing properties or configuration properties to store serial number. By this way thing id becomes less relevant and only one who cares about it is framework itself.
@glhopital - Thanks. The module ext ID is actually logged upon thing discovery and linked to the internal ID, so it would still be easy to debug. Adding that the module ID is used also by end users when configuring Items via config file, maybe another reason to try to keep it short and ease their life.
@splatch - Thanks. Reading here, it seems representationProperty to be more related to device type than to the thing UID - which is what I’m looking for.
@hilbrand - So did I. Unfortunately cannot easily guess the real changing part of the external id as there’s no documentation on how it is generated.
Could it be an acceptable solution to apply some algorithm, like CRC32 for example, to the module ext ID, in order to generate a shorter internal module ID ?
It should not add too much overhead, as the ID hashing would be executed only once during autodiscovery.
This way, modules that are on the same location and whose ext ID is quite similar would still get an unique ID inside the location - which is my scenario.
I wouldn’t make it more complicated than necessary. Using a small part of the serial id should work. If you don’t see any direct pattern between different ids (sometimes the first part is the same) you can probably take any part of the id. My guess is the last part is the safest (similar what git does).
Sure, I’d usually follow such pattern. However, in this particular case I have experimented that different parts of the ext ID change in different installations
That’s why I’m a bit reluctant to choose a fixed specific part of the ext ID here, and would prefer to find a more reliable solution.
