Home » Archived » Eclipse SmartHome » Hierarchy of Bridges?
Hierarchy of Bridges? [message #1403106] |
Mon, 21 July 2014 12:01 |
Kai Kreuzer Messages: 673 Registered: December 2011 |
Senior Member |
|
|
Posting a discussion taken from a mail thread with Karel Goderis:
>> Karel: Since Bridges are Things, you can also define channels for them, and use them in Item definitions?
> Me: Yes, this is possible.
Karel: So, in Theory, one can also create hierarchies of Bridges? For Sonos for example, the logical choice would be to take a music player in a room as "the" Thing, but you could also argument against this. For example, related back to UPNP, a device can implement different UPNP templates, and thus behave as different devices. In casu, the Sonos player is a MediaPlayer, a MediaBrowser, etc etc. You could map such a UPNP template to a Thing, then have the Player act as a Bridge, and take the other stuff one level up....
|
|
|
Re: Hierarchy of Bridges? [message #1403108 is a reply to message #1403106] |
Mon, 21 July 2014 12:14 |
Kai Kreuzer Messages: 673 Registered: December 2011 |
Senior Member |
|
|
Let me try to give some guideline on the right level of modelling "Things": Things and Bridges were now introduced for setup and configuration purposes. So they should reflect a (physical) module that you can add to the system at once. So for a device that implements different UPnP templates, this should imho still be a single Thing, but with many different channels.
Bridges should only be introduced, if there is some independent device that needs to be added and configured on its own before it is possible to add any other devices. A ZWave-USB-dongle is e.g. a good example for a Bridge. I do not know the details of Sonos: If you always require a Sonos Bridge to access any speaker, then this should be done as a Bridge. If you can actually use a certain speaker (PLAYBAR) as a bridge as well, this should be a Bridge as well.
Nonetheless, I would try to avoid having hierarchies of multiple Bridges - theoretically, the current APIs support this, but I am rather afraid that we will run into trouble trying to get this handled in a user friendly way in an administration UI. So unless you have a compelling use case where we would need multiple Bridges in a row.
Regards,
Kai
|
|
| | |
Re: Hierarchy of Bridges? [message #1403509 is a reply to message #1403226] |
Thu, 24 July 2014 09:04 |
Karel Goderis Messages: 198 Registered: March 2014 |
Senior Member |
|
|
No no, they are physical devices, and there is no physical bridge necessary to control them. But, in order to implement some functionality - as it exists today in the binding - you need a "virtual" bridge to control the group of physical players. For example, Sonos players can be put in Groups, and within a given UPNP template Sonos has a mechanism to track which player sits in which Group. This grouping functionality is the basis of the multi-room functionality of Sonos, e.g. to play music in the Kitchen, and have the same music in the dining room, Sonos will put Kitchen and Dinging in a Group, and whenever you change the music you want to play (e.g. new playlist, other radio, spotify,...), then automagically, all Grouped zones will play this new music. In each such group Sonos desginates a group controller who is instructing the "slave" members what to do. Now, in the current binding, I keep track of which player is in what group. I also have a central mechanism to save and restore the play state of a single player. That allows to implement things like a Public Address feature: you save the state of the players involved, you put them in group, you make an annoucement, and then you ungroup them, and restore state. In other words, you can play music, and put that on hold to have the doorbell ring
If devices are logically separated from eachother - e.g. per ThingHandler - then we will need a virtual bridge to put all this inter-player functionality....
An advantage I see over OH1.0 is that Bridges are dynamically notified when a new player comes or goes, so, it facilitates some of the tracking to be done.
To open a bit the discussion, would it make sense to define an abstract class MediaThing(Handler) which could be shared by all the Sonos/Squeeze/... type of bindings?
|
|
| |
Goto Forum:
Current Time: Thu Mar 28 19:51:29 GMT 2024
Powered by FUDForum. Page generated in 0.02691 seconds
|