Announcement

Collapse
No announcement yet.

Plugin unable to discover devices

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

  • #16
    Originally posted by BlairG View Post

    Now, next step, is there a way to make HomeSeer allow the server to be on a Public instead of Private network address?
    Besides this issue with Sonos plugin is there any harm being on a Public address while on my Private network?
    Is this an educational question or something you want to do? If educational, see below, if intentional, can you explain why, because it is just not a good idea.

    Here's why using a public address for a local (private) network is a no-go.
    When any device wants to communicate with another device over IP, it will query the local stack with the destination IP address. The stack will quickly determine whether the address is within any of the subnets attached to any of your interfaces. This is done by using the subnet mask (ex 255.255.255.0) to AND your IP address and destination IP address. If it is local (and function resulted in 0), a special packet (ARP) will be broadcast on the local network asking which physical machine owns your destination IP address. That destination responds and you are now communicating using the physical addresses (MAC).

    If you didn't have an Internet (WAN), you can use for this ANY IP address range you want, machines don't understand public versus private addresses, this is just an agreement made when Al Gore created the internet.

    However, say you want to pull up a website that is not local, the stack will now know it is not local and will forward the packet to the gateway router (for residential users, typically your DSL or Cable modem). The gateway router, or any router for that matter, they don't know where the end destination is, but they maintain tables per port they have and do a look up of your destination IP address and will determine out of which port the packet need to be forwarded. This continues until somewhere in the network, a router determines the destination address is local and now they do the ARP thing etc and voila your packet ends up at its destination.

    So why should you NOT use a public address for a local private network? Because if that public address, is say a google server, your local stack will NOT forward it to your gateway router and that packet will stay local and you will NEVER have access to that public function.

    Clear as mud?

    Comment


    • #17
      Crazy! Actually it turns out that 169.253.x.x seems to be just a "run of the mill" public IP address range. A search indicates its owned by the US Department of State. Its very close however to a "real" reserved range, 169.254.x.x, which is what initially caught my eye.

      Comment


      • #18
        Like I said a decade or two ago, I didn't know better, now that it's perfectly clear I understand that I've got to systematically change the IP address of about 70 things.

        Thank you for explaining that, including the AL Gore part.
        Blair

        HomeSeer: HS3 Pro 3.0.0.435
        Hometroller S6 | Devices: 601 | Events: 202
        Plug-Ins: Z-Wave .190 | HSTouch | RFXCOM | UltraRachio3
        BLLAN | NetCAM | Global Cache Pro | Blur-Iris :rolleyes:

        Comment


        • #19
          Originally posted by BlairG View Post
          Like I said a decade or two ago, I didn't know better, now that it's perfectly clear I understand that I've got to systematically change the IP address of about 70 things.

          Thank you for explaining that, including the AL Gore part.
          I sense a second way of doing things I wouldn't do. I sense you set manually the IP address for all your devices. Is there no DHCP server on your LAN? I would have expected a statement, "I changed the address range on my router and all fine now ..."

          Comment


          • #20
            If everything was on dhcp, that would be great. But I have static and reservations to change also. It'll be fun.
            Blair

            HomeSeer: HS3 Pro 3.0.0.435
            Hometroller S6 | Devices: 601 | Events: 202
            Plug-Ins: Z-Wave .190 | HSTouch | RFXCOM | UltraRachio3
            BLLAN | NetCAM | Global Cache Pro | Blur-Iris :rolleyes:

            Comment


            • #21
              Originally posted by BlairG View Post
              If everything was on dhcp, that would be great. But I have static and reservations to change also. It'll be fun.
              I see ....
              Why do you use static? Why not use IP to MAC stitching on the router and put everything on DHCP for those devices that you need always the same IP address?

              Comment


              • #22
                Originally posted by dcorsus View Post

                I began some test/coding of letting the PI select which subnet it would "manage" until I realized that the only way this can work is when HS and the players are in the same subnet. I believe the PI can be changed to say monitor subnet "on selection", perhaps even multiple subnets. HOWEVER, when I do announcements, the announcements are "served" by the embedded HS HTTP server function. So when you have text to announce, the PI will use external functions to convert the text to a speech file and then tell the sonos player to play a "file". This in essence is a URL that you pass to the player upon which the player will use HTTP to retrieve/stream that file. If HS is in a different subnet from the Sonos players, that request will need to be "routed" between the two subnets, which means you need a router in your setup to route between your 192.xx.xx.xx and 10.xx.xx.xx subnets. If UltraJones already added functionality to monitor multiple subnets, why don't you bind HS to the 192.xx.xx.xx subnet?
                I have bound HS3 to the wifi IP address of 192.168.1.21 once before and still no go. I just disabled the PI, bound HS3 to the wifi IP, and assured "System is Discoverable Using UPNP" is unchecked.

                Restarted HS3, webserver is wifi address as expected. Enabled Sonos PI and got the following in the log. Strange that multicaster in the log calls my old HS3 Ethernet IP of 10.17.0.3 and probably why I cannot run any of the players now either?

                If I disable the Ethernet adaptor then Sonos finds all the players at their respective Wifi IP's and all plays fine. Unfortunately the Ethernet adapter (10.17.0.x) subnet supports other PI's on my HS3 system so I need to have both.

                I will keep plugging away at it. Let me know if something sticks out?

                Thanks


                Click image for larger version

