Network/server error logging into MyQ service

[drprm1]

Awesome

Edited November 5, 2023 by drprm1

[Xathros]

Well, thanks to the DST kerfuffle today, I had to restart my systems. I have lost access to all 3 of my My-Q doors.  Just ordered the YoLink Garage Door stuff.  I'm already using YoLink for motion and temp sensing and am quite happy with the performance and stability of their devices.  Can't say I'm going to miss Chamberlain, My-Q and their issues.

I'll keep the My-Q node server installed for now in case Goose and the others can get it working again.

-Xathros

 

[bcdavis75]

Uhg.  I rebooted and I'm now in the same boat as you all.  @Goose66 do we know if the node server will work with if one is subscribed to the MyQ service (meaning if we pay MyQ their subscription fee?).  I was thinking of doing that anyway becasue my Tesla can use it.  If that solved the problem I might by the bullet... but I don't want to pay them and then find out it won't work for the node server.

[toddhutch]

I had been grandfathered in from lift master to access to the service.  When they first said payment required to access the garages features remotely, the marketing on the packaging stated it was included.  This was more than 10 years ago.  I have a login to their service, but at least for me I don’t think the devices show up there anymore.

 

 But I have the same question, I’d be willing to pay for access until there is another way without it directly via their/my local hardware.  This has motivated me to try harder to sniff the network.  Now I have two projects to do the same thing for, this and the Hayward OmniLogic pool controller.

 

i suspect if I speak to the CTO about their decision, he will have a list of reasons why they don’t give local access for home automation.  Having a solid suggested method for that discussion would be useful.  Any solid recommendations?

Edited November 6, 2023 by toddhutch

[Goose66]

This effort to block unauthorized access is only a year or less after they rolled out the public API to their "trusted partners." I suspect that none of the technical reasons the CTO would give you for blocking unauthorized access would be valid, and that the real reason is they want to make 3rd-party access exclusive to their partners. This leads me to believe that being a "trusted partner" comes with a financial cost.

Now, I can't see any way that this could represent a significant amount of revenue to Chamberlain. It just doesn't make sense that HA integrators would pay enough money to Chamberlain for access that it would even pay for the efforts to block unauthorized access. If anything, you would think the result would be that Chamberlain GDOs (their primary and significant source of revenue) would just be less attractive to some purchasers, even if only to the "small percentage of users" that's mentioned in the Chamberlain letter.

