The second part however, is crucial user information.
The $SONOS$ part is just to help the HS3 Proxy to pick out those proxy calls that are meant for the Sonos PI and ignore all else. If you go back to my example $SONOS$All Rooms$, you can see 2 parts. Second thing which is a bit more problematic is that I haven't found a way to pass information. I guess one way is to define a class in the SDK that hides all non-essential methods. What I don't like so much about it is that IFromSpeaker has a ton of mandated inherited methods (~30) so is isn't quite user friendly. I applied this in HS4 and I have this running. This is implementing the IFromSpeaker class.
#HOMESEER SPEAKER CLIENT LINUX CODE#
Rich pitched in and suggested I used the stripped down code they use in HSTouch, and apparently Spud, who I'm sure is reading this, is doing the same. So the question for HS4 implementation was whether the PI itself could populate these fake speakerclient entries in the selection menu when users create speak events.
#HOMESEER SPEAKER CLIENT LINUX MANUAL#
Some users complained they had to remember and understand the $SONOS$All Room$ syntax and complained that for each Speak event they created, they had to do all the manual steps to create a fake speaker client again and again. So the PI would use that info to take action or not. When this action was invoked the SpeakIn method listed above was called (back) and the host parameter would be equal to $SONOS$All Rooms$. Now the "cheat" I would do, is to ask my PI users, when they created an event to "add a speakerclient" MANUALLY and give it a very specific name, example: $SONOS$All Rooms$. I'm not sure this is what you are asking, but I used the plain vanilla HS3 suggested implementation. Public Sub SpeakIn(ByVal device As Integer, ByVal text As String, ByVal wait As Boolean, ByVal host As String) Implements Then you add this method to your PI and each time ANY PI or HS invokes the Speak method, your PI gets a call back through this method RegisterProxySpeakPlug (PIName, PIInstance) The clientCallback of type iAppCallbaklAPI had a method clientCallback.ServiceProxy that would return a handle of type iAppCallback. Maybe I should study the speaker Client class, if I can instantiate only one and have a way to pass the information I need (the linkgroup name), that would work.Ĭlient = ScsServiceClientBuilder.CreateClient(Of IHSApplication)(New ScsTcpEndPoint(sIp, 10400), gAppAPI)ĬlientCallback = ScsServiceClientBuilder.CreateClient(Of IAppCallbackAPI)(New ScsTcpEndPoint(sIp, 10400), gAppAPI) So I can have many of these and If I now need to instantiate a call, which I suspect may open another UDP/TCP connection per entry to fake these "speaker clients", that makes me nervous.
So in HS2 and HS3, the way I passed that information from the user created event into my PI was to use a 'fake speakerclient name" which was constructed with a prefix $SONOS$ and a "grouping name" say $Entire House$, so it would make up $SONOS$Entire House$. For example, in my PI, a user can create many different groupings or settings of Sonos players for announcements. I'm still worried, despite Rich telling me not to, to open more interfaces. He suggest to use the HSTouch SpeakerClient class as opposed to having the capability to add static entries to the list of select-able speaker client lists. Rich very recently suggested the same when I asked for a capability to add speakerclients to the list of select-able speaker clients.
0 kommentar(er)
