Thing compareTo() [message #1496757] |
Wed, 03 December 2014 08:43 |
Karel Goderis Messages: 198 Registered: March 2014 |
Senior Member |
|
|
With the transition to openHAB2.0 I came across a real-life example of what I already suggested before: duplication of Things between Things defined in the DSL and Things found through Discovery.
In the case of the KNX binding for example, you would typically have a user define a lot of things in a DSL, andn then, from time to time, do a Discovery to find out about new KNX Group Addresses when a KNX actor is for example added to the KNX bus.
Today the KNX binding, when Discovery GA's, creates Things with ID's that end with x_y_z, where x y and z make up the x/y/z GA format. However, when Things are already defined through the DSL, using another nomenclatura than then one that it assumed by the Discovery service, one gets duplicates of the Thing (i.e. different UID but with some properties other than the name being equal) in the Inbox.
One could argue that it is up to the user to manually delete the Things from the Inbox, but with a technology like KNX you easily end up with 100's (in for example my case 1000's) of Things you do not need
Therefore, I think that a mechanism should be provided to check for duplicate Things that goes beyond the simple ThingUID, but that also takes into account attributes of the Things, a kind of a compareTo(). When a thing is discovered, or added through the DSL, a check needs to be done to see if the Thing already exists, and if it does, it's creation is either simply abandoned, or it's attributes are "updated". I might be wrong in this, but the GenericThingProvider and ThingFactory could use the same getUID() methods to solve this issue....
K
|
|
|
|
Re: Thing compareTo() [message #1496808 is a reply to message #1496796] |
Wed, 03 December 2014 09:34 |
Karel Goderis Messages: 198 Registered: March 2014 |
Senior Member |
|
|
Indeed, I would not expect to do a comparison on all attributes of a Thing, but we could identify those attributes to compare in the things.xml definition, no? style <compare>true</compare> flag
Cf. your suggestion, another one would be to persist the inbox or the thing registry to a DSL file using the osgi console. At least that way you do not have to deal with keeping things in sync real-time ,eg. user would do discovery, export the inbox or registry to a DSL file, use a text editor to combine the generated DSL with the "custom" DSL, save the combined DSL to the configuration folders, ...
Making thingProvider and ThingHandlerFactory use the same getUID is not an option? that would already resolved part of the issue, no? For example, have thingProvider create a dummy instance of all registered factories so that it can call upon the getUID() method?
good idea to have general thread.
K
|
|
|
Powered by
FUDForum. Page generated in 0.03663 seconds