As I understand a thing is the representation of a physical object.
More complex objects could be binded by more than one binding.
For example my Nvidia Shield may use
Is it possible to create an individual Thing with channels to different bindings?
Michael
Don’t think you can do that.
Not sure what your usecase is, but you can certainly create multiple things for your Nividia Shield and bundle them together through logic and show them organized on your sitemap. In the end it may not make a big difference, as most interactions and rules work on items anyway and at that point it would not make a difference whether the items are mapped against one thing with multiple channels or multiple things with few channels.
Hope that helps
Sure - it even works without the Thing - I just really don’t understand the concept of things.
It would make sense for me, if all possible channels of a physical object are combined in a Thing - despite of their kind of binding…
Thanks, I too, am getting lost on and off in the varied levels of abstractions; and some of it appears somewhat counterintuitive, in particular the things.
Here is the only way this makes sense to me: to focus on the thought that the ultimate goal is to have all bindings supporting auto-discovery. In my mind, for auto-discovery to work, we will need a new layer between the physical world and the items, hence the thing is borne. This way, things can be auto-discovered and items can be fully user controlled (with the channel statement providing the link between the thing and the item). There are multiple ways to realize this, but in OH2 the developers went down the road of a new layer of abstraction.
However, a thing-object is only as good/comprehensive as the binding that represents it, and ideally, it would represent all channels the physical-object has. In reality, the things maps only a certain facet of the physical object (i.e., only the parameters that are included in the binding).
I guess where it gets tricky are items that are already abstracted underneath OH2. For example, who owns the channels for the network binding, the Nvidia Shield or the router? Intuitively, one would say the Nvidia shield as we want to know whether it is online or not; however, in reality, only your DHCP server knows who is online and who is not (and DHCP server does not even have to be your running on you router).
Ultimately, for me that leads to the fact that some aspects are nicely abstracted and I do not need to care about the technical details (for examples, the autodiscovery of hue lamps or squeezebox players pulls everything in and I do not even have to remember how many devices I have as all will be automatically presented), while others are still requiring more details.
Sorry if the above is too trivial. I am sharing your frustration and am not fully convinced that OH2 has not breached the threshold of over-engineering. It is a very powerful program, but the learning curve remains rather steep in almost all aspects, at least for the non-expert (me).
There are amazingly talented people on this forum that likely feel different and are incredibly kind with their advice, but when I am reading the forum (for the last 3 years or so), there appears to be a mounting amount of confusion.
In all fairness, I am just a user (with some basic computer science skills) and technology aficionado who plays the role of early adopter, so maybe I should not even be dabbling in this.
Hi Michael,
The abstraction layer thing as described in the docs, does refer to physical objects for some bindings, others (such as the Astro binding, refer to virtual devices - think of a solar position sensor that normally you buy for the sunset or dawn trigger, but instead it is created virtually via the binding’s things and their respective channels). In your case you just have multiple devices, that need to be linked through various bindings.
There is the abstraction layer called “items” that allows you to combine channels from different bindings! Take a look here, in the Multi Binding/Channel Linkage section.
For me at least, this is self explanatory, but I can accept that sometimes the virtual side of some bindings can create a little bit of confusion for some.
Best regards,
George
I’m heavy using openHAB since the early 1 days and use nearly 350 items of different bindings.
When the concept of Things was introduces in OH2 I thought I understand it.
But after the number of OH2-Bindings is increasing I struggle with it…
The idea to represent the physical object as Thing is attractive - but then I would prefere to define Things by myself.
I don’t know if it is possible to create an individual thing.
Imagine I build a beer-brewing-machine with a zwaveswitch, an enocean-temperature sensor and a raspi with some channels. This is a physical object! Now I want all switches and data in OH - so I want to represent it as a thing.
The kind of connection/binding of each channel should be secondary.
In terms of existing OH2 bindings, your solution is in fact a collection of at least 3 things with their respective bindings, as you well know.
.[quote=“mashborn, post:6, topic:30549”]
The idea to represent the physical object as Thing is attractive - but then I would prefere to define Things by myself.
[/quote]
I might be wrong, but I understand that what you are desiring is the integration of a DIY solution in a form of abstraction (implementing various communication protocols in to one binding) that someone can build to fulfill a custom solution. You can always develop your own binding and still comply with OH2 concepts, although I think it does not worth it…
Best regards,
George
That is the analogy that is used in the docs but it really isn’t correct, or at least not complete and I would caution you to avoid getting hung up on the “physical device” aspect of it.
A Thing is the representation of a device or service endpoint for a specific technology. As such, it is not possible to combine things from different Technologies.
Combining Things like described is, based on what I’ve learned of the architecture, intended to be done at the Items/Rules level, not the Things level.
At the end of the day, except for some minor convenience in Channel ID names, combining Things doesn’t really buy you much.
It might be helpful to understand a little of the history. Since you have been using OH 1.x for awhile you are very familiar with Items and how Items are bound to bindings in the { } part of the Item definition.
That approach was unscalable and unsuitable to allow automatic discovery of devices and for the ability to define and configure Items through the web-based UI. So a new layer of abstraction was created between the bindings and the Items.
This new layer is made up of Things and Channels and all the infrastructure that allows them to be discovered, created, and managed by OH instead of requiring users to manually edit .items files.
However, this layer of abstraction is ONLY between the bindings and the Items and it is the bindings side of this layer that “owns” the Things definitions. The binding defines what Things are possible, configuration of those Things, and what Channels are available. Because of this, any given Thing can only work with the one Binding that it was created for/by. One cannot mix and match channels between different bindings.
On the Items side of the abstraction layer the interface is now much simpler. you just need the Channel ID to link your Item to.
For all bindings, it is theoretically possible to define Things in a .things file yourself. Some are too complex or lack the proper documentation to make this tenable though, e.g. zwave. But because the binding basically owns the way the Thing is represented and the channels on that Thing, you are still limited to one binding per Thing.
But that is THE main job of a Thing, to interface between the binding and Items. It isn’t secondary, it is almost the Thing’s entire raison d’etre. The integration between multiple bindings is supposed to occur at the Item/Rules level.