[ST Edge] SmartThings MyQ Edge (Obsolete)

I’ve had good uptime until just recently. 1.0.4 fixed the issue with some behind-the-scenes changes, and then I’ve just gotten the API errors today.

Cannot seem to get MyQ to come up again. I tried deleting the MyQ-Controller and re-installing. The controller installed and I put in my credentials. It somehow managed to find the correct server address but immediately says it is offline.

Same here.

Well isn’t this fun timing. The day after I finally get things working again, MyQ breaks things. At least it’s not just us this time - HomeAssistant is also down. I’ll watch for updates there and hopefully make whatever changes needed.

4 Likes

I’m getting intermittent responses now.

1 Like

Good Morning All,

As of 6am ET, it seems to have settled down.

I’m still unclear about the “first” “Status: 200” response (see screenshot below).

Running Windows 10 Executable v1.04

Can anyone tell me if it is normal to see that first Status 200 indication?

Also running 1.0.4 on Win10.
I restarted the service/exe to compare log files with you. Did it twice and I don’t get the line you marked or the one right before it.

image

1 Like

I do get the 200 message but it works fine. It still also says new version available even though im running 1.04

1 Like

@mlchelp and @puzzles312

Thank you both !

@mlchelp It’s good to know I’m not the only one getting the Status 200 message. And yes, with the exception of the MyQ issues last night, v1.04 seems to be working for me too (even with the Status 200).

@puzzles312 interesting you don’t get it. Could be 1000 different things (well maybe 10 or 20) :wink:

  1. My SmartThings v3 Hub v49.09 Firmware; “Wired” to LAN (not wi-fi)
  2. Router
  3. Behaves same for me on two different computers; one WiFi; one Wired
  4. Etc.

I don’t think it’s worth troubleshooting any further given it still works for me and @mlchelp. Just one of life’s mysteries :slight_smile: .

V2 hub running 49.00009, wired

Below is the relevant code from server.js pertaining to SSDP and what generates your status 200. @brbeaird may be able to clarify the code/message you are seeing.

//I tweaked ssdp library to bubble up a broadcast event and to then do an http post to the URL
// this is because this app cannot know its external IP if running as a docker container
server.on(‘response’, async function (headers, msg, rinfo) {
try {
if (searchPending || headers.ST != ssdpId || !headers.SERVER_IP || !headers.SERVER_PORT){
return;
}
searchPending = true;
let hubAddress = http://${headers.SERVER_IP}:${headers.SERVER_PORT}/ping
log(Detected auto-discovery request from SmartThings Hub (${hubAddress}). Replying with bridge server URL.)
let response = await axios.post(hubAddress,
{
myqServerPort: port,
deviceId: headers.DEVICE_ID
},
{timeout: 5000})
log(SmartThings hub acknowledged auto-discovery response (status: ${response.status}). If this message repeats, it means the hub cannot connect to this server's URL due to firewall or network issues.);
} catch (error) {
let msg = error.message;
if (error.response){
msg += error.response.data
}
log(msg, true);
}
});
}

Yes, the status 200 message is actually a good thing. The auto-discovery flow goes like this:

  1. SmartThings hub isn’t sure it knows the correct bridge server IP/port, so it sends out a UDP broadcast across the network hoping to let the bridge server know where to respond to the hub.
  2. The bridge server sees this broadcast message and sends an HTTP request to the hub’s address.
  3. The hub receives the message and responds with a simple 200-status acknowledgement. It takes note of the bridge server’s IP/port.
  4. The hub calls out to the refresh endpoint of the bridge server on the refresh interval.

That said, I’ll probably clarify the log message a bit more - it really doesn’t need to include 200 response code. In addition, something isn’t quite working right because the hub shouldn’t be going into auto-discovery mode when MyQ issues happen as long as the bridge server is still up. I want to figure out a cleaner way to handle that, but so far the MyQ problems always happen when I’m away from a desk where I can reproduce it.

6 Likes

Thank you for all your work on this and the detailed explination.

Second that. One other thing, can anyone confirm how to set the MYQ_SERVER_PORT variable if using the windows executable version of Myq lite? Can’t seem to figure out how to access it. TY

I start it with a batch file that I found someone posted way back in the forum someplace. I run this under task scheduler every 6 hours and it also runs on start up.

::Run MyQBridge if not running
CD C:\SmartThings\MyQBridge
SET MYQ_SERVER_PORT=8125
tasklist /nh /fi “imagename eq myQBridgeServer-win-x64.exe” | find /i “myQBridgeServer-win-x64.exe” > nul ||( start myQBridgeServer-win-x64.exe )

1 Like

does this means that a fixed version will be v 1.05 or later?

Yep my controller is also offline.
@brbeaird we will wait for your update!

Good Morning,

Isn’t that the way it goes ? :grin:

Thank you for the thorough overview!

I know we have had SmartThings myQ issues for a little while, mine has been connected since Friday so I told my wife it was good to go, she called me to the garage with a slight tone in her voice, because it was not closing. Well I whipped out the phone to check the status, said online, started to investigate, and now my torsion spring is broke. LMAO.

1 Like

I bet if you report that to SmartThings Support they’ll tell you to delete and reinstall the app.

6 Likes

And make you go through the whole send me logs deal they always want and then just leave the ticket open and ignore it.