I will give it a try! But after banging my head against the network, I’ll need to take a small mental break 
I ran netstat on my server and this is what I found. The *.166 is my server IP and assuming the port is 139.
When I input this info into the device settings, I get “Error: MyQ Bridge Offline: http://I192.168.4.166:139” in the MyQ Status field.
NETSTAT results:
[myQBridgeServer-win.exe]
TCP 192.168.4.166:139 TEMPLEOFDOOM:0 LISTENING
Can not obtain ownership information
TCP 192.168.4.166:49410 52.159.127.243:https ESTABLISHED
WpnService
[svchost.exe]
TCP 192.168.4.166:57812 192.168.4.141:8008 ESTABLISHED
can’t be 139. sounds like something on windows is preventing your server from obtaining a valid port
That is odd, especially after looking up what Port 139 is supposed to be used for. I went back and looked at other updates around this time, and my Eero Pro 6e also installed new firmware. Now I am wondering if there was something in that update that has stopped this from working.
When you start up the server, you should see a message like "“Http server listening on port [port]”
In an earlier screenshot, I think yours was 56961. Once you have that port number, open up a browser window and navigate to http://serverip:port/status
If that comes up, do the same thing but from a different machine on your LAN (if possible) - that would prove that the server is accessible on that port to the rest of your network, and then entering in that IP/Port combination in SmartThings should get this running.
3 Likes
And we have lift off 
Strike my previous post. I reserved the IP address and port in my eero, then input that into the device settings. Voila! The credentials were passed, and the door was found.
I have no idea what changed in my network that would have caused the autodetect not to work. It worked flawlessly for a month without any intervention.
Thank you, and to @jkp for the help and for being so responsive. I very much appreciate it, and I got to learn a lot in the process! (CLI, Powershell and troubleshooting). Happy Holidays to you both!
1 Like
none of the compatibility settings worked. tried them all. I’m at a loss. I guess I’ll have to just use a zwave garage opener, and call it done. thanks for the help anyways.
1 Like
Did you see @peeps post at 708 about what he found and had to do to make it run. I’m not using windows, but possibly your in the same boat as him?
Has anyone been able to run MyQ Edge server on a Rasberry Pi4 running x64 Raspbian? If so, what method did you use and how can you see if it’s running? Newbie here. TIA!!
I use docker + Portainer. Create a stack in Portainer to build everything:
version: "2"
services:
smartthings-myq-edge:
image: brbeaird/smartthings-myq-edge:latest
container_name: smartthings-myq-edge
ports:
- 8090:8090/tcp
- 1900:1900/udp
restart: unless-stopped
services:
smartthings-myq-edge:
image: brbeaird/smartthings-myq-edge:latest
container_name: smartthings-myq-edge
restart: always
network_mode: host
security_opt:
- seccomp:unconfined
volumes:
- ./smartthings-myq-edge:/smartthings-myq-edge
to check the status:
http://IP address: port number used/status
4 Likes
Thank you!!
@brbeaird
I was trying to track down an error message in home assistant, which it keeps encountering on my network, and I traced it back to the smartthings Myq server that I’m running (BTW, your MyQ integration in ST runs more reliable than the one in home assistant! Great Job!)
Upon further investigating, and it appears that the SSDP response from an m-search shows a problem in the LOCATION key. This is what I get from the server:
Got a response to an m-search:
200
{
"ST": "urn:SmartThingsCommunity:device:MyQController",
"USN": "uuid:smartthings-brbeaird-myq::urn:SmartThingsCommunity:device:MyQController",
"CACHE-CONTROL": "max-age=1800",
"DATE": "Thu, 05 Jan 2023 20:22:17 GMT",
"SERVER": "node.js/16.18.1 UPnP/1.1 node-ssdp-response/4.1.0",
"EXT": "",
"LOCATION": "http://:8090/details"
}
{
"address": "192.168.1.182",
"family": "IPv4",
"port": 1900,
"size": 317
}
There is no actual IP address for location, and it looks like this causes issues for other software, like home assistant, that scan using SSDP on the network.
That’s interesting. Ideally, the MyQ bridge server should not respond to m-searches that do not specifically send along the MyQController USN string. I guess HA does wildcard searches. I’ll look into disabling responses to wildcard searches.
Originally, I was using the location key to pass along the bridge server’s IP back to the SmartThings hub but soon found out that the bridge server often cannot accurately know its own external IP, especially if running in a Docker container. So now location is useless. I could force it to be a real URL, but chances are if HA were to try and hit it, there would be no response.
I’ll take some credit for smoothing things out, but the truth is this runs using the same underlying library created by the home assistant author 
.
I just got done modifying the server.js script by hardcoding the server’s IP address in the LOCATION key, just to see how HA reacts.
It’s been 2 hours and no errors reports from HA. So I was thinking that the lack of an IP address causes the error, so I tried “0.0.0.0” and this removed the error also.
Been loving the new integration. This was one I was stressing about with the change and it has all worked smothly once I worked out the kinks with getting the bridge server running.
With this integration, is there a need to check this thread periodically for updates to download or are code updates handled by some backend that you handle and we are just connecting to it?
That’s great info, thanks. Makes sense that it would blow up trying to parse an invalid IP. I’ll update the server code.
For the Edge driver, no. For changes made to the Bridge LAN server, yes it’s possible, and I will post here if I make changes. That said, if you’re running in Docker and pointing to DockerHub, you should see an update there and your system may even auto-update.
1 Like
For the Edge driver, no. For changes made to the Bridge LAN server, yes it’s possible, and I will post here if I make changes. That said, if you’re running in Docker and pointing to DockerHub, you should see an update there and your system may even auto-update.
Good to know. Thanks! Will keep an eye out as I never bothered trying to get Docker going on my Win10 Home setup once I got the EXE to run on startup without needing UAC authorization.
So this thread has grown huge!
Is the short of this, MyQ [Edge] driver needs a server like raspberry pi or something?
I don’t have any dedicated servers running at home, nor do I have a raspberry pi. I realize they are inexpensive, but I’m just not really wanting one more device to worry about.
Are there alternatives I can consider? (Like a “PI as a service” offering, or something that doesn’t require a raspberry pi? or???)
Thanks for any ideas/suggestions…
Yes, it has! However, as in most threads, the original (first) post has most of what you need to get going.
If you follow the link in the first post, you’ll get to this list of executables you can run on your choice of Linux, MacOS, or Windows. Any of these wouldn’t need a dedicated server. Run as a service on a workstation would suffice.
Okay I have tried for days and I can’t get past the “Awaiting credentials”
The newer myQBridgeServer-win app is running on a always on Windows 10 PC without any config.json file in the same directory. It is reporting the following:
I have ran the Smarthings CLI on the MyQConnector Driver and it is reporting the following:
Suggestions as to what I may be doing incorrectly?
Thanks for any help I can get.