Comments (17)
Bingo! You were absolutely right - the server where I am running this bridge did not allow port 8083 which I configured. I added a firewall rule to allow it and Echo discovered 5 test devices that I configured with no issues! Commands don't seem to work yet but I think that's because I may not configured devices correctly, so I will look into this. Thank again for all your help.
OP - this could be your problem too, go to Windows firewall and add a PORT rule to allow it if you are using non-standard port.
from nanoverahuesbridge.
Check log.txt in the installation directory (or one of the older log archives—whichever file contains data from the time when you told Echo to discover devices).
Or you can make a clean log (stop service, delete log.txt, then start service. Then tell Alexa to do a discover, then check log.txt).
Other thing to check is that the SSDP Discovery service included with Windows isn’t running. If so, it will grab the SSDP Discovery port (port 1900) and the bridge won’t be able to use that port. To stop it, check these directions:
http://computerstepbystep.com/ssdp_discovery_service.html
From: farhanito [mailto:[email protected]]
Sent: Wednesday, March 09, 2016 2:09 AM
To: nanowebcoder/NanoVeraHuesBridge [email protected]
Subject: [NanoVeraHuesBridge] Alexa can't find anything.. (#1)
I managed to get the bridge running, but alexa can't find any device i set.
—
Reply to this email directly or view it on GitHubhttps://github.com//issues/1.
from nanoverahuesbridge.
here's my log.. http://pastebin.com/5gefFWPU
nothing in the log about "discover devices". turning off SSDP doesn't help either
thanks.
from nanoverahuesbridge.
Yeah, that log looks good. Everything is up and running with no errors.
SSDP is very noisy—Sonos players, Media players, Xboxes, etc all use it to make uPNP work. Underlying it is UDP, is a broadcast technology and a lot of those devices on a home network are broadcasting all the time. The fact that your log isn’t seeing any broadcasts (even ones it ignores) at all tells me that something isn’t configured right.
Two possibilities: either Echo isn’t on the same network, or the Windows SSDP Discovery service is running and blocking receipt of the UDP broadcasts.
If you already turned off SSDP service in Windows, then the next step is to check the IP config. Your computer’s IP (from the log) is:
192.168.31.248
Is your Echo in the same subnet (what’s its IP?). If they are on different subnets, we’ll need to adjust the MulticastIP setting to match.
If your log starts showing lines like this, then its seeing UDP broadcasts:
2016-03-10 08:09:19.2234 | VeraHuesBridge.SSDPService | INFO | Received a UDP multicast from IP [239.255.255.250], on port [1900]. |
2016-03-10 08:09:19.2234 | VeraHuesBridge.SSDPService | INFO | Testing if message is SSDP Discovery Packet... |
From: farhanito [mailto:[email protected]]
Sent: Wednesday, March 09, 2016 9:54 PM
To: nanowebcoder/NanoVeraHuesBridge [email protected]
Cc: Kevin Casey [email protected]
Subject: Re: [NanoVeraHuesBridge] Alexa can't find anything.. (#1)
here's my log.. http://pastebin.com/5gefFWPU
nothing in the log about "discover devices". turning off SSDP doesn't help either
thanks.
—
Reply to this email directly or view it on GitHubhttps://github.com//issues/1#issuecomment-194636024.
from nanoverahuesbridge.
I am having the same issue. All setup and running, Turned off SSDP Service per instructions, it is off. Log looks good with corresponding records above. But Vera says can not find anything. Log below. Any help appreciated. Thanks.
from nanoverahuesbridge.
Yours is actually receiving lots of UDP broadcasts
From: ykamenet [mailto:[email protected]]
Sent: Thursday, March 10, 2016 6:42 PM
To: nanowebcoder/NanoVeraHuesBridge [email protected]
Cc: Kevin Casey [email protected]
Subject: Re: [NanoVeraHuesBridge] Alexa can't find anything.. (#1)
I am having the same issue. All setup and running, Turned off SSDP Service per instructions, it is off. Log looks good with corresponding records above. But Vera says can not find anything. Log below. Any help appreciated. Thanks.
—
Reply to this email directly or view it on GitHubhttps://github.com//issues/1#issuecomment-195101887.
from nanoverahuesbridge.
Yours is receiving UDP broadcasts. So your problem is not the same issue.
Its just not seeing a UDP packet from Alexa. Whats the IP address of your Echo? Is it in the same subnet? ( From the logs, your software is at LocalIP [192.168.1.206]. Does Alexa’s IP start with 192.168.1.x? I assume your subnet mask is 255.255.255.0, but check that too)
These log entries say its getting a UDP packet on the port. It just doesn’t contain the “M-SEARCH” keyword that is a hallmark of an SSDP discovery.
- 2016-03-10 18:30:30.7456 | VeraHuesBridge.SSDPService | INFO | Testing if message is SSDP Discovery Packet... |
- 2016-03-10 18:30:30.7456 | VeraHuesBridge.SSDPService | INFO | SSDP Discovery Packet not detected. |
- 2016-03-10 18:30:30.7456 | VeraHuesBridge.SSDPService | INFO | Restarted Multicast Receiver. |
- 2016-03-10 18:30:30.7456 | VeraHuesBridge.SSDPService | INFO | Received a UDP multicast from IP [239.255.255.250], on port [1900]. |
- 2016-03-10 18:30:30.7456 | VeraHuesBridge.SSDPService | INFO | Testing if message is SSDP Discovery Packet... |
From: ykamenet [mailto:[email protected]]
Sent: Thursday, March 10, 2016 6:42 PM
To: nanowebcoder/NanoVeraHuesBridge [email protected]
Cc: Kevin Casey [email protected]
Subject: Re: [NanoVeraHuesBridge] Alexa can't find anything.. (#1)
I am having the same issue. All setup and running, Turned off SSDP Service per instructions, it is off. Log looks good with corresponding records above. But Vera says can not find anything. Log below. Any help appreciated. Thanks.
—
Reply to this email directly or view it on GitHubhttps://github.com//issues/1#issuecomment-195101887.
from nanoverahuesbridge.
Thanks, not sure what the problem is then. Echo is on the same subnet: 192.168.1.205 echo address. Server where the service is running is 192.168.1.206.
from nanoverahuesbridge.
Stop the service, edit the nLog.config file with notepad.
Change
To minLevel=”Debug”
Then restart the service.
Given that you have a lot of UDP traffic, the log files are going to fill fast. So, pretty quickly after the service starts, tell Alexa to discover devices.
Then stop the service and post the logs. This function is whats inspecting the UDP packets, so we are hoping to see “M-SEARCH”. At the start of the packet and it should contain “MAN: “ etc… Perhaps there’s something different about your Echo.
private static bool IsSSDPDiscoveryPacket(string message)
{
logger.Info("Testing if message is SSDP Discovery Packet...");
logger.Debug("Examing message [{0}]", message);
if (message != null && message.StartsWith("M-SEARCH * HTTP/1.1") && message.Contains("MAN: \"ssdp:discover\""))
{
logger.Info("SSDP Discovery Packet detected.");
return true;
}
logger.Info("SSDP Discovery Packet not detected.");
return false;
}
From: ykamenet [mailto:[email protected]]
Sent: Thursday, March 10, 2016 6:51 PM
To: nanowebcoder/NanoVeraHuesBridge [email protected]
Cc: Kevin Casey [email protected]
Subject: Re: [NanoVeraHuesBridge] Alexa can't find anything.. (#1)
Thanks, not sure what the problem is then. Echo is on the same subnet: 192.168.1.205 echo address. Server where the service is running is 192.168.1.206.
—
Reply to this email directly or view it on GitHubhttps://github.com//issues/1#issuecomment-195106298.
from nanoverahuesbridge.
Another idea: if you have a physical Philips Hues hub, try turning it off before running discovery
From: ykamenet [mailto:[email protected]]
Sent: Thursday, March 10, 2016 6:51 PM
To: nanowebcoder/NanoVeraHuesBridge [email protected]
Cc: Kevin Casey [email protected]
Subject: Re: [NanoVeraHuesBridge] Alexa can't find anything.. (#1)
Thanks, not sure what the problem is then. Echo is on the same subnet: 192.168.1.205 echo address. Server where the service is running is 192.168.1.206.
—
Reply to this email directly or view it on GitHubhttps://github.com//issues/1#issuecomment-195106298.
from nanoverahuesbridge.
Thanks for your support. So I noticed one thing is that if I restart the service, the log does not keep updating for some reason if though the service apepars to be running. I have to restart computer for some reason for it to start working again. I also noticed that when I restart the computer the SSDP Service starts again even though I set it to "Disabled" so I have to shut it down again. I am running this on Windows Home Server 2011 if that makes any difference. Here is the latest log, I do see the M-SEARCH there and Echo IP address (.205) shows up, but it still tells me no devices discovered.
from nanoverahuesbridge.
Ok, new code is in the folder named Latest (https://github.com/nanowebcoder/NanoVeraHuesBridge/tree/master/Latest).
You only need to download the file named NanoVeraHuesBridgeService.exe.
[cid:[email protected]]
-
Stop your service.
-
Copy the new file and overwrite the old file.
-
Start the service
-
Tell Alexa to discover devices
Let me know how that works.
From: ykamenet [mailto:[email protected]]
Sent: Thursday, March 10, 2016 9:33 PM
To: nanowebcoder/NanoVeraHuesBridge [email protected]
Cc: Kevin Casey [email protected]
Subject: Re: [NanoVeraHuesBridge] Alexa can't find anything.. (#1)
Thanks for your support. So I noticed one thing is that if I restart the service, the log does not keep updating for some reason if though the service apepars to be running. I have to restart computer for some reason for it to start working again. I also noticed that when I restart the computer the SSDP Service starts again even though I set it to "Disabled" so I have to shut it down again. I am running this on Windows Home Server 2011 if that makes any difference. Here is the latest log, I do see the M-SEARCH there and Echo IP address (.205) shows up, but it still tells me no devices discovered.
—
Reply to this email directly or view it on GitHubhttps://github.com//issues/1#issuecomment-195151990.
from nanoverahuesbridge.
Ugh. I see the problem. In your log
Man:"ssdp:discover"
The code is looking for
message.Contains("MAN: "ssdp:discover""))
Why yours is only an upper case Man and mine is ALL CAPS… don’t know. I’ll change my code to make it a little less sensitive to the caps and get a fresh copy out there tonight.
From: ykamenet [mailto:[email protected]]
Sent: Thursday, March 10, 2016 9:33 PM
To: nanowebcoder/NanoVeraHuesBridge [email protected]
Cc: Kevin Casey [email protected]
Subject: Re: [NanoVeraHuesBridge] Alexa can't find anything.. (#1)
Thanks for your support. So I noticed one thing is that if I restart the service, the log does not keep updating for some reason if though the service apepars to be running. I have to restart computer for some reason for it to start working again. I also noticed that when I restart the computer the SSDP Service starts again even though I set it to "Disabled" so I have to shut it down again. I am running this on Windows Home Server 2011 if that makes any difference. Here is the latest log, I do see the M-SEARCH there and Echo IP address (.205) shows up, but it still tells me no devices discovered.
—
Reply to this email directly or view it on GitHubhttps://github.com//issues/1#issuecomment-195151990.
from nanoverahuesbridge.
No luck still. Here is the new log after I updated the new .exe file: http://pastebin.com/ii2m99mk
I see that requests from my Echo (ip ends on .205) come with "MAN:" upper case:
2016-03-10 21:24:20.5931 | VeraHuesBridge.SSDPService | INFO | SSDP Discovery Packet not detected. |
2016-03-10 21:24:20.5931 | VeraHuesBridge.SSDPService | INFO | Restarted Multicast Receiver. |
2016-03-10 21:24:25.6020 | VeraHuesBridge.SSDPService | INFO | Received a UDP multicast from IP [239.255.255.250], on port [1900]. |
2016-03-10 21:24:25.6020 | VeraHuesBridge.SSDPService | DEBUG | Multicast From: 192.168.1.205:50000
Data:
M-SEARCH * HTTP/1.1
HOST: 239.255.255.250:1900
MAN: "ssdp:discover"
MX: 15
ST: urn:Belkin:device:**
from nanoverahuesbridge.
Hmmm.. I see its now successfully detecting the M-SEARCH, and returning the setup.xml file location in the part of the log from 3/10.
It succeeded for a device numbered 192.168.1 .248:
- |
- 2016-03-10 21:23:21.8340 | VeraHuesBridge.SSDPService | INFO | Testing if message is SSDP Discovery Packet... |
- 2016-03-10 21:23:21.8340 | VeraHuesBridge.SSDPService | DEBUG | Examing message [M-SEARCH * HTTP/1.1
- HOST: 239.255.255.250:1900
- MAN: "ssdp:discover"
- MX: 1
- ST: urn:dial-multiscreen-org:service:dial:1
- ] |
- 2016-03-10 21:23:21.8340 | VeraHuesBridge.SSDPService | INFO | SSDP Discovery Packet detected. |
- 2016-03-10 21:23:21.8340 | VeraHuesBridge.SSDPService | INFO | Sending SSDP setup information... |
- 2016-03-10 21:23:21.8340 | VeraHuesBridge.SSDPService | DEBUG | Sent Response To: 192.168.1.248:42909
- Data:
- HTTP/1.1 200 OK
- CACHE-CONTROL: max-age=86400
- EXT:
- LOCATION: http://192.168.1.206:8083/api/setup.xml
- OPT: "http://schemas.upnp.org/upnp/1/0/"; ns=01
- 01-NLS: aef85303-330a-4eab-b28d-038ac90416ab
- ST: urn:schemas-upnp-org:device:basic:1
- USN: uuid:Socket-1_0-221438K0100073::urn:Belkin:device:**
22. - |
But it fails on a different device (192.168.1.206) (your bridge is running some kind of media server too?) - 2016-03-10 21:23:16.2589 | VeraHuesBridge.SSDPService | DEBUG | Multicast From: 192.168.1.206:55103
- Data:
- M-SEARCH * HTTP/1.1
- Host:239.255.255.250:1900
- ST:urn:schemas-upnp-org:device:MediaServer:1
- Man:"ssdp:discover"
- MX:3
8. - |
- 2016-03-10 21:23:16.2589 | VeraHuesBridge.SSDPService | INFO | Testing if message is SSDP Discovery Packet... |
- 2016-03-10 21:23:16.2589 | VeraHuesBridge.SSDPService | DEBUG | Examing message [M-SEARCH * HTTP/1.1
- Host:239.255.255.250:1900
- ST:urn:schemas-upnp-org:device:MediaServer:1
- Man:"ssdp:discover"
- MX:3
16. - ] |
- 2016-03-10 21:23:16.2589 | VeraHuesBridge.SSDPService | INFO | SSDP Discovery Packet not detected. |
And then it succeeds on .205 (your Echo, right?)
- 2016-03-10 21:24:25.6020 | VeraHuesBridge.SSDPService | DEBUG | Multicast From: 192.168.1.205:50000
- Data:
- M-SEARCH * HTTP/1.1
- HOST: 239.255.255.250:1900
- MAN: "ssdp:discover"
- MX: 15
- ST: urn:Belkin:device:**
- |
- 2016-03-10 21:24:25.6020 | VeraHuesBridge.SSDPService | INFO | Testing if message is SSDP Discovery Packet... |
- 2016-03-10 21:24:25.6020 | VeraHuesBridge.SSDPService | DEBUG | Examing message [M-SEARCH * HTTP/1.1
- HOST: 239.255.255.250:1900
- MAN: "ssdp:discover"
- MX: 15
- ST: urn:Belkin:device:**
16. - ] |
- 2016-03-10 21:24:25.6020 | VeraHuesBridge.SSDPService | INFO | SSDP Discovery Packet detected. |
- 2016-03-10 21:24:25.6020 | VeraHuesBridge.SSDPService | INFO | Sending SSDP setup information... |
- 2016-03-10 21:24:25.6445 | VeraHuesBridge.SSDPService | DEBUG | Sent Response To: 192.168.1.205:50000
- Data:
- HTTP/1.1 200 OK
- CACHE-CONTROL: max-age=86400
- EXT:
- LOCATION: http://192.168.1.206:8083/api/setup.xml
- OPT: "http://schemas.upnp.org/upnp/1/0/"; ns=01
- 01-NLS: aef85303-330a-4eab-b28d-038ac90416ab
- ST: urn:schemas-upnp-org:device:basic:1
- USN: uuid:Socket-1_0-221438K0100073::urn:Belkin:device:**
30. - |
If 192.168.1.205 is your Echo, we then should see a request to the webserver side of things to get that setup file: http://192.168.1.206:8083/api/setup.xml. With the bridge service running, try going to that URL in your browser. You should get an XML file back. If not, then we have to figure out why (are any firewalls running and blocking port 8083?)
The most recent log entries dated are 3/11, but nLog is not in DEBUG mode, so I cant see why it’s not recognizing the M-SEARCH packets for todays attempts.
Let’s get a clean log:
Stop the service.
Delete the log.txt file.
Edit nLog.config and set the minlevel to Debug.
Then start the service.
Do discovery on Alexa
Stop the service
Send the log file.
From: ykamenet [mailto:[email protected]]
Sent: Friday, March 11, 2016 7:04 PM
To: nanowebcoder/NanoVeraHuesBridge [email protected]
Cc: Kevin Casey [email protected]
Subject: Re: [NanoVeraHuesBridge] Alexa can't find anything.. (#1)
No luck still. Here is the new log after I updated the new .exe file: http://pastebin.com/ii2m99mk
I see that requests from my Echo (ip ends on .205) come with "MAN:" upper case:
2016-03-10 21:24:20.5931 | VeraHuesBridge.SSDPService | INFO | SSDP Discovery Packet not detected. |
2016-03-10 21:24:20.5931 | VeraHuesBridge.SSDPService | INFO | Restarted Multicast Receiver. |
2016-03-10 21:24:25.6020 | VeraHuesBridge.SSDPService | INFO | Received a UDP multicast from IP [239.255.255.250], on port [1900]. |
2016-03-10 21:24:25.6020 | VeraHuesBridge.SSDPService | DEBUG | Multicast From: 192.168.1.205:50000
Data:
M-SEARCH * HTTP/1.1
HOST: 239.255.255.250:1900
MAN: "ssdp:discover"
MX: 15
ST: urn:Belkin:device:**
—
Reply to this email directly or view it on GitHubhttps://github.com//issues/1#issuecomment-195610548.
from nanoverahuesbridge.
Hey that’s awesome!
Yeah, I suppose I should have mentioned to check firewall settings. I don’t use firewalls in my internal networks (but block everything going outbound at the edge router), so I rarely ever think of it.
From: ykamenet [mailto:[email protected]]
Sent: Friday, March 11, 2016 7:39 PM
To: nanowebcoder/NanoVeraHuesBridge [email protected]
Cc: Kevin Casey [email protected]
Subject: Re: [NanoVeraHuesBridge] Alexa can't find anything.. (#1)
Bingo! You were absolutely right - the server where I am running this bridge did not allow port 8083 which I configured. I added a firewall rule to allow it and Echo discovered 5 test devices that I configured with no issues! Commands don't seem to work yet but I think that's because I may not configured devices correctly, so I will look into this. Thank again for all your help.
OP - this could be your problem too, go to Windows firewall and add a PORT rule to allow it if you are using non-standard port.
—
Reply to this email directly or view it on GitHubhttps://github.com//issues/1#issuecomment-195617232.
from nanoverahuesbridge.
OP - this could be your problem too, go to Windows firewall and add a PORT rule to allow it if you are using non-standard port.
no luck still.
i've been using Java version bridge on this same machine, and working fine. (disabled before running this one, of course)
tried everything suggested
- changed exe file,
- changed the port to 8081 (known to work with Java version),
- turned off SSDP discovery,
... alexa still can't find anything.
i think mine have different problem as @nanowebcoder said.
Log : http://pastebin.com/V17mwFmW
BridgeIP : 192.168.31.248 (wired connection)
EchoIP : 192.168.31.100 (5ghz wi-fi)
from nanoverahuesbridge.
Related Issues (12)
- Request: pass details of source echo HOT 3
- pairing not working HOT 7
- Port conflicts (patch attached) HOT 1
- setup.exe HOT 21
- Setting up HOT 19
- Firewall and Scenes HOT 1
- can i use this to Dim HOT 1
- comands HOT 1
- Worked great until modem crash
- Web server HOT 4
- Philips Smart Tv (ambilight)->NanoVeraBridge->MiLight Led Controller HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from nanoverahuesbridge.