In my 20+ years of experience with helping companies license their IP and create new revenue streams, the ones that have tried to monetize their non-strategic IP portfolios are rarely successful. The likes of IBM, AT&T, Microsoft, and Intellectual Ventures aside, for most companies it really comes down to staying in your lane and just staying out front of your competitors in your primary market(s). So my questions for the CTO (which I am sure he wouldn't answer) are 1) what are the real reasons and concerns for blocking third-party access, and will he give us the opportunity to address and mitigate them, and 2) why not respond to Michel's requests to be a "trusted partner," even if just to say "f' off." Seems to me all they have to lose is an increase in product sales, even if it is marginally small and insignificant.

EDIT: Also, a lot if not most people end up moving and inheriting whatever GDOs the builder originally installed in their home. If Chamberlain wants to open up a new revenue stream, I think a $75 gateway that allows "trusted partner" HA integrators to access their GDOs through the public API would be a much better revenue generator than a pay-to-play partner program, and would be much more inline with their primary market as a hardware OEM then that of some kind of SaS provider.

Edited November 6, 2023 by Goose66

[jkosharek]

9 minutes ago, Goose66 said:

This effort to block unauthorized access is only a year or less after they rolled out the public API to their "trusted partners." I suspect that none of the technical reasons the CTO would give you for blocking unauthorized access would be valid, and that the real reason is they want to make 3rd-party access exclusive to their partners. This leads me to believe that being a "trusted partner" comes with a financial cost.

Now, I can't see any way that this could represent a significant amount of revenue to Chamberlain. It just doesn't make sense that HA integrators would pay enough money to Chamberlain for access that it would even pay for the efforts to block unauthorized access. If anything, you would think the result would be that Chamberlain GDOs (their primary and significant source of revenue) would just be less attractive to some purchasers, even if only to the "small percentage of users" that's mentioned in the Chamberlain letter.

In my 20+ years of experience with helping companies license their IP and create new revenue streams, the ones that have tried to monetize their non-strategic IP portfolios are rarely successful. The likes of IBM, AT&T, Microsoft, and Intellectual Ventures aside, for most companies it really comes down to staying in your lane and just staying out front of your competitors in your primary market(s). So my questions for the CTO (which I am sure he wouldn't answer) are 1) what are the real reasons and concerns for blocking third-party access, and will he give us the opportunity to address and mitigate them, and 2) why not respond to Michel's requests to be a "trusted partner," even if just to say "f' off." Seems to me all they have to lose is an increase in product sales, even if it is marginally small and insignificant.

EDIT: Also, a lot if not most people end up moving and inheriting whatever GDOs the builder originally installed in their home. If Chamberlain wants to open up a new revenue stream, I think a $75 gateway that allows "trusted partner" HA integrators to access their GDOs through the public API would be a much better revenue generator than a pay-to-play partner program, and would be much more inline with their primary market as a hardware OEM then that of some kind of SaS provider.

I only went with the Chamberlain/MyQ hardware option for my opener for the ability to integrate with it. I think I will hack some other IoX locally connected I/O to it and call it a day. 

[Goose66]

2 minutes ago, jkosharek said:

I only went with the Chamberlain/MyQ hardware option for my opener for the ability to integrate with it. I think I will hack some other IoX locally connected I/O to it and call it a day. 

The ratgdo looks the most promising. I would love to get one and write a node server for it, but I have Genie GDOs with the MyQ Universal Controller and Door Sensors, so I don't really have a testbed for it.

I have a friend with MyQ GDOs that's buying one, but he's ditching UD to go with HomeAssistant. Maybe I can convince him to keep his Polisy running long enough to test the ratgdo node server.

[Xathros]

4 minutes ago, jkosharek said:

I only went with the Chamberlain/MyQ hardware option for my opener for the ability to integrate with it. I think I will hack some other IoX locally connected I/O to it and call it a day. 

Same here.  In fact, I've been struggling to get all 3 of my doors working with the My-Q stuff since one is a commercial opener and some of the My-Q gateway/hub devices don't work with the commercial openers.  Finally got it all working and now they block my access with anything other than their crappy app.  The only real feature I use in their app is a scheduled close at night if I forgot and left a door open.  I can code that on the ISY so no loss there.

I'm installing the YoLink stuff and will end up with better functionality on all three doors for less than the price of one My-Q gateway. And no more disco party flashing lights when I close my shop door from the house!

-Xathros

[jkosharek]

4 minutes ago, Goose66 said:

The ratgdo looks the most promising. I would love to get one and write a node server for it, but I have Genie GDOs with the MyQ Universal Controller and Door Sensors, so I don't really have a testbed for it.

I have a friend with MyQ GDOs that's buying one, but he's ditching UD to go with HomeAssistant. Maybe I can convince him to keep his Polisy running long enough to test the ratgdo node server.

Looks like the ratgdo v2.5 is on backorder. So the ratgdo v2.5 would connect to a MyQ opener that doesn't work with dry contacts (Chamberlan 8500W) and control it and read the sensors? And this would be another Node server, would that be a locally run connection from the ratgdo v2.5 to the node or cloud?

[Goose66]

Local. The ratgdo uses (among other options) MQTT. There is an MQTT broker on the Polisy/eISY that you would connect it to, and the node server would use the same MQTT broker to control and receive status updates from the ratgdo. Updates would be near realtime (unlike the polling of MyQ) and could be used to control lights and such, and probably more appropriately reflect "opening" and "closing" statuses and report obstructions.

But yes, on backorder. Just ordered one and my friend did too (we are together on vacation at the moment).

Edited November 6, 2023 by Goose66

[jkosharek]

7 minutes ago, Goose66 said:

Local. The ratgdo uses (among other options) MQTT. There is an MQTT broker on the Polisy/eISY that you would connect it to, and the node server would use the same MQTT broker to control and receive status updates from the ratgdo. Updates would be near realtime (unlike the polling of MyQ) and could be used to control lights and such, and probably more appropriately reflect "opening" and "closing" statuses and report obstructions.

But yes, on backorder. Just ordered one and my friend did too (we are together on vacation at the moment).

Yeah, that does sound promising. I also just ordered one, I could assist in testing if needed. 

[toddhutch]

Thank you for sharing that @Goose66 I like the concept of the ratgdo, with 3 doors, so that would be under $130.  Looks like a project for the winter.  I'll have to look more closely at this, as my doors have the battery backup option.  We lose power up in the hill country where we live, and it's nice to be able to open the doors even when the power is out.  The home automation is all on UPS's so depending on the complications it may or may not be viable to leverage the battery which is 12 volt. 

I like this because it was what I was expecting liftmaster was going to do with their product.

I won't need my wireless door sensors anymore, as this look like the open and close detection is real time, and can be queried.  👍👍👍

Do you think we should wait a while to see if they respond to Michael, or the request for partner access?  Or has that ship sailed?

[jkosharek]

4 minutes ago, toddhutch said:

Thank you for sharing that @Goose66 I like the concept of the ratgdo, with 3 doors, so that would be under $130.  Looks like a project for the winter.  I'll have to look more closely at this, as my doors have the battery backup option.  We lose power up in the hill country where we live, and it's nice to be able to open the doors even when the power is out.  The home automation is all on UPS's so depending on the complications it may or may not be viable to leverage the battery which is 12 volt. 

I like this because it was what I was expecting liftmaster was going to do with their product.

I won't need my wireless door sensors anymore, as this look like the open and close detection is real time, and can be queried.  👍👍👍

Do you think we should wait a while to see if they respond to Michael, or the request for partner access?  Or has that ship sailed?

I plan to use this device to leverage the battery backup in the opener. 

https://www.amazon.com/Converter-DROK-Regulator-Inverter-Transformer/dp/B01NALDSJ0/ref=sr_1_4

[toddhutch]

@jkosharek Thank you for sharing.  So now under $160, and better functionality, that pushes me over the edge.  Ordering 3 of the ratgdo's.  @Goose66 I was going to offer to send you one, but I see you've bought one as well. 👍👍

I really appreciate the work you put into this over the YEARS Goose, and I'll PM you about your day job.   We develop software products, and are in the middle of setting up a partnership on a scale I'm looking for some wisdom on. 👍

Edited November 6, 2023 by toddhutch

[jkosharek]

42 minutes ago, Xathros said:

Same here.  In fact, I've been struggling to get all 3 of my doors working with the My-Q stuff since one is a commercial opener and some of the My-Q gateway/hub devices don't work with the commercial openers.  Finally got it all working and now they block my access with anything other than their crappy app.  The only real feature I use in their app is a scheduled close at night if I forgot and left a door open.  I can code that on the ISY so no loss there.

I'm installing the YoLink stuff and will end up with better functionality on all three doors for less than the price of one My-Q gateway. And no more disco party flashing lights when I close my shop door from the house!

-Xathros

I bought some YoLink stuff to play with, my first impressions is, it will work and is very responsive. But if the ratgdo v2.5 gives me access to control or at least view other properties of the opener system, like the motion, light, and other sensors that will be where I end up. YoLink is interesting but they are restricting API calls and putting devices offline. I am running into that with some testing I am doing with the Speaker Hub and open/close sensor I put in the mailbox.

So, I am not sure I want to hitch my wagon to another system out of my control. 

[sjenkins]

1 hour ago, Goose66 said:

Local. The ratgdo uses (among other options) MQTT. There is an MQTT broker on the Polisy/eISY that you would connect it to, and the node server would use the same MQTT broker to control and receive status updates from the ratgdo. Updates would be near realtime (unlike the polling of MyQ) and could be used to control lights and such, and probably more appropriately reflect "opening" and "closing" statuses and report obstructions.

But yes, on backorder. Just ordered one and my friend did too (we are together on vacation at the moment).

Ordered one a little over a week ago. Over the weekend I moved my MQTT from a pi over to my eisy. I have used the MQTT “plugin” quite a bit over the last few years, adding some devices to it. Would be easy to add a special ratdgo device as well. So just staring at my mailbox now as no tracking on the ratdgo site. lol. 

[SHM]

On 11/2/2023 at 6:53 AM, Goose66 said:

There’s been some changes to another project (not pymyq) that seem to be working, although the developer has shutdown posts from users to the issue in the GitHub repository. I am going to implement his changes this weekend and see if I can restart mine.

Longer term, I am implementing some local solution as well (maybe ratgdo device), and if a node server is required I will make it free to all MyQ owners (or everyone if it’s easier).

But ultimately I don’t’ want to give up on Chamberlain and MyQ, because there is a whole batch of Polisy/eISY users out there that are DIY enough to own one but not DIY enough to be wiring some 3rd party device into their garage door opener. We don’t want to forget about those folks!

I sent for the ratdgo device but the setup seems daunting.  I have 4 lift masters (3 8550W and 1 commercial Logic 5.0 so will try to set rated up on 1 to see how it works.   Trying to figure out the wiring and MQTT but it is not intuitive.  Count me in on testing.

[Goose66]

if I can make a ratgdo node server that basic mirrors the current MyQ node server profile (interface), it should be easy enough just to plug-in to your current programs and scenes and such. 

[jkosharek]

26 minutes ago, Goose66 said:

if I can make a ratgdo node server that basic mirrors the current MyQ node server profile (interface), it should be easy enough just to plug-in to your current programs and scenes and such. 

I didn't have light or motion in the MyQ node, which I believe was a limitation of the API. I would love to see control or at least status of the light, motion, lock, and obstruction sensors.

[Goose66]

I don't see motion as a state (unless you mean door motion). I see availability state: Online and Offline (MQTT LWT), door state: Open, Close, Opening, Closing; obstruction state: Obstructed and Clear; light state: On and Off; lockout state: Locked and Unlocked; door command: Open and Close; light command: On and Off; and lockout command: Lock and Unlock.

Another thing to note here is, while Chamberlain may not like having this third-party device being able to control the door locally, it is doing so using PWM over the control line and emulating one of their wall control keypads, so there's no way they can push out new firmware to block access.

Edited November 6, 2023 by Goose66

[jkosharek]

1 hour ago, Goose66 said:

I don't see motion as a state (unless you mean door motion). I see availability state: Online and Offline (MQTT LWT), door state: Open, Close, Opening, Closing; obstruction state: Obstructed and Clear; light state: On and Off; lockout state: Locked and Unlocked; door command: Open and Close; light command: On and Off; and lockout command: Lock and Unlock.

My light has a motion sensor on it, but doesn't look like it's in the list you showed. I suppose if the Node Light state could be a controller in my garage light scene, that would work.  

Edited November 6, 2023 by jkosharek

[dbwarner5]

4 hours ago, Goose66 said:

Local. The ratgdo uses (among other options) MQTT. There is an MQTT broker on the Polisy/eISY that you would connect it to, and the node server would use the same MQTT broker to control and receive status updates from the ratgdo. Updates would be near realtime (unlike the polling of MyQ) and could be used to control lights and such, and probably more appropriately reflect "opening" and "closing" statuses and report obstructions.

But yes, on backorder. Just ordered one and my friend did too (we are together on vacation at the moment).

So how does the Polisy actually communicate to the Ratdgo?  via LAN wifi?  Just trying to understand if I installed two in a remote pole barn, how the "link" would work. I have wifi there but too far for zwave etc.

thanks.

[jkosharek]

8 minutes ago, dbwarner5 said:

So how does the Polisy actually communicate to the Ratdgo?  via LAN wifi?  Just trying to understand if I installed two in a remote pole barn, how the "link" would work. I have wifi there but too far for zwave etc.

thanks.

ratgdo device connects to wifi and the node server would connect to it's IP

[Goose66]

2 hours ago, jkosharek said:

ratgdo device connects to wifi and the node server would connect to it's IP

The ratgdo does connect to Wifi, but it is actually the ratgdo that connects to the Polisy's or eISY's MQTT broker. So as long as there is TCP/IP connectivity between the ratgdo and the Polisy, it would work (even if not on the same LAN segment).

You configure the IP address or .local name of the Polisy/eISY into the ratgdo. The node server simply connects to the MQTT broker on localhost. The node server would probably have the ability to connect to some external MQTT broker, however, for advanced configurations, just like my Tasmota node server does.

Edited November 6, 2023 by Goose66

[EWhite]

the more i see posted on this ratgdo the more im liking it...love the idea of getting away from the "cloud" and having local control.

What is the time frame on the backorder for these?