Google Home + MyQ : does not support OPEN!!!! wtf! MAJOR FAIL

  • 14
  • Problem
  • Updated 1 week ago
  • (Edited)
cannot OPEN door with Google Home or IFTTT .... WTF!!!!!  and you want to charge me $10 yearly for this?????
Photo of mkrosse

mkrosse

  • 7 Posts
  • 12 Reply Likes
  • utterly disgusted w Chamberlain idiots

Posted 2 years ago

  • 14
Photo of Richard Tumi

Richard Tumi

  • 1 Post
  • 1 Reply Like
Two years and still using the "trying to find a way to make it happen securely" excuse for not allowing google home users the ability to open their garage doors... silly. It's not difficult. It's not time consuming.Your team isn't dumb. You're just not going to do it. SO, just say so, offer a refund to every user that "signed up" for the MyQ "Close-only" service, and let Genie, Ryobi, etc. eat your lunch.
Photo of Leo

Leo

  • 2 Posts
  • 0 Reply Likes
Agree; now it appears to have been more than a year since the last community manager left an update on this process....As it happens I know more than my fair share about API's, integration, and how different softwares' "speak" to one another.  Would you like me to sum it up? Sure you wouldn't, so here we go:
MyQ "integrates" with Google using a slightly different model than devices like Phillips Hue bulbs, and Wemo devices (which is why they charge a yearly fee).  MyQ utilizes a cloud-based "middle man" that, in this case interprets the commands issued.  This is different as the other model simply passes a phrase or word on to the cloud directly which has an automated response based on whatever the phrase or word that is sent  happens to be.  Because of this, MyQ (ie: Chamberlain) is in complete control over what commands can be passed, how they are passed, and what "security" is utilized to pass them.
What does this all mean?  It means that more than likely  the software that runs on the cloud side absolutely has the the functionality to be able to OPEN the garage door, but that it is simply configured not to----by simply configured, I mean it is likely something as simple as an xml file the cloud parses that says something along the lines of <allow open  if not homekit=NO>.  Which, once you understand that is how these things work on the cloud level, tends to infuriate a person even more, as now they can see just how easy it would be to correct this oversight <allow open if not homekit=YES>.
Yes, that is a bit of an oversimplification if one is intending to bolster the security, and yes it is a bit of an oversimplification if, as I suspect, the people that run Chamberlain are "apple" people and therefore never looked outside of the apple-box when developing their product.  What it really means is to be able to securely change the "NO" to a "YES" they would have to re-engineer their cloud API to accept authenticated google voice commands as secured inputs (which they did for apple when they developed the software because they forgot that --particularly worldwide-- FAR more people own android devices than apple).  AND WHY hasn't that been done?  Typically in a corporate culture, the people that write that kind of software are hired as one-off contractors, ie: here is $35000, please deliver a cloud API that can do x, y, and z.  Once the job is done, they are no longer part of the company and have nothing to do with the API----unless, say, the company realizes how short-sighted they were and then wants the original programmer to go back and add functionality.  If you were that programmer, what do you suppose the fee for that contract would be?  Exactly, more than the company would pay---so now, I suspect they are stuck, they either have to find someone willing to work on a foreign-to-them API (which takes more time and therefore probably at least as much as the original development), or, fork over the money to the original contractor to fix the mess they asked for and make it into what I would like to believe the original contractor told them it should be to begin with (this happens a lot as well).

MyQ....any of that ringing a bell? sound like whats been happening the last year, I'm betting so---how long do you suppose you can carry this before people, maybe even 15 years from now, when confronted with a choice, will pick "any brand but yours" to avoid these types of headaches?

So, I'll ask again, any update on this functionality being enabled?
Photo of Leo

Leo

  • 2 Posts
  • 0 Reply Likes
Agree; now it appears to have been more than a year since the last community manager left an update on this process....As it happens I know more than my fair share about API's, integration, and how different softwares' "speak" to one another.  Would you like me to sum it up? Sure you wouldn't, so here we go:
MyQ "integrates" with Google using a slightly different model than devices like Phillips Hue bulbs, and Wemo devices (which is why they charge a yearly fee).  MyQ utilizes a cloud-based "middle man" that, in this case interprets the commands issued.  This is different as the other model simply passes a phrase or word on to the cloud directly which has an automated response based on whatever the phrase or word that is sent  happens to be.  Because of this, MyQ (ie: Chamberlain) is in complete control over what commands can be passed, how they are passed, and what "security" is utilized to pass them.
What does this all mean?  It means that more than likely  the software that runs on the cloud side absolutely has the the functionality to be able to OPEN the garage door, but that it is simply configured not to----by simply configured, I mean it is likely something as simple as an xml file the cloud parses that says something along the lines of <allow open  if not homekit=NO>.  Which, once you understand that is how these things work on the cloud level, tends to infuriate a person even more, as now they can see just how easy it would be to correct this oversight <allow open if not homekit=YES>.
Yes, that is a bit of an oversimplification if one is intending to bolster the security, and yes it is a bit of an oversimplification if, as I suspect, the people that run Chamberlain are "apple" people and therefore never looked outside of the apple-box when developing their product.  What it really means is to be able to securely change the "NO" to a "YES" they would have to re-engineer their cloud API to accept authenticated google voice commands as secured inputs (which they did for apple when they developed the software because they forgot that --particularly worldwide-- FAR more people own android devices than apple).  AND WHY hasn't that been done?  Typically in a corporate culture, the people that write that kind of software are hired as one-off contractors, ie: here is $35000, please deliver a cloud API that can do x, y, and z.  Once the job is done, they are no longer part of the company and have nothing to do with the API----unless, say, the company realizes how short-sighted they were and then wants the original programmer to go back and add functionality.  If you were that programmer, what do you suppose the fee for that contract would be?  Exactly, more than the company would pay---so now, I suspect they are stuck, they either have to find someone willing to work on a foreign-to-them API (which takes more time and therefore probably at least as much as the original development), or, fork over the money to the original contractor to fix the mess they asked for and make it into what I would like to believe the original contractor told them it should be to begin with (this happens a lot as well).

MyQ....any of that ringing a bell? sound like whats been happening the last year, I'm betting so---how long do you suppose you can carry this before people, maybe even 15 years from now, when confronted with a choice, will pick "any brand but yours" to avoid these types of headaches?

So, I'll ask again, any update on this functionality being enabled?