Paul Webster wrote: > I suggest that, initially at least, you allow users to provide host name > (preferred) or IP address of their Alexa devices. > > A skill does not know the local IP address of an Echo (ideas below for > how it could be done) and I do not think that Alexa devices respond to > discovery requests (at least not after they have been set-up). > > However, some ideas: > If you ask an Alexa device to perform a "Discover" then it issues SSDP > broadcast to try to find other systems (Philips Hue I think). > So if your bridge/whatever listened out for it then it could capture the > IP address in the list of possible devices. > However, I think it uses port 80 ... so would that be a problem e.g. on > pCP where there is the pCP web server listening on that port? > I thought that only the primary Echo issued the SSDP but I see from > statements elsewhere that each Echo does this - presumably in an attempt > to ensure it reaches all parts of the home network. > > Another way that could work ... the Echo device could ask MediaServer > skill to do something that results in a Play request being sent (via a > .pls) that points to a specific IP:port where the special code is > listening (e.g. LMSIPAddress:8888 .... and when the special code gets > the request it captures the IP address as a potential Echo device (it > could even respond with a short voice clip via a stream saying "Your > Alexa device at IP address n.n.n.n has been registered". > So the end user would walk to each Echo and say something like "Ask > mediaserver to register with LMS) > > Some other things to keep in back of mind... > MAC addresses - might be able to use the prefix to find Amazon Echo > devices (not checked to see if range is different to other Amazon > devices such as Fire) but there are 3rd-party devices with Alexa built > in that presumably use MAC address range of the 3rd-party device and not > an Amazon (lab126) one.
There's no value in knowing either the IP address or MAC address of an Echo, as there is no way to send audio to them on that basis. Knowing their 'names' is something that the skill already indirectly does via the *Assume* command which sets a default Squeezebox for each Echo to target when a player name is omitted from a spoken command. All this actually does under the hood is set up a dict with Echo deviceId to Squeezebox friendlyName mappings. During player discovery by the skill (which is not Amazon's Smart Home discovery but just my own code querying LMS directly via jsonrpc.js), the MAC addresses of the Squeezeboxes are retrieved so that we then have an Echo deviceId to Squeezebox playerId mapping. I could send that Echo deviceId info to the LMS bridge upon player discovery by the skill, but as I said I do not see much value in having a pre-configured array of virtual Echos within LMS and I'm fine with them being created and destroyed as-needed. If there were a pre-defined bunch of virtual Echos, they would all need their own unique stream URLs and just one /stream.m3 would not suffice. ------------------------------------------------------------------------ philchillbill's Profile: http://forums.slimdevices.com/member.php?userid=68920 View this thread: http://forums.slimdevices.com/showthread.php?t=111016 _______________________________________________ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