Name:	sonos log.JPG
Views:	3
Size:	145.2 KB
ID:	1254706Click image for larger version

Name:	sonos player.JPG
Views:	3
Size:	108.1 KB
ID:	1254705


                Attached Files

                Comment


                • #23
                  Originally posted by will40 View Post

                  I have bound HS3 to the wifi IP address of 192.168.1.21 once before and still no go. I just disabled the PI, bound HS3 to the wifi IP, and assured "System is Discoverable Using UPNP" is unchecked.

                  Restarted HS3, webserver is wifi address as expected. Enabled Sonos PI and got the following in the log. Strange that multicaster in the log calls my old HS3 Ethernet IP of 10.17.0.3 and probably why I cannot run any of the players now either?

                  If I disable the Ethernet adaptor then Sonos finds all the players at their respective Wifi IP's and all plays fine. Unfortunately the Ethernet adapter (10.17.0.x) subnet supports other PI's on my HS3 system so I need to have both.

                  I will keep plugging away at it. Let me know if something sticks out?

                  Thanks


                  Click image for larger version

Name:	sonos log.JPG
Views:	3
Size:	145.2 KB
ID:	1254706Click image for larger version

Name:	sonos player.JPG
Views:	3
Size:	108.1 KB
ID:	1254705

                  So any changes you make to the network binding, the only way it will take affect to the Sonos PI is after a restart.
                  The HS setting of UPNP discovery has no effect on the Sonos PI.
                  Not sure that HS does everything dynamic as well, so any change in the binding, I would suggest that you not just restart the Sonos PI but whole of HS. Now it is a mystery to me why HS wouldn't provide the same IP address when requested as the IP address selected for the webserver. If it doesn't, I guess we would have to ask Rich why not.
                  Dirk

                  Comment


                  • #24
                    I tried binding to 127.0.0.1 and sure enough all PI's including Sonos are playing well together. I hope it continues after a restart but I will leave alone for time being.

                    Comment


                    • #25
                      Originally posted by will40 View Post
                      I tried binding to 127.0.0.1 and sure enough all PI's including Sonos are playing well together. I hope it continues after a restart but I will leave alone for time being.
                      Excellent! The PI does "listen" to the loopback address but depending on the setup of the device the PI runs on, you may not always be able to do discoveries via the loopback address and I hope that autonomous alive/byebye UPNP messages are forwarded to the loopback address. The way to test is, is to power down a player, wait until it status changes to off-line (could take up to 30 min). Once it is shows off-line in the player table, power it back up. It should be rediscovered with a minute or 2. If not, this solution isn't going to be very stable. If it does see the alive messages, you are in good shape. Uhh, maybe one last thing, if you look at the log during startup, which IP is the PI now getting from HS? If the loopback address, your TTS isn't going to work!

                      Comment


                      • #26
                        Yeah, I did notice TTS does not work bummer.

                        I’m still not done messing with this. I know I’ve had this setup working not that long ago.

                        Comment


                        • #27
                          Originally posted by will40 View Post
                          Yeah, I did notice TTS does not work bummer.

                          I’m still not done messing with this. I know I’ve had this setup working not that long ago.
                          Seems to recall someone, at some point, struggling with which Ethernet HS would pick if they had multiple Ethernet ports. That person stated he changed the "priority" of the ports, but this was all in the context of VMs. Maybe you should check the settings on the Ethernet ports and see if it has a priority or weight or preference setting. All we need is HS to discover the Sonos subnet as its prefered network, hence it would bind itself to it so you would pull up the HS management page using the IP of that subnet AND it would pass this IP@ to the PI so it would know where to discover the players and the players would be able to communicate with HS when they pull files for TTS.

                          There might be one more alternative .... I think that HS stores your network binding selection in its ini file. Instead of "asking" HS for the IP address (and somehow receive the wrong one), I could query the ini file and retrieve it from there .... Hate to spend more effort so hope you can make it work without me making more one off changes.

                          Comment


                          • #28
                            Originally posted by will40 View Post
                            Yeah, I did notice TTS does not work bummer.

                            I’m still not done messing with this. I know I’ve had this setup working not that long ago.
                            Well I have some good news, sorta....
                            was playing around with the ip bind settings and could easily recreate the scenario where the function hs.getipaddress returned a different IP address from the selected binding.
                            So .... I emailed HS to understand their implementation logic and got a fast response it was a bug and will be fixed in version 479 and later. So that’s the good news. The bad news is that I don’t know when 479 will be released and you would have to upgrade HS because short of me writing code I don’t need, I can’t think of a workaround for now.
                            Dirk

                            Comment


                            • #29
                              Ok Dirk, I understand and I really appreciate your PI support and digging further into this for me. It gives me an excuse to redesign my home network with more reliability to make this work as I do miss the TTS announcements for phone calls, reminders, and door bell throughout the house using my Sonos system.

                              Thanks,

                              Will

                              Comment

                              Working...
                              X