Alexa upnp discovery?

[lewismervin1]

Thanks for the great work.

Is the emulated bridge compatible with Alexa via upnp?

I am using port 80 and have tried discovery but no devices are found.

[lewismervin1]

Ah my apologies I just spotted #31 and #32

[chrivers]

Are these issues preventing you from using Bifrost?

I haven't yet found anything that depends on it, but I don't have Alexa myself, so I can't test..

[lewismervin1]

Thanks @chrivers. Yes, UPnP discovery for home assistants is something that diyHue offers that Bifrost currently does not, which prevents me from fully transitioning to Bifrost. I think it would great to add this to Bifrost and well received by users as #31 and #32 also indicate. I hope you consider adding it :) Thank you again for the great work!

[lewismervin1]

Ah I just saw #109! 👍

[lewismervin1]

Hi @chrivers, thanks for the recent work on #109. I tested it out to see if the lights appear in the Alexa app but no joy. Discovery didn't find any new devices. I'm happy to test anything if you're planning to get uPnP working for Alexa

[chrivers]

Hm, that's annoying, I was really hoping it would help with that as well 😄

Are you on discord? Since I don't have any Alexa devices, I'd need the help of someone who has one, to test new ideas :)

[lewismervin1]

Digging a bit more - I think the issue is the number of entities being exposed quickly gets too high for Alexa.

The emulated_hue HA implementation (https://www.home-assistant.io/integrations/emulated_hue/) mentions exposing more devices than Alexa supports (48 but some users are reporting ~68 now) results in Alexa not discovering any of them

emulated_hue has a expose_by_default and exposed_domains to offer fine grained control over which devices get exposed.

It would be good to add something like this to bifrost, if possible. There is group_prefix, but being able to supply a prefix for devices (device_prefix or device_prefixes) or just additional control over what gets exposed might reduce devices and solve the issue

[chrivers]

Thanks to everybody who helped, both here and on discord.

I'm soon merging #124, which almost completely reworks both mdns and ssdp/upnp.

Several workarounds are now included, for certain clients that send broken requests.

I think there's a big chance PR #124 will help with the issues you have faced - I hope you guys will give it a try :)

[lewismervin1]

Thanks for the continued efforts @chrivers - I tried the latest master but still no joy.

Would it be useful to be able to rule out if the max number of devices is causing no devices not being discovered? A simple way limit the number of devices discovered/exposed by bifrost would act as a simple test to rule this out.

[chrivers]

That would be useful, yes.

I've also discovered a minor difference between Bifrost upnp announcements and Hue bridge.

It seems a standardized prefix is used in the generated UUID. If any clients are relying on this specific generation scheme, they would fail to notice Bifrost.

I've made a branch to fix this.

Also, since this is definitely a bug of some sort, I've created issue #127 to track this. Let's continue the discussion there 👍

[chrivers]

@lewismervin1 I believe the newest version of Bifrost fixes this issue.

If you want to test with fewer devices, one way could be to remove your state.yaml (which remembers the discovered devices), and temporarily set your config.yaml like so:

# ...usual config here

# empty dict of servers, meaning Bifrost will start, but no devices will be discovered
z2m: {}

You should still be able to discover the bridge, and surely 0 devices can't be "too many" :)