Discovery issues from Echo Dot 2nd Gen - potential fix #860
Comments
|
That is great news! I will put that in the next release. Will also allow adjusting for timeout. That may be the reason when I do a discover on a gen 1, it asks multiple times. |
|
I spent a bit of time reading the upnp specs - seems that the MX value in the search should be used to get the devices that are replying to stagger their responses - but it also says its max value is 5 and if it gets a higher value it should assume 5 - I note the echo dot sets it mx to 15 (I think) - I was going to put some random between .05 and 5 seconds in - but the quick and dirty of 1.5 (1500 ms) seemed to nail it. don't know if we need it on all three template types but i see the dot only asks for the last type in it's search - maybe it ignores the other replies whenever they come. either way - hope it helps - and let me know if you want a test of that particular piece ahead of release - happy to throw it into my setup. |
|
They way I was going to implement it was the delay between each template send starting with delaying the first template. |
|
So, looking at the spec for MX, it is to randomize between 0 and seconds where MX is between 1 and 5. So as many times as this is used, I'll jsut make sure the value set does not exceed 5 seconds for the 3 responses. |
|
I wonder how sensitive the dot is to the timing. I will double check but I thought the dot set the mx to 15. I know the specs say 5 ( or assume 5 is mx > 5) is the max but I wonder if dot does that (15) because it needs longer and maybe the HUE chooses to use random up to 15 rather than random > 5.
… On 29 Dec 2017, at 17:15, BWS Systems ***@***.***> wrote:
So, looking at the spec for MX, it is to randomize between 0 and seconds where MX is between 1 and 5. So as many times as this is used, I'll jsut make sure the value set does not exceed 5 seconds for the 3 responses.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
My implementation has a max of 15000. So that should cover it, |
|
will the fix be a new .jar file? If so, I cannot find a new .jar file for 5.2.0, the latest I can find is 5.1.0. |
|
Please go test RC version in #863 |
|
Hello, I'm also experiencing this issue. Tried several versions (4.5.9, 5.0.0, 5.1.0) and was hoping that 5.2.0RC1 would fix this but sadly not: Log: 2018-01-04 17:09:40,461 [main] INFO com.bwssystems.HABridge.HABridge - HA Bridge (v5.2.0RC1) starting.... HOST: 239.255.255.250:1900 CACHE-CONTROL: max-age=100 LOCATION: http:https://192.168.1.108:80/description.xml SERVER: Linux/3.14.0 UPnP/1.0 IpBridge/1.19.0 NTS: ssdp:alive hue-bridgeid: B827EBFFFE8644CD NT: uuid:2f402f80-da50-11e1-9b23-b827eb8644cd USN: uuid:2f402f80-da50-11e1-9b23-b827eb8644cd 2018-01-04 17:11:00,205 [main] INFO com.bwssystems.HABridge.upnp.UpnpListener - Traceupnp: SSDP M-SEARCH packet from 192.168.1.121:50000 HOST: 239.255.255.250:1900 CACHE-CONTROL: max-age=100 EXT: LOCATION: http:https://192.168.1.108:80/description.xml SERVER: Linux/3.14.0 UPnP/1.0 IpBridge/1.19.0 hue-bridgeid: B827EBFFFE8644CD ST: upnp:rootdevice USN: uuid:2f402f80-da50-11e1-9b23-b827eb8644cd::upnp:rootdevice 2018-01-04 17:11:03,240 [main] INFO com.bwssystems.HABridge.upnp.UpnpListener - Traceupnp: send upnp discovery template 2 with response address: 192.168.1.108:80 to address: /192.168.1.121:50000 HOST: 239.255.255.250:1900 CACHE-CONTROL: max-age=100 EXT: LOCATION: http:https://192.168.1.108:80/description.xml SERVER: Linux/3.14.0 UPnP/1.0 IpBridge/1.19.0 hue-bridgeid: B827EBFFFE8644CD ST: uuid:2f402f80-da50-11e1-9b23-b827eb8644cd USN: uuid:2f402f80-da50-11e1-9b23-b827eb8644cd 2018-01-04 17:11:04,759 [main] INFO com.bwssystems.HABridge.upnp.UpnpListener - Traceupnp: send upnp discovery template 3 with response address: 192.168.1.108:80 to address: /192.168.1.121:50000 HOST: 239.255.255.250:1900 CACHE-CONTROL: max-age=100 EXT: LOCATION: http:https://192.168.1.108:80/description.xml SERVER: Linux/3.14.0 UPnP/1.0 IpBridge/1.19.0 hue-bridgeid: B827EBFFFE8644CD ST: urn:schemas-upnp-org:device:basic:1 USN: uuid:2f402f80-da50-11e1-9b23-b827eb8644cd 2018-01-04 17:11:04,768 [main] INFO com.bwssystems.HABridge.upnp.UpnpListener - Traceupnp: SSDP M-SEARCH packet from 192.168.1.121:50000 HOST: 239.255.255.250:1900 CACHE-CONTROL: max-age=100 EXT: LOCATION: http:https://192.168.1.108:80/description.xml SERVER: Linux/3.14.0 UPnP/1.0 IpBridge/1.19.0 hue-bridgeid: B827EBFFFE8644CD ST: upnp:rootdevice USN: uuid:2f402f80-da50-11e1-9b23-b827eb8644cd::upnp:rootdevice 2018-01-04 17:11:07,802 [main] INFO com.bwssystems.HABridge.upnp.UpnpListener - Traceupnp: send upnp discovery template 2 with response address: 192.168.1.108:80 to address: /192.168.1.121:50000 HOST: 239.255.255.250:1900 CACHE-CONTROL: max-age=100 EXT: LOCATION: http:https://192.168.1.108:80/description.xml SERVER: Linux/3.14.0 UPnP/1.0 IpBridge/1.19.0 hue-bridgeid: B827EBFFFE8644CD ST: uuid:2f402f80-da50-11e1-9b23-b827eb8644cd USN: uuid:2f402f80-da50-11e1-9b23-b827eb8644cd 2018-01-04 17:11:09,320 [main] INFO com.bwssystems.HABridge.upnp.UpnpListener - Traceupnp: send upnp discovery template 3 with response address: 192.168.1.108:80 to address: /192.168.1.121:50000 HOST: 239.255.255.250:1900 CACHE-CONTROL: max-age=100 EXT: LOCATION: http:https://192.168.1.108:80/description.xml SERVER: Linux/3.14.0 UPnP/1.0 IpBridge/1.19.0 hue-bridgeid: B827EBFFFE8644CD ST: urn:schemas-upnp-org:device:basic:1 USN: uuid:2f402f80-da50-11e1-9b23-b827eb8644cd 2018-01-04 17:11:09,331 [main] INFO com.bwssystems.HABridge.upnp.UpnpListener - Traceupnp: SSDP M-SEARCH packet from 192.168.1.122:50000 HOST: 239.255.255.250:1900 CACHE-CONTROL: max-age=100 EXT: LOCATION: http:https://192.168.1.108:80/description.xml SERVER: Linux/3.14.0 UPnP/1.0 IpBridge/1.19.0 hue-bridgeid: B827EBFFFE8644CD ST: upnp:rootdevice USN: uuid:2f402f80-da50-11e1-9b23-b827eb8644cd::upnp:rootdevice 2018-01-04 17:11:10,852 [qtp25643290-13] INFO com.bwssystems.HABridge.hue.HueMulator - Traceupnp: hue lights list requested by user: 8giiV6M6J5EYTVzC1DoAG4k74dpswkSpMfWwAdxS from address: 192.168.1.121 HOST: 239.255.255.250:1900 CACHE-CONTROL: max-age=100 EXT: LOCATION: http:https://192.168.1.108:80/description.xml SERVER: Linux/3.14.0 UPnP/1.0 IpBridge/1.19.0 hue-bridgeid: B827EBFFFE8644CD ST: uuid:2f402f80-da50-11e1-9b23-b827eb8644cd USN: uuid:2f402f80-da50-11e1-9b23-b827eb8644cd 2018-01-04 17:11:13,876 [main] INFO com.bwssystems.HABridge.upnp.UpnpListener - Traceupnp: send upnp discovery template 3 with response address: 192.168.1.108:80 to address: /192.168.1.122:50000 HOST: 239.255.255.250:1900 CACHE-CONTROL: max-age=100 EXT: LOCATION: http:https://192.168.1.108:80/description.xml SERVER: Linux/3.14.0 UPnP/1.0 IpBridge/1.19.0 hue-bridgeid: B827EBFFFE8644CD ST: urn:schemas-upnp-org:device:basic:1 USN: uuid:2f402f80-da50-11e1-9b23-b827eb8644cd 2018-01-04 17:11:13,888 [main] INFO com.bwssystems.HABridge.upnp.UpnpListener - Traceupnp: SSDP M-SEARCH packet from 192.168.1.122:50000 HOST: 239.255.255.250:1900 CACHE-CONTROL: max-age=100 EXT: LOCATION: http:https://192.168.1.108:80/description.xml SERVER: Linux/3.14.0 UPnP/1.0 IpBridge/1.19.0 hue-bridgeid: B827EBFFFE8644CD ST: upnp:rootdevice USN: uuid:2f402f80-da50-11e1-9b23-b827eb8644cd::upnp:rootdevice 2018-01-04 17:11:16,924 [main] INFO com.bwssystems.HABridge.upnp.UpnpListener - Traceupnp: send upnp discovery template 2 with response address: 192.168.1.108:80 to address: /192.168.1.122:50000 HOST: 239.255.255.250:1900 CACHE-CONTROL: max-age=100 EXT: LOCATION: http:https://192.168.1.108:80/description.xml SERVER: Linux/3.14.0 UPnP/1.0 IpBridge/1.19.0 hue-bridgeid: B827EBFFFE8644CD ST: uuid:2f402f80-da50-11e1-9b23-b827eb8644cd USN: uuid:2f402f80-da50-11e1-9b23-b827eb8644cd 2018-01-04 17:11:18,439 [main] INFO com.bwssystems.HABridge.upnp.UpnpListener - Traceupnp: send upnp discovery template 3 with response address: 192.168.1.108:80 to address: /192.168.1.122:50000 HOST: 239.255.255.250:1900 CACHE-CONTROL: max-age=100 EXT: LOCATION: http:https://192.168.1.108:80/description.xml SERVER: Linux/3.14.0 UPnP/1.0 IpBridge/1.19.0 hue-bridgeid: B827EBFFFE8644CD ST: urn:schemas-upnp-org:device:basic:1 USN: uuid:2f402f80-da50-11e1-9b23-b827eb8644cd 2018-01-04 17:11:27,302 [main] DEBUG com.bwssystems.HABridge.upnp.UpnpListener - sendUpnpNotify notifyTemplate is <<<NOTIFY * HTTP/1.1 HOST: 239.255.255.250:1900 CACHE-CONTROL: max-age=100 LOCATION: http:https://192.168.1.108:80/description.xml SERVER: Linux/3.14.0 UPnP/1.0 IpBridge/1.19.0 NTS: ssdp:alive hue-bridgeid: B827EBFFFE8644CD NT: uuid:2f402f80-da50-11e1-9b23-b827eb8644cd USN: uuid:2f402f80-da50-11e1-9b23-b827eb8644cd 2018-01-04 17:11:58,669 [main] DEBUG com.bwssystems.HABridge.upnp.UpnpListener - sendUpnpNotify notifyTemplate is <<<NOTIFY * HTTP/1.1 HOST: 239.255.255.250:1900 CACHE-CONTROL: max-age=100 LOCATION: http:https://192.168.1.108:80/description.xml SERVER: Linux/3.14.0 UPnP/1.0 IpBridge/1.19.0 NTS: ssdp:alive hue-bridgeid: B827EBFFFE8644CD NT: uuid:2f402f80-da50-11e1-9b23-b827eb8644cd USN: uuid:2f402f80-da50-11e1-9b23-b827eb8644cd 2018-01-04 17:11:58,687 [main] DEBUG com.bwssystems.HABridge.upnp.UpnpListener - sendUpnpNotify notifyTemplate is <<<NOTIFY * HTTP/1.1 HOST: 239.255.255.250:1900 CACHE-CONTROL: max-age=100 LOCATION: http:https://192.168.1.108:80/description.xml SERVER: Linux/3.14.0 UPnP/1.0 IpBridge/1.19.0 NTS: ssdp:alive hue-bridgeid: B827EBFFFE8644CD NT: uuid:2f402f80-da50-11e1-9b23-b827eb8644cd USN: uuid:2f402f80-da50-11e1-9b23-b827eb8644cd I've tried several UPNP send delays (1000, 1500, 2000, 3000, 4500): No success. Am I doing something wrong? My Harmony Hub has no problems finding the bridge so I suspect the Echo being the culprit. |
|
Quick test tonight on this Echo Dot 2nd GEN - found bridge and device 1st attempt - working as expected. Echo Plus - found bridge and (additional to 1st test) device - this had NEVER worked before - even with my dirty hack on the timing - so working as expected. Looking good for now - will test more tomorrow (including alexa app on IOS for discovery as well). |
|
Please post your run environments and IPs of your devices please. |
|
@F3ELING1337 It seems that the dot finds the bridge and does ask for the lights list. What is on IP 1.122? |
|
Sorry 1.122 is just another Echo Dot 2nd Gen with exactly same firmware version. Tried only one Dot, two at the same time, only the other Dot, no success. Yeah I saw that the Dot seems to ask for the lights but again my Harmony Hub had no problems finding the bridge and listing all lights correctly. So sadly no misconfiguration there :-( |
|
@F3ELING1337 in the Amazon Echo App on your phone, do a add scene as it will go and discover again but it seems it may be different. |
|
If you have two echo devices then if either of them find the bridge and devices then the other won’t report it as new ( it does however learn how to drive it so you can power off the one that discovers first and the other can still drive ).
I staggered my testing. Powered off one echo. Created a new device in the bridge and ran discovery.
Then swapped over crated another device and did it again.
In my case both found the device I added just before the test for the and both echos can drive both devices.
Suggest a double check that the devices haven’t sneaked in (on the app or the web page )
It seems weird because once I got as far as the echo devise asking for the “hue lights” it’s always worked from there on.
Is it worth checking that the get hue api call is returning what is expected ( question for bws )
… On 4 Jan 2018, at 22:10, BWS Systems ***@***.***> wrote:
@F3ELING1337 in the Amazon Echo App on your phone, do a add scene as it will go and discover again but it seems it may be different.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
@Malarcy What being expected is something I am looking for. I may need someone to get the replies from a current V2 Hue Hub to validate. |
|
I can do that. I will grab the request exchange between dot and hue hub (will be tomorrow before I can do that )
I was thinking more of checking what this particular users instance of habridge is returning to the get hue call since it’s working for me we could maybe take a look and see if there’s something in a device name or some other attribute that could give a hint to the echo not processing the reply
I am testing in a clean install with jus a couple of devices with easily spoken names (teddy and fiction - don’t ask ) maybe there’s more things going on with a bigger list for example.
… On 4 Jan 2018, at 22:31, BWS Systems ***@***.***> wrote:
@Malarcy What being expected is something I am looking for. I may need someone to get the replies from a current V2 Hue Hub to validate.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
@bwssytems Today I tried what you suggested. I unplugged 1 of my Dots and asked to discover scenes, here are the results: 2018-01-05 17:16:50,162 [main] INFO com.bwssystems.HABridge.HABridge - HA Bridge (v5.2.0RC1) starting.... If it helps something, here's my device: Again no discovery :-( |
|
@F3ELING1337 Thanks for trying. |
|
I also have an 2nd gen echo that does not discover any devices that are well configures in habridge, see #878 I also tried it with a 1500ms delay, self compiled like this from the void sendUpnpResponse(InetAddress requester, int sourcePort) method: ... unfortunately without luck - does not fix the detection issue for me. |
I have found discovery in my setup to be very hit and miss and for the last two weeks almost completely impossible (worked perhaps once every 50 times).
I noted that new devices on my real HUE bridge were always found
After a lot of tracing and debugging I hit upon the idea of it being a timing issue - I think ha-bridge is responding too quickly for the dot to be ready to receive the response to the M-SEARCH (there a fair amount of upnp traffic on my network, chrome seems to search, as does plex as does my sky tv box - but I am not "flooded" with responses).
I made a quick and dirty change in Upnplistener.java inserting a Thread.sleep(1500) before the call to send the template3 response via sendUDPResponse.
The echo then completes the handshake and I see " hue lights list requested by user" etc.
This - in my setup at least has resulted in 100% stability in discovery.
I offer this purely as info - it may be something that is totally local to me and therefore shouldn't be considered for the code base but I have had poor discovery ever since I started using ha-bridge - and now it's 100% ( from the DOT - I also have an echo plus - that doesn't seem to play nicely - but I will worry about that another day)
The text was updated successfully, but these errors were encountered: