Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Archived » Eclipse SmartHome » Hierarchy of Bridges?
Hierarchy of Bridges? [message #1403106] Mon, 21 July 2014 12:01 Go to next message
Kai Kreuzer is currently offline Kai KreuzerFriend
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 Go to previous messageGo to next message
Kai Kreuzer is currently offline Kai KreuzerFriend
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 #1403200 is a reply to message #1403108] Tue, 22 July 2014 10:21 Go to previous messageGo to next message
Karel Goderis is currently offline Karel GoderisFriend
Messages: 198
Registered: March 2014
Senior Member
The Sonos player does not need a bridge to function, the physical bridge device is truly a bridge from networking point of view, bridging between ethernet and the propriatery protocol used by Sonos over the Wifi spectrum.
However, for some functionalities in the current binding you need an instance that can control the sonos players, so a Bridge is necessary, albeit it will be a "virtual" one
Re: Hierarchy of Bridges? [message #1403226 is a reply to message #1403200] Tue, 22 July 2014 13:13 Go to previous messageGo to next message
Kai Kreuzer is currently offline Kai KreuzerFriend
Messages: 673
Registered: December 2011
Senior Member
Not sure if I understand that. A "virtual" bridge is needed as it needs to be configured (with an ip address, urn or similar)? Are "Sonos players" the physical devices or also just some logical unit?
Re: Hierarchy of Bridges? [message #1403509 is a reply to message #1403226] Thu, 24 July 2014 09:04 Go to previous messageGo to next message
Karel Goderis is currently offline Karel GoderisFriend
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?
Re: Hierarchy of Bridges? [message #1403950 is a reply to message #1403509] Mon, 28 July 2014 17:08 Go to previous message
Kai Kreuzer is currently offline Kai KreuzerFriend
Messages: 673
Registered: December 2011
Senior Member
I have nothing against encapsulating common logic into MediaThingHandlers or similar - do you already now have a vision on what code should be in there? Otherwise, I would opt for delaying the creation of such abstract classes until the moment when it really is required, because we notice that another binding is supposed to work the same way and thus needs the same logic.

One commonly required feature is actually UPnP - I have just started the discussion for this here: https://bugs.eclipse.org/bugs/show_bug.cgi?id=440577. Possibly you can also share your experiences with the Cling library on this issue - as Cling so far seems to be the best choice (although I only had a first glance, so that might be very biased).
Previous Topic:Multiple channels for an Item?
Next Topic:KNX in openHAB 2 / Smarthome
Goto Forum:
  


Current Time: Thu Mar 28 19:51:29 GMT 2024

Powered by FUDForum. Page generated in 0.02691 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top