Closed Pseudomizer closed 7 years ago
same with me.. Every thing was was working 5 days back.. Then it stopped working. Updated to 3.5.1 not alexa not discovering anything. Tried everything. Need some help.
I even removed all devices from the bridge after a backup. Then I added 1 switch and 1 scene just in case the number of devices are causing the issue, which was the case before. Still nothing.
I tested again today removed everything and tried again. Ha-bridge is discovered by harmony hub but not by alexa app. Anybody has any ideas.
I'm assuming you already verified that the UPNP address hasn't changed for the device you are using to run your hub and that your router is redirecting to that IP from Amazon.
What are the steps to verify that? I did upgrade the HA bridge to 3.5.1, but I also upgraded Rasperian to the latest version. If that causes changes, then please let me know, how to fix that.
Thanks in advance.
What's the IP of your Raspberry Pi? Is it using dhcp or static? If dhcp is it reserved on your router to be the same IP all the time? If you find the IP of your Pi, then set the upnp IP address in the bridge setup to the same address.
If that doesn't work, I also had to open port 1900 for UDP traffic from my router and point it to the server running the bridge.
I am using DHCP but I reserved the mac address to have the same IP every single time. So the IP is basically fixed to ensure consistency.
I understand your point about port 1900 but why is Google Home finding the HA bridge and Amazon Echo does not? Is this an Amazon specific port?
I haven't played around with Google home so I don't know.
So is your UPNP address the same as your server address?
If that doesn't resolve try opening up 1900. Otherwise I'm at a loss as well.
Sorry.
I just created a new rule for 192.168.1.0 where all UDP Traffic gets routed to 192.168.1.50, which is my PI. Still no luck.
And the UPNP address is 192.168.1.50 in your config?
The rule I have is all inbound traffic on 1900 UDP is sent to my PI. I'm not home so can't check the exact terminology on the router.
Yes
Pseudomizer - sorry for keep interrupting in your thread but i am also in same issue. My harmony and Anymote app on android both detects ha-bridge running on pi and can control it also but amazon echo cannot find anything. Tried on 2 amazon echo's same. All was working on the old jar file as i was using a very old ha-bridge update and everything was working fine till 4 days back, Then i updated to new jar file and change the config as given in the new updated page now echo not finding anything. Can't figure out anything.
Did you try to downgrade and see, if it works for you? Doesn't work for me, but maybe it works for you.
Have done that also same here.. Its working great from harmony hub and my phone.
Add me to the list. I upgrade to 3.5.1 and then tried to discover some new devices - nothing. Tried deleting all devices and starting from scratch - nothing discovers. Everything appears to be running and no errors. I don't think this is related to 3.5.1 - I think it just started happening at the same time. My ha-bridge is running on a Windows 7 machine and was working fine up until I started having this issue. Anything else I can post to help diagnose this? Thanks.
Here are some logs after going into Debug mode for most of the modules. This clearly shows how the HA bridge is exchanging information with my Google Home device. I pressed discover 3 times during that time and the log doesn't show anything from any of my two Alexa IP addresses. It seems like Alexa doesn't even try to communicate with the HA bridge at all...
I am now testing with JAR 3.2.1 and no longer with 3.5.1 as this was working before. So the log files below are for version 3.2.1 HA bridge.
192.168.1.50 = HA bridge 192.168.1.238 = Google Home
11-27-2016 23:44:55.283 DEBUG isSSDPDiscovery Got SSDP packet from 192.168.1.238:32820, body: M-SEARCH * HTTP/1.1 HOST: 239.255.255.250:1900 MAN: "ssdp:discover" MX: 2 ST: ssdp:all
com.bwssystems.HABridge.upnp.UpnpListener
11-27-2016 23:44:55.283 DEBUG isSSDPDiscovery found message to be valid under strict rules - strict: true com.bwssystems.HABridge.upnp.UpnpListener 11-27-2016 23:44:55.287 DEBUG sendUpnpResponse discovery responseTemplate1 is <<<HTTP/1.1 200 OK HOST: 239.255.255.250:1900 CACHE-CONTROL: max-age=100 EXT: LOCATION: http://192.168.1.50:80/description.xml SERVER: Linux/3.14.0 UPnP/1.0 IpBridge/1.15.0 hue-bridgeid: B827EBFFFE053F93 ST: upnp:rootdevice USN: uuid:2f402f80-da50-11e1-9b23-b827eb053f93::upnp:rootdevice
com.bwssystems.HABridge.upnp.UpnpListener
11-27-2016 23:44:55.287 DEBUG Sending response string: <<<HTTP/1.1 200 OK HOST: 239.255.255.250:1900 CACHE-CONTROL: max-age=100 EXT: LOCATION: http://192.168.1.50:80/description.xml SERVER: Linux/3.14.0 UPnP/1.0 IpBridge/1.15.0 hue-bridgeid: B827EBFFFE053F93 ST: upnp:rootdevice USN: uuid:2f402f80-da50-11e1-9b23-b827eb053f93::upnp:rootdevice
com.bwssystems.util.UDPDatagramSender
11-27-2016 23:44:55.288 DEBUG sendUpnpResponse discovery responseTemplate2 is <<<HTTP/1.1 200 OK HOST: 239.255.255.250:1900 CACHE-CONTROL: max-age=100 EXT: LOCATION: http://192.168.1.50:80/description.xml SERVER: Linux/3.14.0 UPnP/1.0 IpBridge/1.15.0 hue-bridgeid: B827EBFFFE053F93 ST: uuid:2f402f80-da50-11e1-9b23-b827eb053f93 USN: uuid:2f402f80-da50-11e1-9b23-b827eb053f93
com.bwssystems.HABridge.upnp.UpnpListener
11-27-2016 23:44:55.289 DEBUG Sending response string: <<<HTTP/1.1 200 OK HOST: 239.255.255.250:1900 CACHE-CONTROL: max-age=100 EXT: LOCATION: http://192.168.1.50:80/description.xml SERVER: Linux/3.14.0 UPnP/1.0 IpBridge/1.15.0 hue-bridgeid: B827EBFFFE053F93 ST: uuid:2f402f80-da50-11e1-9b23-b827eb053f93 USN: uuid:2f402f80-da50-11e1-9b23-b827eb053f93
com.bwssystems.util.UDPDatagramSender
11-27-2016 23:44:55.290 DEBUG sendUpnpResponse discovery responseTemplate3 is <<<HTTP/1.1 200 OK HOST: 239.255.255.250:1900 CACHE-CONTROL: max-age=100 EXT: LOCATION: http://192.168.1.50:80/description.xml SERVER: Linux/3.14.0 UPnP/1.0 IpBridge/1.15.0 hue-bridgeid: B827EBFFFE053F93 ST: urn:schemas-upnp-org:device:basic:1 USN: uuid:2f402f80-da50-11e1-9b23-b827eb053f93
com.bwssystems.HABridge.upnp.UpnpListener
11-27-2016 23:44:55.290 DEBUG Sending response string: <<<HTTP/1.1 200 OK HOST: 239.255.255.250:1900 CACHE-CONTROL: max-age=100 EXT: LOCATION: http://192.168.1.50:80/description.xml SERVER: Linux/3.14.0 UPnP/1.0 IpBridge/1.15.0 hue-bridgeid: B827EBFFFE053F93 ST: urn:schemas-upnp-org:device:basic:1 USN: uuid:2f402f80-da50-11e1-9b23-b827eb053f93
com.bwssystems.util.UDPDatagramSender
1-27-2016 23:53:31.927 DEBUG hue lights list requested: d2e0c6c235fe4e87a0bfb717cdbb2610 from 192.168.1.238 com.bwssystems.HABridge.hue.HueMulator
Dumb question. Did anyone restart their Echo? And what type of Echo's are they?
Lol. Yes, and I even went as far rebooting both Alexas at the same time and shutting one off and leave just one on. They are both full blown Echos. No tap or dots.
Ok, then. your log shows that it did not send a upnp multicast request out or it would have been seen by the bridge.
When I remove the real hue bridge from Alexa and then go to discover, it gets found. So I assume that Alexa is sending a broadcast out. It is not showing up in the logs of the HA bridge though. So I don't know what else to check.
Ahh, yes. When there is a real hue bridge on the network, you need to disconnect that and then discover for the ha-bridge, then reconnect the real hue bridge. Known issue with the Alexa.
Tried restarting both amazon echo. Don't have any real hue bridge on network. Ha-bridge is discovered by harmony hub and Anymote just not by echo. Is it possible that something in echo got updated as before that everything was working.
@vageesh79 Have you turned on trace upnp in the settings to see what is talking to your bridge? That will help immensely.
Here is the Upnp trace log i can see -
11-28-2016 12:45:57.791 INFO == Spark has ignited ... spark.webserver.JettySparkServer 11-28-2016 12:45:57.808 INFO >> Listening on 0.0.0.0:80 spark.webserver.JettySparkServer 11-28-2016 12:45:58.217 INFO HABridge device management service started.... com.bwssystems.HABridge.devicemanagmeent.DeviceResource 11-28-2016 12:45:58.269 INFO Hue description service started.... com.bwssystems.HABridge.upnp.UpnpSettingsResource 11-28-2016 12:45:58.280 INFO Initializing UDP response Seocket... com.bwssystems.util.UDPDatagramSender 11-28-2016 12:45:58.294 INFO UDP response Seocket initialized to: 50000 com.bwssystems.util.UDPDatagramSender 11-28-2016 12:45:58.309 INFO Traceupnp: upnp device settings requested: from 192.168.0.20:80 com.bwssystems.HABridge.upnp.UpnpSettingsResource 11-28-2016 12:45:58.321 INFO Traceupnp: upnp device settings template filled with address: 192.168.0.210 and port: 80 com.bwssystems.HABridge.upnp.UpnpSettingsResource 11-28-2016 12:45:58.511 INFO Hue emulator service started.... com.bwssystems.HABridge.hue.HueMulator 11-28-2016 12:45:58.532 INFO UPNP Discovery Listener starting.... com.bwssystems.HABridge.upnp.UpnpListener 11-28-2016 12:45:58.545 INFO Traceupnp: eth0 ... has addr /fe80:0:0:0:4522:60ca:bdd7:1bb9%eth0 com.bwssystems.HABridge.upnp.UpnpListener 11-28-2016 12:45:58.551 INFO Traceupnp: wlan0 ... has addr /fe80:0:0:0:6c37:7945:407:d636%wlan0 com.bwssystems.HABridge.upnp.UpnpListener 11-28-2016 12:45:58.558 INFO Traceupnp: wlan0 ... has addr /fd00:f0f2:49a7:5d22:57d7:576a:c214:3280%wlan0 com.bwssystems.HABridge.upnp.UpnpListener 11-28-2016 12:45:58.567 INFO Traceupnp: wlan0 ... has addr /192.168.0.210 com.bwssystems.HABridge.upnp.UpnpListener 11-28-2016 12:45:58.577 INFO Traceupnp: Adding lo to our interface set com.bwssystems.HABridge.upnp.UpnpListener 11-28-2016 12:46:34.129 INFO Traceupnp: isSSDPDiscovery found message to be valid under strict rules - strict: true com.bwssystems.HABridge.upnp.UpnpListener 11-28-2016 12:46:34.266 INFO Traceupnp: sendUpnpResponse discovery responseTemplate1 is <<<HTTP/1.1 200 OK HOST: 239.255.255.250:1900 CACHE-CONTROL: max-age=100 EXT: LOCATION: http://192.168.0.210:80/description.xml SERVER: Linux/3.14.0 UPnP/1.0 IpBridge/1.15.0 hue-bridgeid: 30B5C2FFFE186086 ST: upnp:rootdevice USN: uuid:2f402f80-da50-11e1-9b23-30b5c2186086::upnp:rootdevice
com.bwssystems.HABridge.upnp.UpnpListener 11-28-2016 12:46:34.305 INFO Traceupnp: sendUpnpResponse discovery responseTemplate2 is <<<HTTP/1.1 200 OK HOST: 239.255.255.250:1900 CACHE-CONTROL: max-age=100 EXT: LOCATION: http://192.168.0.210:80/description.xml SERVER: Linux/3.14.0 UPnP/1.0 IpBridge/1.15.0 hue-bridgeid: 30B5C2FFFE186086 ST: uuid:2f402f80-da50-11e1-9b23-30b5c2186086 USN: uuid:2f402f80-da50-11e1-9b23-30b5c2186086
com.bwssystems.HABridge.upnp.UpnpListener 11-28-2016 12:46:34.334 INFO Traceupnp: sendUpnpResponse discovery responseTemplate3 is <<<HTTP/1.1 200 OK HOST: 239.255.255.250:1900 CACHE-CONTROL: max-age=100 EXT: LOCATION: http://192.168.0.210:80/description.xml SERVER: Linux/3.14.0 UPnP/1.0 IpBridge/1.15.0 hue-bridgeid: 30B5C2FFFE186086 ST: urn:schemas-upnp-org:device:basic:1 USN: uuid:2f402f80-da50-11e1-9b23-30b5c2186086
com.bwssystems.HABridge.upnp.UpnpListener 11-28-2016 12:46:39.150 INFO Traceupnp: isSSDPDiscovery found message to be an M-SEARCH message. com.bwssystems.HABridge.upnp.UpnpListener 11-28-2016 12:46:39.160 INFO Traceupnp: isSSDPDiscovery found message to be valid under strict rules - strict: true com.bwssystems.HABridge.upnp.UpnpListener 11-28-2016 12:46:39.161 INFO Traceupnp: SSDP packet from 192.168.0.210:43699, body: M-SEARCH * HTTP/1.1 HOST: 239.255.255.250:1900 MAN: "ssdp:discover" MX: 1 ST: upnp:rootdevice
com.bwssystems.HABridge.upnp.UpnpListener
11-28-2016 12:46:39.197 INFO Traceupnp: sendUpnpResponse discovery responseTemplate1 is <<<HTTP/1.1 200 OK HOST: 239.255.255.250:1900 CACHE-CONTROL: max-age=100 EXT: LOCATION: http://192.168.0.210:80/description.xml SERVER: Linux/3.14.0 UPnP/1.0 IpBridge/1.15.0 hue-bridgeid: 30B5C2FFFE186086 ST: upnp:rootdevice USN: uuid:2f402f80-da50-11e1-9b23-30b5c2186086::upnp:rootdevice
com.bwssystems.HABridge.upnp.UpnpListener 11-28-2016 12:46:39.216 INFO Traceupnp: sendUpnpResponse discovery responseTemplate2 is <<<HTTP/1.1 200 OK HOST: 239.255.255.250:1900 CACHE-CONTROL: max-age=100 EXT: LOCATION: http://192.168.0.210:80/description.xml SERVER: Linux/3.14.0 UPnP/1.0 IpBridge/1.15.0 hue-bridgeid: 30B5C2FFFE186086 ST: uuid:2f402f80-da50-11e1-9b23-30b5c2186086 USN: uuid:2f402f80-da50-11e1-9b23-30b5c2186086
com.bwssystems.HABridge.upnp.UpnpListener 11-28-2016 12:46:39.233 INFO Traceupnp: sendUpnpResponse discovery responseTemplate3 is <<<HTTP/1.1 200 OK HOST: 239.255.255.250:1900 CACHE-CONTROL: max-age=100 EXT: LOCATION: http://192.168.0.210:80/description.xml SERVER: Linux/3.14.0 UPnP/1.0 IpBridge/1.15.0 hue-bridgeid: 30B5C2FFFE186086 ST: urn:schemas-upnp-org:device:basic:1 USN: uuid:2f402f80-da50-11e1-9b23-30b5c2186086
com.bwssystems.HABridge.upnp.UpnpListener
Now, what is the address of your echo?
Its 192.168.0.22. It is connected to internet and my other skills are working on that but i think echo is not finding the bridge
192.168.0 210 is the raspberry pi address running ha-bridge..
Did you try telling it to do a discover multiple times after the bridge restart?
Just tried again and this is what i gt in logs -
11-28-2016 13:47:16.878 INFO Traceupnp: isSSDPDiscovery found message to be an M-SEARCH message. com.bwssystems.HABridge.upnp.UpnpListener 11-28-2016 13:47:16.885 INFO Traceupnp: isSSDPDiscovery found message to be valid under strict rules - strict: true com.bwssystems.HABridge.upnp.UpnpListener 11-28-2016 13:47:16.885 INFO Traceupnp: SSDP packet from 192.168.0.210:45271, body: M-SEARCH * HTTP/1.1 HOST: 239.255.255.250:1900 MAN: "ssdp:discover" MX: 1 ST: ssdp:all
com.bwssystems.HABridge.upnp.UpnpListener
11-28-2016 13:47:16.912 INFO Traceupnp: sendUpnpResponse discovery responseTemplate1 is <<<HTTP/1.1 200 OK HOST: 239.255.255.250:1900 CACHE-CONTROL: max-age=100 EXT: LOCATION: http://192.168.0.210:80/description.xml SERVER: Linux/3.14.0 UPnP/1.0 IpBridge/1.15.0 hue-bridgeid: 30B5C2FFFE186086 ST: upnp:rootdevice USN: uuid:2f402f80-da50-11e1-9b23-30b5c2186086::upnp:rootdevice
com.bwssystems.HABridge.upnp.UpnpListener 11-28-2016 13:47:16.913 INFO Traceupnp: sendUpnpResponse discovery responseTemplate2 is <<<HTTP/1.1 200 OK HOST: 239.255.255.250:1900 CACHE-CONTROL: max-age=100 EXT: LOCATION: http://192.168.0.210:80/description.xml SERVER: Linux/3.14.0 UPnP/1.0 IpBridge/1.15.0 hue-bridgeid: 30B5C2FFFE186086 ST: uuid:2f402f80-da50-11e1-9b23-30b5c2186086 USN: uuid:2f402f80-da50-11e1-9b23-30b5c2186086
com.bwssystems.HABridge.upnp.UpnpListener 11-28-2016 13:47:16.997 INFO Traceupnp: sendUpnpResponse discovery responseTemplate3 is <<<HTTP/1.1 200 OK HOST: 239.255.255.250:1900 CACHE-CONTROL: max-age=100 EXT: LOCATION: http://192.168.0.210:80/description.xml SERVER: Linux/3.14.0 UPnP/1.0 IpBridge/1.15.0 hue-bridgeid: 30B5C2FFFE186086 ST: urn:schemas-upnp-org:device:basic:1 USN: uuid:2f402f80-da50-11e1-9b23-30b5c2186086
com.bwssystems.HABridge.upnp.UpnpListener 11-28-2016 13:47:21.880 INFO Traceupnp: isSSDPDiscovery found message to be an M-SEARCH message. com.bwssystems.HABridge.upnp.UpnpListener 11-28-2016 13:47:21.887 INFO Traceupnp: isSSDPDiscovery found message to be valid under strict rules - strict: true com.bwssystems.HABridge.upnp.UpnpListener 11-28-2016 13:47:21.888 INFO Traceupnp: SSDP packet from 192.168.0.210:57928, body: M-SEARCH * HTTP/1.1 HOST: 239.255.255.250:1900 MAN: "ssdp:discover" MX: 1 ST: upnp:rootdevice
com.bwssystems.HABridge.upnp.UpnpListener
11-28-2016 13:47:21.892 INFO Traceupnp: sendUpnpResponse discovery responseTemplate1 is <<<HTTP/1.1 200 OK HOST: 239.255.255.250:1900 CACHE-CONTROL: max-age=100 EXT: LOCATION: http://192.168.0.210:80/description.xml SERVER: Linux/3.14.0 UPnP/1.0 IpBridge/1.15.0 hue-bridgeid: 30B5C2FFFE186086 ST: upnp:rootdevice USN: uuid:2f402f80-da50-11e1-9b23-30b5c2186086::upnp:rootdevice
com.bwssystems.HABridge.upnp.UpnpListener 11-28-2016 13:47:21.911 INFO Traceupnp: sendUpnpResponse discovery responseTemplate2 is <<<HTTP/1.1 200 OK HOST: 239.255.255.250:1900 CACHE-CONTROL: max-age=100 EXT: LOCATION: http://192.168.0.210:80/description.xml SERVER: Linux/3.14.0 UPnP/1.0 IpBridge/1.15.0 hue-bridgeid: 30B5C2FFFE186086 ST: uuid:2f402f80-da50-11e1-9b23-30b5c2186086 USN: uuid:2f402f80-da50-11e1-9b23-30b5c2186086
com.bwssystems.HABridge.upnp.UpnpListener 11-28-2016 13:47:21.914 INFO Traceupnp: sendUpnpResponse discovery responseTemplate3 is <<<HTTP/1.1 200 OK HOST: 239.255.255.250:1900 CACHE-CONTROL: max-age=100 EXT: LOCATION: http://192.168.0.210:80/description.xml SERVER: Linux/3.14.0 UPnP/1.0 IpBridge/1.15.0 hue-bridgeid: 30B5C2FFFE186086 ST: urn:schemas-upnp-org:device:basic:1 USN: uuid:2f402f80-da50-11e1-9b23-30b5c2186086
com.b
Well, it sseems the echo is not broadcasting a upnp multicast message. Check your router settings.
Let me check that again.. upnp is open on router. I even opened the port 1900 also but il see if i missed anything.
I noticed that both lan0 and wan0 have IPv6 addresses bound as well. Have you tried setting Java to prefer ipv4v?
-Djava.net.preferIPv4Stack=true
It is automatically set to IPV4 in the code.
Cannot find anything on router. I just tried enabling vera and harmony skills and echo is discovering vera and harmony devices. I think i had to start from scratch installing everything again.
Same problem here. Decided to give this a go to replace an original Amazon-ha-bridge install. I should have stuck with "if it ain't broke don't fix it", as now I can't discover any devices or anything. Nothing on the router changed at all, just rebooted it, as well as everything else and no change.
My echos have 192.168.1.34 and .35. My Asus router has uPnp enabled.
I also noticed one more phenomenon. Vera uses uPnp to discover Sonos. This used to work but now the discovery returns nothing. I have to manually enter the IP addresses of my 3 Sonos speakers.
This is getting frustrating. uPnP, which should be universal plug and play becomes plug and pray now. I can troubleshoot IP issues but I have never troubleshooted uPnP issues.
In summary: Both Alexas don't find the HA bridge. Google home DOES find the HA bridge. Sonos is no longer discoverable but works with manual IP entering.
Anyone else facing issues
I am counting 4 people above having the same issues in total.
I actually resolved mine, turned out that on restart my settings didn't save, so I needed to go into the settings page and set uPNP IP again, saved it restarted and did a rediscover. All was well after that.
On Tue, Nov 29, 2016 at 5:51 PM Pseudomizer notifications@github.com wrote:
I am counting 4 people above having the same issues in total.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/bwssytems/ha-bridge/issues/278#issuecomment-263726264, or mute the thread https://github.com/notifications/unsubscribe-auth/AJ59bAP7kqnKX6WEix671ky8fC9n9z_1ks5rDKxygaJpZM4K9E8m .
Today i tried it on fresh installation used an old version but still same. I think the problem is with Echo only as if i add hue bridge on harmony hub it is added. Only Echo is having trouble finding the bridge. Anyone has any idea. UPNP is working fine on network as harmony and my phone software Anymote are finding bridge easily.
You might want to look into wireshark to debug your network.
Got it working. Problem was with the router only. I switched to a different gateway and now echo is discovering.
Great!
I am sorry, but I opened this case and it is still not resolved for me and 2 other guys.
Sorry about that. You did get it to discover when you took your real hue bridge off the network. There is something the echo is doing in that case and I cannot fix that.
@simondsmason Please take a look at your windows firewall to make sure that upnp is not blocked.
@jlekhter Glad you fixed it with the port unblock.
I am using Raspberry PI 3. I am going to trace my network when I get from my business trip.
I am also going to work with my router company to see if they have something to say especially why Google Home is working and Echos are not.
Thanks for reopening.
So, this is not an issue list for Echo problems. This is an issue list for ha-bridge problems and enhancements and not really a forum. Hope you understand.
Hello guys, I updated to HA 3.5.1 today. I also added 2 new devices in Vera and the HA bridge. Alexa, couldn't find them. I deleted all devices on Alexa. Tried to rediscover. Nothing. Rebootet both Alexas in my home. Rebootet the HA bridge on my PI. Nothing. Downgraded to 3.2.1 again. Still not working. Disabled uPNP on my router and hammered the IP of Alexa as the uPNP address into the HA bridge just to test. Nothing. Alexa finds the real Hue bridge with my 12 bulbs and my Nest and my Ecobee3 via the 2 skills. Nothing else is being discovered. Then I read about the new support for Google home and I changed the port from 5050 to 80 for the HA bridge. GOOGLE HOME FOUND ALL DEVICES! Alexa discovers nothing! Enabled logging on router and HA bridge as suggested in the previous issues thread with one debug level while all others are on info only. My router doesn't show any uPNP logs (Asus RT-A5300) and the HA bridge doesn't log anything either about Alexa... BUT it shows how Google Home requests an updated list every min or two and the HA bridge responds. At this stage I am out of ideas guys.
Thanks in advance for any help here.