Home » Archived » Eclipse SmartHome » Flow for creating Things and ThingHandlers
| Flow for creating Things and ThingHandlers [message #1426265] |
Thu, 18 September 2014 13:42  |
 Karel Goderis
Messages: 198
Registered: March 2014 |
Senior Member |
|
|
Here are a few questions that popped up when developing a binding:
1. Why is the GenericThingProvider not calling the createThing method of the HandlerFactory to create things? it seems that it has it's own createThing method instead
2. When a Thing is created, and a Thing is also discovered through a DiscoveryService, and then that discovered thing is approved from the Inbox, will the ThingHandler of the firstly created Thing be warned through ThingUpdated()? if not, will the Configuration of the DiscoveryResult be copied over the Configuration already attached to the initially created Thing? if copied, is that behaviour we want, e.g. should configuration elements coming from the discovery process overrule what is defined in .things? In my use case I would like to complement the Configuration of a Thing with properties discovered through Discovery. If the discovery happens after the creation of the Thing, then that can be done through thingDiscovered(), but what if the discovery happens before the Thing is created, and it needs approval from the Inbox.....
3. When interacting through a GUI, what will trigger a handleCommand() and what will trigger a handleUpdate() call? in OH1 we seldomly made a distinction between the two, but in ESH...?
|
|
|
| Re: Flow for creating Things and ThingHandlers [message #1426327 is a reply to message #1426265] |
Thu, 18 September 2014 15:21  |
Dennis Nobel
Messages: 166
Registered: September 2014 |
Senior Member |
|
|
Hi Karel,
let me try to answer your questions:
1. The createThing method of the ThingHandlerFactory is intended to be used for creating new things from discovery. When a thing is discovered, there is no instance of a Thing object. Only the thing type, thing UID and the configuration is known. After the thing was created through your handler factory it will be persisted and this state is compatible to the DSL. Because inside the DSL you are defining complete thing objects, because you are also allowed to define channels etc. Thats why createThing is not called, because you already defined a thing. Is there a concrete use case, where you need to hook in into the process of a thing creation?
2. It depends mainly of the thing identification what will happen. If the thing was defined with the same UID inside the DSL, as the UID of the discovered thing by the DiscoveryService it is same thing. It will not be put into the inbox., but the configuration of the thing will be updated automatically without a need for approval.
For me there is a general problem with the usage of the DSL and the discovery mechanism together. I would assume that if a binding supports a good discovery, there is no need to define things inside a DSL at all. Regarding your second case. If a thing was discovered and already approved and stored inside the storage, there will be a problem if the same thing is defined inside the DSL. Because there can not be two things with the same UID inside the ThingRegistry.
3. It is the same as for OH1. handleCommand is just an event listener for a command that was sent to an item, same for handleUpdate, which is an update Event sent to an item. These two methods are more or less completely similar to the methods of the OH1 binding architecture.
Regards
Dennis
|
|
|
| Re: Flow for creating Things and ThingHandlers [message #1426357 is a reply to message #1426327] |
Thu, 18 September 2014 16:23 |
Karel Goderis
Messages: 198
Registered: March 2014 |
Senior Member |
|
|
Dennis Nobel wrote on Thu, 18 September 2014 11:21Hi Karel,
let me try to answer your questions:
1. The createThing method of the ThingHandlerFactory is intended to be used for creating new things from discovery. When a thing is discovered, there is no instance of a Thing object. Only the thing type, thing UID and the configuration is known. After the thing was created through your handler factory it will be persisted and this state is compatible to the DSL. Because inside the DSL you are defining complete thing objects, because you are also allowed to define channels etc. Thats why createThing is not called, because you already defined a thing. Is there a concrete use case, where you need to hook in into the process of a thing creation?
Mhh... so this implicitly assumes that a Thing in the DSL and during discovery are described in the same way? As it stands right now with the Sonos binding, the Thing parameters in the DSL are a subset of the parameters found during discovery. e.g. the information I can find during discovery is more complete than in the DSL, but maybe not required for unique identification. For example, in the Sonos binding ID are based on the UUID of UPNP, but not a single user can remember those UUID, and thus, "friendly names" are very handy, not only for reporting, but also when creating Rules and Scripts in the runtime. Currently, in the sonos DSL, I let a user define a thing using the Friendly Name of choosing, and then, later on add a UUID when the device is physically discovered on the network. When the device is discovered (and not in the DSL), then the UID of the device is based on the UUID of UPNP, as a friendly name is not known or defined at that point in time.
Hooking into the creation of things would be helpful in the case the thing is defined in the DSL. As soon as it is defined, a "search" could be initiated on the network for the device (and this, independent from the upnp discovery process for example).
Quote:
2. It depends mainly of the thing identification what will happen. If the thing was defined with the same UID inside the DSL, as the UID of the discovered thing by the DiscoveryService it is same thing. It will not be put into the inbox., but the configuration of the thing will be updated automatically without a need for approval.
Ok - that is very logical, however...
updated as in "copied over"? so, if a parameter is defined in the DSL, this will be overwritten by not necessarily the same value coming from discovery? (I presume the Configuration collection is assigned to the Thing configuration member)
Quote:
For me there is a general problem with the usage of the DSL and the discovery mechanism together. I would assume that if a binding supports a good discovery, there is no need to define things inside a DSL at all. Regarding your second case. If a thing was discovered and already approved and stored inside the storage, there will be a problem if the same thing is defined inside the DSL. Because there can not be two things with the same UID inside the ThingRegistry.
Well, this is problematic (let's say inconvenient) for users. Imagine a thing discovered with a very complex UID to remember, like binding:type:"20char HEX String" or whatever (imagine for example an Ethernet MAC Address). So in no DSL, then this UID has to be used in Rules and Scripts? I would rather prefer x:y:"nickname" instead.
I mentioned this to Kai in an email thread: Either you have duplicate things, with different UIDs, or, a - like I did for Sonos - the ThingHandler is also a DiscoveryListener and updates the DSL-thing with interesting stuff from the Discoverd-thing, but then it implies that the user permanently disallows the discovered thing
In the case of Sonos, I have in the DSL "nickname" and the UPNP UDN as an attribute, whereas through discovery, I have the UDN as last segment of the thing UID.
Quote:
3. It is the same as for OH1. handleCommand is just an event listener for a command that was sent to an item, same for handleUpdate, which is an update Event sent to an item. These two methods are more or less completely similar to the methods of the OH1 binding architecture.
For example, a slider/Dimmer that is updated, that will be processed through a Command or an Update event? If I am not mistaken, in the core of OH1 both the Command and Update "flow" was called when an Event was posted on the event bus, explaining why nobody bothered to implement both flows. Question is: is that still the case in ESH?
Regards
K
|
|
|
| Re: Flow for creating Things and ThingHandlers [message #1431920 is a reply to message #1426357] |
Fri, 26 September 2014 10:31 |
Kai Kreuzer
Messages: 673
Registered: December 2011 |
Senior Member |
|
|
Quote:so this implicitly assumes that a Thing in the DSL and during discovery are described in the same way?
Yes, or rather it means that if you use a different UUID in the DSL, you will have your device appear twice. As you would anyhow probably want to ignore the discovered one, you do this one time and you are good to go. This should imho be an acceptable behaviour.
Quote:"friendly names" are very handy, not only for reporting, but also when creating Rules and Scripts in the runtime
For reporting and UIs, we will soon have (localisable) labels through ThingUIProviders - note that labels in contrast to a UUID won't necessarily be unique. Rules and scripts are supposed to make use of Items only, not of things, so there is no need for a friendly thing name. The only part where the user will have to know about the UUID is in the channel="xxx" part inside the item files. This is indeed a bit ugly there. But if you use only DSLs, you are fine as you can define the UUID yourself. And if you use discovery and UIs, you will soon have a possibility to define these "ItemChannelLinks" through a UI, so you do not need to deal with the UUID at all.
Quote:For example, a slider/Dimmer that is updated, that will be processed through a Command or an Update event?
If you talk about a slider in the UI, this is a command, since you "ask" the device to do something. If your binding gets informed that the device has changed its state to OFF, this is an update event as you only report an update that has happened.
Quote:in the core of OH1 both the Command and Update "flow" was called
Only because of the "autoupdate" binding, which sends a status update for an item, when a command is received, so that "unbound" items are still updating their status correctly. Yes, this is the same way in ESH.
Regards,
Kai
|
|
|
Goto Forum:
Current Time: Wed Apr 24 22:34:17 GMT 2024
Powered by FUDForum. Page generated in 0.02607 seconds |
] 
Search
Help
Register
Login
Home
