Crafting a letter to Chamberlain Group CEO for MyQ issues

Third party integrations
1

Hello community I’m writing a letter (email) to the CEO of Chamberlain Group. The holding company for MyQ products.

As you may know, in the past few months we’ve been experiencing total system failures.

We need to know what’s going on and if it’s planned on their part. This way, we can as a community scrap the brand and move on, or continue to find fixes and improve general reliability of the integration.

I’m not technical, but I (with help from ChatGPT) have put together a general summary based on comments and posts across the community.

I’m looking for community input so we can be as impactful as possible.

For context, no, I do not expect the CEO to write back to us. However, these companies more often than not have dedicated executive teams to field these types of issues and emails. This will escalate more effectively than say, going to their chat function or customer support.

Here’s what I have so far. Input is welcomed

Subject: Concerns Regarding MyQ API Integration

Dear [CEO’s Name],

I hope this message finds you well. I am writing to you as a representative of our community that has been actively integrating MyQ devices into our smart home systems using the MyQ API.

Our goal has been to provide a seamless and enhanced experience for MyQ device users, but recently, we’ve encountered significant challenges due to alterations in the MyQ API. This has caused disruptions in our systems, affecting the hundreds of thousands of users within our Home Assistant and general smart home communities, particularly in the United States.

What concerns us the most is the potential impact of these API changes on the continuity and reliability of our integrations. The MyQ API alterations seem to have limited the functionality we can offer, providing fewer features than the free version, and making it impossible for us to integrate the paid version features. We want to emphasize that these alterations do not have any positive impact on your subscription revenue. In fact, they risk frustrating your customer base and eroding trust in the MyQ ecosystem.

The reason for our concern is twofold, as highlighted by a member of our community:

  1. There is speculation that these API changes might be a strategic move to encourage users to switch to the paid service, effectively driving more customers to subscribe. While we understand the need for generating revenue, this approach might negatively impact the trust and satisfaction of existing users.

  2. The second and more concerning explanation is that these API changes are unintentional, resulting from continuous modifications to the API without a clear understanding of their downstream effects. This would not only disrupt our systems but also deter us from recommending MyQ to others in the future.

To better understand the situation, we kindly request clarity on the intent behind these API alterations. If they are purposefully designed, it would be beneficial for us to know to make informed decisions as a community. If these are accidental, it would be essential to establish better communication channels to avoid future disruptions and maintain the trust of your customer base.

We are ready to provide more technical details if necessary, but we believe addressing this matter promptly and transparently will benefit both our community and MyQ as a brand.

We look forward to your response and hope to find a solution that ensures the continued success and growth of the MyQ ecosystem while meeting the needs of your dedicated user community.

Thank you for your attention to this matter.

Sincerely,

[Your Name]
[Your Title]
[Your Contact Information]

2

I don’t think you’re going to get anywhere with this. It is noted and stated in multiple places that the API being used (HA, Homebridge, pymyq, the new Python-MyQ, etc) is an unofficial and unsupported API from Chamberlain which has been reverse engineered by the community from the MyQ official app. The API can change at any time without notice. Chamberlain/MyQ appears to be exercising their right and does not have to explain themselves or the changes. It is disappointing they are taking a rather unfriendly approach to 3rd party integrations. I feel your letter should focus more on the cooperation with 3rd parties and making the API documented and available, thus defining a clear path for 3rd party integrations. If Chamberlain says no, then that’s their prerogative. MyQ was fun while it lasted. You can always “vote with your dollar”.

1 Like
3

I’m afraid squirtbrnr is correct. Chamberlain can do whatever they want, including the ongoing cat and mouse game to block unsanctioned use of their API. The solution is to switch to local control avoiding the cloud altogether.

4

I appreciate your attempt @Harsh_Tone

Do it. You never know. Worst case, you are still at the same place where you are now.

A few notes regarding the mail contents. As an exec, this is way above my head. I care about customers who pay for our products. If that is stressed to me that a large pool of customers are want something, I might pay attention. Existing customers who can tell others how mad I am are also something that can make me react.

1 Like
5

There are no ‘downstream effects’ to understand for them. This is an internal API used by Chamberlain for their own products. It is not intended to be used by any third party and there is absolutely no obligation for them to maintain it for third parties who reverse engineered it, nor to ‘clarify’ anything to anyone at all. This kind of entitled behavior is not going to help at all. In fact, worst case, it could push them to pull a Mazda on the current integration.

If you really want them to open their API and document it (and that would be great), then you have to lay out the advantages this would afford them as a business, financially and for customer retention. Opening and publicly maintaining an API is a lot of work and costs money. There must be some form of ROI in it for them. If you can clearly show that, they may listen to you. This is not going to be easy at all.

The best approach, obviously, is to drop the cloud API altogether and go fully local.

1 Like
6

I like the sentiment, but have to agree with the folks pointing out that Chamberlain has no obligation to support the API for the public. I wouldn’t mind tossing them a buck-or-two if they supported it, but in the end I also hate relying on a cloud API for individual device brands. They only have incentive to get you to buy more of their product and get more deeply coupled to their eco-system. I don’t have to like it, but that is the business model.

ratgo is back-ordered, but I’m gonna buy a bunch of them and use on my 3 Chamberlain and one LiftMaster (3 different models, one of which is > 10 years old).

7

All, I’m fully aware that they don’t need to do anything for us with regards to their private API.

That said, I see no harm in asking if there’s a way we can work together, or tell me they want us to piss off and then we can all rule this integration out.

Currently the myQ integration is in use off 5% of HA overalls. There’s another 95% of users who’d potentially buy their hardware.

There’s potential for something to happen if not just keep a small community of users happy. If it’s not possible then I’d like to hear that conclusively from them as opposed to people telling me it’s their api they do what they want shrug

8

Whine?

Hyperbole?

This approach would more likely end any access to the API.

You need to SELL an open and supported API to the executive. Without hyperbole, indicate how an open and supported API would increase their potential customer base. When I have to replace anything in my home, the first thing I do is research if there is an integration for the same type of device. The one with an integration or supported API is usually the one I buy.

9

Agreed that there is no harm…did not mean to imply “No, don’t do it!” :slight_smile:

Who knows, maybe they’ll find a compromise that will permit a public API for a few bucks, or realize the interested community is bigger than they knew about and might want to provide it for free in the hopes we would buy more of their product because of the increased compatibility.

10

Asking, sure. Making entitled demands like in your original draft, oh yes this can do harm. I can very well picture how the discussion between CEO (should he even get that mail, they’d probably be sorted out before reaching him) and PM would go:

“So who are these guys again and how much do they pay us in license fees to make demands like that ?”

“What do you mean nothing and they’re using our services without authorization ?”

“Could you run that by legal and get their feedback on this issue please”

Making unreasonable demands isn’t going to get you or the community anywhere. It can even harm us all. Be polite, don’t make demands you have no business making and lay out your case in a friendly and well founded way. Use real numbers (not made up user counts) and projections and return of investment calculations.

11

feel free to drop your edits

12

Scrap it all. Writing to the CEO with stuff like that in a harsh tone (hah !) is not the way to go about this.

Social media. Grassroots. Go over engineers, let them bring up the potential benefits of going open internally within their corporate hierarchy. Refer to other companies that went that way or are starting to go that way (like for example Victron Energy or Tesla API and emphasize the positive effects on community, customers and the company.

1 Like
13

I’ve scrapped the idea all together but agree with your proposal