Announcement

Collapse
No announcement yet.

Speaker Proxy

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    Speaker Proxy

    I am trying to get my head around how the speaker proxy portion of this plugin is supposed to work but I must be missing something.

    I have the Proxy Flag checked and have chosen the "Forward When No Match" option. I have a simple manually triggered event with a "Speak Something" action.

    When I do not specify a speaker client in the speak event I only get the announcement from DNLA clients. I would expect all clients to speak.

    When I specify a specific non-DNLA speaker client in the speak event I only get the announcement from DNLA clients. I would expect only that specific non-DNLA client to speak.

    When I specify a specific DNLA speaker client in the speak event I only get the announcement from that DNLA Client. That is as I would expect.

    When I specify a specific Non-Existant DNLA speaker client in the speak event I get output from the Non-DNLA clients. That is as I would expect.


    What this seems to indicate is that the plugin considers the "wildcard" everybody speak is a match for the DNLA clients, and therefore does not forward events back to HS for processing. While that is true, I don't believe that is the intent.

    It also seems to indicate is that the plugin considers the lack of a $MC$***$ to mean that it is a "wildcard" event for DNLA clients and treats it as above.

    Could somebody please confirm this behavior, or help me in what I am missing.

    Thanks,

    Matt

    #2
    Originally posted by matthewb View Post
    I am trying to get my head around how the speaker proxy portion of this plugin is supposed to work but I must be missing something.

    I have the Proxy Flag checked and have chosen the "Forward When No Match" option. I have a simple manually triggered event with a "Speak Something" action.

    When I do not specify a speaker client in the speak event I only get the announcement from DNLA clients. I would expect all clients to speak.

    When I specify a specific non-DNLA speaker client in the speak event I only get the announcement from DNLA clients. I would expect only that specific non-DNLA client to speak.

    When I specify a specific DNLA speaker client in the speak event I only get the announcement from that DNLA Client. That is as I would expect.

    When I specify a specific Non-Existant DNLA speaker client in the speak event I get output from the Non-DNLA clients. That is as I would expect.


    What this seems to indicate is that the plugin considers the "wildcard" everybody speak is a match for the DNLA clients, and therefore does not forward events back to HS for processing. While that is true, I don't believe that is the intent.

    It also seems to indicate is that the plugin considers the lack of a $MC$***$ to mean that it is a "wildcard" event for DNLA clients and treats it as above.

    Could somebody please confirm this behavior, or help me in what I am missing.

    Thanks,

    Matt
    A speaker proxy is a way to "intercept" something. So the client you specify is not that important, in fact I usually use the wildcard .... unless you want some post announcement treatment (see later). So the client you refer to is actually of somewhat little importance, what is most important is that you create or intercept the right sources of announcements and modify those such that only what you want to go through a DLNA clients will be intercepted. Does that make sense?

    What is important to know is how HS deals with proxies. Once a proxy registers itself, each time an announcement event is created, HS will informs all proxy clients, but won't do anything itself anymore. So know let's say the Media PI is the ONLY proxy active that means that any event generated in the system will be presented to this PI. So this PI needs to know whether it should do something with this announcement or not. So there are two way, either the prefix you added to the speaker client or you use specific speaker devices (read helpful!). The default behavior always was, if the announcement parameters match the Media PIs parameters for interception, the announcement would be intercepted and dealt with and done. It means that if you wanted the PI AND a speaker client to have the announcement, you had to create TWO actions for the same event. My recommended way, a little bit more work but better controllable in what goes where. The problem arose when you had multiple proxies. HS would call ALL the proxies and lets just say, the Media PI looked at the announcement parameters and determined it wasn't meant for this PI, it would call HS and say, "not for me, send to this speaker client". All good so far right? Well the second proxy, might have the same logic and now you ended up with TWO times the announcement. Hence I introduced the "post announcement" treatment to set to always drop, which you should use when you have multiple Proxies. If you have on proxy and you ALWAYS want the announcement to go to the speaker client, irrespective whether the Media PI intercepted the announcement, you set it to always forward.

    Makes sense?

    Hope this helps

    Dirk

    Comment


      #3
      Dirk,

      Thanks for the explanation. I think I understand what is suppose to be happening now but I cannot get the outcome I expect.

      First things first though, I think there might be a bug in the plugin config page that I hadn't noticed until I started reading through your explanation. No matter what I set the Post Announcement Action to, it always stays at "Forward When No Match". If I change the PostAnnouncementAction Option in the config file and restart the plugin it honors the new setting. This may be part of the reason for my original confusion as I never could get different behavior with the different settings.

      Now to my original issue. I have three different types of events as examples.
      One event I want to speak to all Speaker Clients, HStouch and DLNA devices. An example of this is when the doorbell rings I would announce it to everybody.

      The second event I want to speak to just the DNLA devices. This would be when I am changing the radio stream they are playing I would announce the new stream to just that device as I am only changing the source for that device.

      The third event would be to a Speaker Client/HSTouch. An example of this is if they chose a button that ran an event to speak the weather forecast. I would only send that speech to that device.

      Based on these types events I believe the proper choice of Post Announcement Action would be "Forward When No Match". The issue I am having is that when in the speak action I choose only a non-DNLA device in the speaker client list my DNLA device still speaks. The other scenario is if I choose a specific DNLA device and a specific Speaker Client only the DNLA client speaks. One further note it also seems to make a difference which type of client is added to the list first as to whether the match is declared.


      Again if I am misunderstanding I apologize, but any help is appreciated.

      Matt
      Last edited by matthewb; November 6, 2015, 11:24 PM.

      Comment


        #4
        Originally posted by matthewb View Post
        Dirk,

        Thanks for the explanation. I think I understand what is suppose to be happening now but I cannot get the outcome I expect.

        First things first though, I think there might be a bug in the plugin config page that I hadn't noticed until I started reading through your explanation. No matter what I set the Post Announcement Action to, it always stays at "Forward When No Match". If I change the PostAnnouncementAction Option in the config file and restart the plugin it honors the new setting. This may be part of the reason for my original confusion as I never could get different behavior with the different settings.

        Now to my original issue. I have three different types of events as examples.
        One event I want to speak to all Speaker Clients, HStouch and DLNA devices. An example of this is when the doorbell rings I would announce it to everybody.

        The second event I want to speak to just the DNLA devices. This would be when I am changing the radio stream they are playing I would announce the new stream to just that device as I am only changing the source for that device.

        The third event would be to a Speaker Client/HSTouch. An example of this is if they chose a button that ran an event to speak the weather forecast. I would only send that speech to that device.

        Based on these types events I believe the proper choice of Post Announcement Action would be "Forward When No Match". The issue I am having is that when in the speak action I choose only a non-DNLA device in the speaker client list my DNLA device still speaks. The other scenario is if I choose a specific DNLA device and a specific Speaker Client only the DNLA client speaks. One further note it also seems to make a difference which type of client is added to the list first as to whether the match is declared.


        Again if I am misunderstanding I apologize, but any help is appreciated.

        Matt
        Screen shots of how exactly you have built the events (expanded view) would help.

        Maybe it was still confusing but if you create an event and you specify the speaker client with an added $MC$ prefix it will ALWAYS be picked up by the Media PI. If you don't add the $MC$ prefix it will NEVER be picked up by the Media PI. So if you want to have it go to DLNA clients only, you add $MC$. If you don't want to have it going to DLNA clients but only to HS Speaker clients you don't add $MC$. For the cases where you want to have it go to DLNA clients AND HS Speaker clients, my recommendation is that you add TWO actions, one with $MC$ prefix and one without. You leave the post announcement treatment to forward only when no match. You really only need the post announcement setting when you have multiple proxies.

        I'll have a look at the bug once I find some time, thanks for pointing out.

        Dirk
        postedit: you can create speak actions and specify multiple speaker clients. For those events where you want the DLNA client AND the speaker clients to announce, you can try to specify multiple speaker clients, obviously one with $MC$ prefix other(s) without $MC$ prefix

        Comment


          #5
          Sorry for making this so difficult that really isn't my objective. I think I have figured out the nuances but wanted to post this follow up with the examples. Sorry I couldn't figure out how to get the pictures to post correctly so I just linked to them.

          Here is the event where the issue I am having is that when in the speak action I choose only a non-DNLA device in the speaker client list my DNLA device still speaks.

          https://www.dropbox.com/s/kvz45iln84...ture1.JPG?dl=0

          Nov-06 11:40:43 PM Event Event Testing Group !Speak triggered by the event page 'Run' button.
          Nov-06 11:40:43 PM Event Event Trigger "Testing Group !Speak"
          Nov-06 11:40:43 PM MC SpeakIn called for Device = 0, Text = Test Event, Wait=False, Host = OSCA32640EFAULT
          Nov-06 11:40:43 PM TTS Speak: (OSCA32640EFAULT):Test Event


          Here is an event representing the other scenario where if I choose a specific DNLA device and a specific Speaker Client only the DNLA client speaks. One further note it also seems to make a difference which type of client is added to the list first as to whether the match is declared. In this example both named clients speak.

          https://www.dropbox.com/s/qq190ivt2t....2JPG.JPG?dl=0

          Nov-06 11:17:32 PM Event Event Testing Group !Speak triggered by the event page 'Run' button.
          Nov-06 11:17:32 PM Event Event Trigger "Testing Group !Speak"
          Nov-06 11:17:32 PM MC SpeakIn called for Device = 0, Text = Test Event, Wait=False, Host = OSCA32640EFAULT,$MC$Living Room$:*
          Nov-06 11:17:33 PM TTS Speak: (OSCA32640EFAULT,$MC$Living Room$:*):Test Event

          In this example only the DNLA client speaks.

          https://www.dropbox.com/s/22db78zme3...ture3.JPG?dl=0


          Nov-06 11:20:09 PM Event Event Testing Group !Speak triggered by the event page 'Run' button.
          Nov-06 11:20:09 PM Event Event Trigger "Testing Group !Speak"
          Nov-06 11:20:09 PM MC SpeakIn called for Device = 0, Text = Test Event, Wait=False, Host = $MC$Living Room$:*,OSCA32640EFAULT

          Again thanks for the help and the plugin.

          Matt
          Last edited by matthewb; November 7, 2015, 12:40 AM. Reason: Added Log Entries

          Comment


            #6
            Originally posted by matthewb View Post
            Sorry for making this so difficult that really isn't my objective. I think I have figured out the nuances but wanted to post this follow up with the examples. Sorry I couldn't figure out how to get the pictures to post correctly so I just linked to them.

            Here is the event where the issue I am having is that when in the speak action I choose only a non-DNLA device in the speaker client list my DNLA device still speaks.

            https://www.dropbox.com/s/kvz45iln84...ture1.JPG?dl=0

            Nov-06 11:40:43 PM Event Event Testing Group !Speak triggered by the event page 'Run' button.
            Nov-06 11:40:43 PM Event Event Trigger "Testing Group !Speak"
            Nov-06 11:40:43 PM MC SpeakIn called for Device = 0, Text = Test Event, Wait=False, Host = OSCA32640EFAULT
            Nov-06 11:40:43 PM TTS Speak: (OSCA32640EFAULT):Test Event


            Here is an event representing the other scenario where if I choose a specific DNLA device and a specific Speaker Client only the DNLA client speaks. One further note it also seems to make a difference which type of client is added to the list first as to whether the match is declared. In this example both named clients speak.

            https://www.dropbox.com/s/qq190ivt2t....2JPG.JPG?dl=0

            Nov-06 11:17:32 PM Event Event Testing Group !Speak triggered by the event page 'Run' button.
            Nov-06 11:17:32 PM Event Event Trigger "Testing Group !Speak"
            Nov-06 11:17:32 PM MC SpeakIn called for Device = 0, Text = Test Event, Wait=False, Host = OSCA32640EFAULT,$MC$Living Room$:*
            Nov-06 11:17:33 PM TTS Speak: (OSCA32640EFAULT,$MC$Living Room$:*):Test Event

            In this example only the DNLA client speaks.

            https://www.dropbox.com/s/22db78zme3...ture3.JPG?dl=0


            Nov-06 11:20:09 PM Event Event Testing Group !Speak triggered by the event page 'Run' button.
            Nov-06 11:20:09 PM Event Event Trigger "Testing Group !Speak"
            Nov-06 11:20:09 PM MC SpeakIn called for Device = 0, Text = Test Event, Wait=False, Host = $MC$Living Room$:*,OSCA32640EFAULT

            Again thanks for the help and the plugin.

            Matt
            I suspect two things are wrong:

            1/ I suspect you have specified to intercept Speaker DEVICE ID = 0. When you go to the settings of the DLNA player itself, there is an option where you can specify which speaker device IDs you want to intercept. HS was originally built where you would specify a number rather than a host name. I suspect the reason why your scenario 1 still has it going to a DLNA client is that you need to remove the device ID = 0 from the DLNA device settings. Else I can't think of any reason why in this scenario, the announcement would end up with a DLNA client.

            2/ For scenario 2 and 3, I realize I never tested or used multiple clients in the same action. I always created two actions. As you noted, only the first specified client in the list of speaker clients seems to be used. If you can fix item #1 above, you should be able to work around this issue by specifying two actions with only one speaker client in each, rather than one action with multiple clients. I'll have a look at this perhaps next week to fix this.

            Dirk

            Comment


              #7
              Dirk,

              You were correct on item 1 I did have the 0 in the Device ID settings. Removing it did fix the event, but did so at the expense of broadcast events to all clients working.

              As you said though at this point I know how to create the events to accomplish my goals. If you have time to look at the code that is great, I would be willing to test anything you come up with.

              Thanks again,

              Matt

              Comment

              Working...
              X