Even if that info was cached it would already be an improvement.
#How to reload homeseer speaker client manual
Advantage is that migration from HS3 to HS4 doesn't break existing events and is quite efficient but had plenty of issues in the past I think with threading or blocking of HS.Ĭ/ Allow the PI authors to add entries to the dropdown list in the speakevent settings screen, instead of the users each time having to add a manual entry. The drawback is that each will have an active TCP connection, so something not very efficient for what I need.ī/ Stay with the HS3 implementation, meaning no implementation of IFromSpeaker done by PI authors, make available that one callback function SpeakIn. So there are a few alternatives here for me:Ī/ create a specific IFromSpeaker speaker client instance for each configuration I have. It tells the Sonos PI what to do, ie which players should participate in the announcement. 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.
#How to reload homeseer speaker client 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. 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)
