| Identical Things provided by different ThingProviders [message #1775582] |
Wed, 01 November 2017 18:13  |
 Karel Goderis
Messages: 198
Registered: March 2014 |
Senior Member |
|
|
The current implementation of the ThingRegistry stores Things provided by ThingProvider on a per ThingProvider basis, which means that two ThingProviders can provide the same Thing (that is, same thing UID), and they get both stored in the the ThingRegistry
ThingManager when calling getProvider() or get() on the ThingRegistry will receive the ThingProvider of the first Provider that provides the given Thing, leaving out the other ThingProvider(s) that happen to provide that Thing
I have a situation whereby I am implementing a ThingProvider that is part of a Binding, and I want that ThingProvider to check if a Thing already exists in the ThingRegistry before deciding to provide that Thing. The reason is that want to be able to define a Thing via the DSL (and thus that is provided by the GenericThingProvider), and only extend that Thing with new Channels if it would happen to be already provided by another Provider, so that in essence, a user can define the Thing and Channels, and then have it automatically completed by the Binding. If the thing would not be present in the ThingRegistry, the binding's ThingProvider would provide it, with all the Channels and so forth.
More concrete, I would like to define Things for the KNX binding in the DSL, define Channels on those Things, but later on automatically parse KNX ETS xml files, add additional Things based on those xml files, but only define additional Channels on those Things that would be provided/defined by through the DSL beforehand.
No where in the Core checks are done on whether Things are already provided by other Providers, I think.
So, how to deal with this situation?
Should the ThingProvider bind to the ThingRegistry services, and go from there? or should it implement ThingRegistryChangeListener and keep track of Things itself?
|
|
|
|
| Re: Identical Things provided by different ThingProviders [message #1775951 is a reply to message #1775936] |
Wed, 08 November 2017 14:17  |
Karel Goderis
Messages: 198
Registered: March 2014 |
Senior Member |
|
|
Quote:I think your issue starts right here. A binding must neither implement its own ThingProviders nor access the ThingRegistry.
The mechanism that a binding must use is that of a discovery service - this allows it to "suggest" Things and if a Thing with the same UID already exists (because it is e.g. defined in a DSL), the discovery result is automatically ignored.
[I edited my response after revisiting some old Discovery service code]
Kai, as far as I can see, DiscoveryResultBuilder and/or DiscoveryResult do not have support for Channels. One can only build the base Thing with properties, but how does one create discovery results with a custom set of Channels ?
K
[Updated on: Thu, 09 November 2017 21:12] Report message to a moderator |
|
|
Powered by
FUDForum. Page generated in 0.01725 seconds
] 
Search
Help
Register
Login
Home
