Discontinuation of MyQ Connect Community SmartApp

(Convinced ST will never be unbroken…) #181

Me too, but it seems no one has a clue for what. SmartThings likes to boast/exaggerate how many developers they have, but they have vetted/published very little code (most of that being one trick ponies)

Official, heavily advertised integrations are littered with ‘asterisks’, and have seen no love for years.

I can’t imagine what the experience is for those unwilling/unable to create their own solutions. While I love the concept of the platform, it’s a huge mess.


Yes, I’m aware of that. That still doesn’t mean the platform shouldn’t handle that use case. I mean, even in the copy paste example, I’m betting very few people actually change that code when they load it into the IDE. A simple checksum of the text would probably be enough to identify most of the app installs, even if they are disparate objects.

(ActionTiles.com co-founder Terry @ActionTiles; GitHub: @cosmicpuppy) #183

SmartThings “should handle” a lot of stuff. Don’t hold your breath.


Not to be that guy, but you can publish to Android’s Play store without review. It does virus checks and all behind-the-scenes. That’s why Android started usurping app market share so quickly.


As far as this goes, I might now find some time to reverse engineer the MyQ triggering device (the actual device plugged into your LAN), and just have SmartThings talk directly to that instead. Bypass all of MyQ’s real API completely. If it’s anything like the rest of MyQ, it’ll have plenty of security holes.


God I wish I were smart enough for this. If you need a test bed later when you get it going holler at me.


Im definitely not offended I just choose to do something rather than just get upset here with like minded people. I may be totally wrong but at least I feel like I tried and did my part to change.

(Jason) #188

What is stopping us from soldering a relay onto an actual extra visor remote button terminals and leaving that in the garage to trigger open/closed?? Wouldn’t that be the simplest solution around this?

Of course if there were a way around getting more hardware through @Scythe’s method that would certainly be preferable.

(Brian) #189

Nothing except that it’s more of a hack than most of us want to implement. I’d rather go with @ady624’s solution of having a nodejs server handle all the communication with Chamberlain which then interfaces via LAN with SmartThings. He’s already got all the code written, so this will be my preferred workaround once the IP’s actually get blocked. All you need is something to run a very simple node server on, either a computer in your house that’s always on or else get a Raspberry Pi you can use.

The current code does have the SmartApp doing callouts, but he’s got another version that’s LAN-only he can revert to once the IP block happens.

(Jason) #190

Yeah, I agree with this completely, it’s not ideal.

The upside of it is that it would take out 1-2 possible cloud/server failure points.

(Brian) #191

No doubt about that. The perfect scenario would be fully local control like @scythe mentioned, but that would involve basically hacking the MyQ gateway controller, which is way over my head…not to mention if Chamberlain gets word of any kind of success, they’ll have to lock things down even tighter. I highly doubt they’ll ever be ok with simple commands being sent directly to the unit via LAN.


I have some nice VPS servers spun up already. We could just modify the MyQ SmartApp that’s already written, and have it target my server. Then I can do the actual REST calls to MyQ via some generated Tor proxies. They’d never be able to figure out who/what is running from where then. Effectively we’d scramble the requests. That would be something I could code up in short order with Spring/Java.

(ActionTiles.com co-founder Terry @ActionTiles; GitHub: @cosmicpuppy) #193

Nothing. And if combined with a WiFi or Thing Shield, SmartThings and a Tilt Sensor, and a camera and/or beeper, this is a much simpler solution for any garage door opener.

Chamberlain MyQ (etc!) is a product for folks who do not have a smart home system… That’s why they provide their own cloud and app! SmartThings doesn’t want to be in the garage door business, but a local (well… as local as we get with ST right now) solution should be built using wifi, ZigBee or Z-Wave and cut a second cloud out of the picture!

(Bobby) #194

Or keep the second cloud as back up for when ST decides to push an update to your hub and magically opens your locally operated solution while you are at work or on a business trip…

(ActionTiles.com co-founder Terry @ActionTiles; GitHub: @cosmicpuppy) #195

Ummm… This needs to be a #1 priority for SmartThings to ensure (via technology or education) cannot happen… there is no such thing as "magic’.

(The hub reboot can cause this if it triggers a presences away - return Event and you have your Garage door set to open on “returning presence”. That would be a dumb dumb dumb thing to do. Presence should not be used for anything of any consequence. Period.)

(Ben W) #196

I was thinking about doing the same thing with their website. HTMLtiles may be able to do something.

I agree not to use presence for unsecuring anything. Must be all my days in the Army and physical security.

(Jason) #197

I originally was thinking that I would keep MyQ hooked up for just this point of redundancy(I prefer redundancy in my home, Especially with doors/locks). But it really rubs me the wrong way that they are going to block ST ips I believe Vera has been using (what I assume is the same unofficial api) for much longer with none of these blocks(afaik-I had mine hooked up for more than a year to vera before switching to ST), I may unplug their gateway out of spite.

(Brian) #198



I talked to chamberlain today and he listed off all the android versions and ios versions that myq would work with and told me that they didn’t support the samsung smartthings phone i just laughed. I tried to tell him it wasn’t a phone oh well


Looks like the MyQ triggering device uses MQTT-Secure to do push-notifications and checks. Pretty standard stuff. It’s basically an TLS-encrypted micro sized data packet on a long running connection (which is odd that’s not what their app is using too). The actual up/down status seems to be a state stored on the device itself, and it does a push notification to check its state for reporting.

So in theory, if 3,000 of us are hammering them at around 200 bytes round trip for an open/close call (largest of their request/response sizes) all at the exact same moment, we could maybe cause them to consume ~585 KB of bandwidth. That doesn’t count the REST call up front, but yeah…let’s just say they should have no qualms with what we’re doing from an engineering aspect. This is really just legal junk.

In general there are a few approaches to hacking it to run locally, but it involves more time consumption than I’m willing to put in. It’s much easier to just create a basic REST app out on a virtual server, and have it relay REST calls out to MyQ’s REST services via some quickly spun up TOR proxies. It could also handle exponential backoff if it starts getting overwhelmed with requests from a rogue smartapp gone crazy. A REST service like that should only take a day to code up.

So if it does stop working, I’m pretty confident I’ll be doing something they won’t like and share it with you all.