[WITHDRAWN] MyQ LiftMaster/Chamberlain

This is a safety requirement of the UL 325 standard for garage door controllers operating in “unattended” mode–that is, where a person is presumed not to be visually watching the door operate. Linear,
Telgard, Nutone, and all other UL listed controllers also have the beep.

1 Like

ever since MyQ updated their’s backend, the beeping is back. You can always open up the MyQ panel and skewer the beeper.

You can always try to override and re-publish. By experience, it’s 50/50 that it won’t work. Make sure you go run through and update the settings so that it reinitiates the scheduling.

Concerns about the beeping should be directed towards Chamberlain or UL. Just remember the beeping is for the safety of a person in the garage, not one in an upstairs bedroom. In most UL standards, safety trumps convenience.

Well, if it is a safety requirement then my thought is UL will not change it because of one complaint which means if I want to get rid of it (no matter the reason) it will have to be on my device. I will make that decision myself based on my situation.


I’m sticking with your latest version for now… I’ve been using it for 11+ hours now and so far it hasn’t failed me. Server polling seems to be working, the event log entries show the door status is accurate and updating once every minute along with the occasional “poll” command. Also, all automated garage door activity is working – opening when I arrive, closing after I leave, alerting me when the door is open for a specified period of time, etc. I realize there are several variations of this MyQ app now but I’m not going to update the code unless your newest version suddenly stops working. Seriously, this is the most reliable I’ve had the MyQ app work in several weeks!

I recommend others try it out.

1 Like

I’ve also had smooth sailing for over 36 hours. The monitor job did have to restart the polling scheduler once or twice, but everything got going again like it’s supposed to. I think it’s a combination of the ST environment being more stable and finally finding a smooth set of code.

I made a tiny update today to my code to make the cron schedules run on odd seconds rather than always on “0” of every X minute. The idea is that most smartApps have probably been set by default to run on the 0 second, which means it’s probably the most crowded time of all to run something. It’s discussed more here: Scheduler and Polling quits after some minutes, hours, or days

Anyway, feel free to try that to further stabilize things. As long as you’re not on the V4 code, you won’t need to uninstall/reinstall since it’s such a small update. You will want to reinitialize though (just click through the app setup once to get it started with the new schedule interval)

Mine quit today at 12:04pm EST :frowning:

Btw - why with v4 of the code, do we have to uninstall each time?

Thanks! I will use your code revision, seems like a good improvement! Btw, everything is still working well after 36+ hours for me too.

Been wondering this myself. I’ve skimmed the code changes a bit and can’t easily tell what it is that makes it not play well with just re-initializing. My guess is that some of the data structure has changed (ex: “DeviceId” field changing to “MyQDeviceId”) which is requiring an uninstall to reconcile. @copyninja may have a better idea of the what’s causing it and if it’s possible to write it in such a way that you can switch between versions without uninstalling. I agree it’s a big pain to have to delete and recreate all the actions each time. Either way, I’m good to sit on non-V4 for now since it’s finally settled down so nicely.

Are you on the latest v4 or on @brbeaird’s code? I did a few updates to the code yesterday including the potential issue with polling on ST. So far it is running strong.

The v4 code is based on latest MyQ app on iPhones. Any MyQ update to the backend will not affect us anymore since the vast majority of iPhone and Android users are on v4.

While non-v4 still works, there’s no telling when they’ll remove those API’s. Also in the past, I’ve experienced inconsistencies with some of the fields from the response in non-v4 API.

I’m still working on updating the device types as well. It seems like MyQ has updated their behavior to disallow the door from stopping it remotely. Also, I’m enabling more options to ensure that reschedule gets kicked off by events like mode changes and allowing multiple contact sensors/multisensors to kick the refresh. So I’ll be making a few more commits tonight.

If you’re on v4 codes already, most likely you won’t need to reinstall. But if you’re still on my old version, you should be able to move to Brian’s version with fewer hiccups.

Latest codes are up. Just to describe the over engineering I have made to ensure that the polling will stay alive for the long run.

  1. Refresh job, which the interval is defined by the user in the SmartApp, fires twice (somehow a weird behavior I found). The first one will fire at a random number of seconds, and wont be fixed on 00 seconds on the minute. Second one will fire 30 seconds later. YMMV. The same Refresh job will check if Rescheduler job died, revive it.

  2. Rescheduler job runs every 30 minutes, checks if Refresh job is at least 5 minutes late. If it is, revive Refresh job

  3. Location Event (Mode changes, Sunrise & Sunset) which runs at least 2 times a day will check if both jobs above is dead. If they are dead, revive them

  4. Contact/Acceleration Event will do the same as no. 3.

Data refreshes if any of these happens. If any of these are not working for any reason, you can always go to the app > Next > Done and it will trigger an initialization again, and all of them will be back in the game.


P.S Sorry to say that you will most likely have to uninstall and reinstall again, since I introduced a new variable in the application state. If you have started using multisensor in my past v4 version, try removing them before installing this version. add it back after you install. If anything fails, you will need to uninstall everything, and readd back everything.

Ok, I just set this up again with @copyninjas latest code .
I am getting so confused with all of the changes between @brbeaird and @copyninja but I went through the fun of re-setting up the devices again with all my SmartApps. I use these doors in various smartapps (Sonos, SmartClicks Dashboard, ITFFF, Hello Home Actions, etc.), so it takes me awhile to redo it.

Perhaps I am not understanding the way GitHub works. When I went to @brbeaird’s repository his last update said it was 5 days ago but was = with @copyninja. However, upon going to the @copyninja’s repository, he did an update 4-5 hours ago.

I am trying to uninstall my current MyQ device and smartapp… I’ve done this before and never had a problem.

When trying to delete the device via the IDE I get this error:

“Child device with device network id 5cb7 not found”

When I try to delete the device via the iphone app I get this error:

“You are not authorized to perform the requested operation”

Any ideas on how to get this removed?

For context I am in a situation where my MyQ account with Chamberlain is locked. I’m waiting for their customer support to unlock my account. Could this be the cause of my not being able to delete/uninstall the devices? Thanks for any ideas.

Sorry about the confusion. Within any git repo, there can be branches. The main branch is typically “master.” This would be considered the “production” code. Once new development is considered stable, it is eventually promoted into master. The master of both of our repos is currently identical. If you click the branch drop-down on the git page on either of ours, it will show you the possible branches that are running. Just to summarize, there are basically 3 versions on MyQ at the moment:

1.) Master. The basic version that’s been essentially unchanged since April. Both copyninja’s and my master are the same. The only recent changes have been the two fixes I found after the Chamberlain update that prevented logging in and closing the door. https://github.com/copy-ninja/SmartThings_MyQ

2.) SchedulerFix. In this branch, I took the code from #1 above and simply added a second scheduled job to monitor the first. The only purpose of this is to try and stop the jobs from dying. This branch is only on my repo. It has proven to be very stable and effective at keeping the polling schedule alive, but in the long run, hopefully we’ll find something a little more elegant. If you want something stable now that doesn’t have a lot of changes, I’d suggest getting this. https://github.com/brbeaird/SmartThings_MyQ/tree/schedulerFix

3.) V4. This is copyninja’s active development and is only on his repo - It is based on the newest API from Chamberlain (version 4). He has also added quite a bit of creative engineering to try and resolve the dying scheduler issue as well. It has significant changes from Master at the moment and is pretty experimental - because of that, moving to it (or away from it) requires a complete uninstall/reinstall of the app. However, once it’s tested and stable, this will be the version of the future. I would suggest getting this if you’re willing to help out in testing it and doing frequent updates. Otherwise, it may be best to hold off for a bit. https://github.com/copy-ninja/SmartThings_MyQ/tree/v4

I’ve had an outdated copy of the V4 branch in my repo. I’ll either delete it or keep it updated with copyninja’s to keep things less confusing.

Never mind… I was able to get the devices removed through some gyrations in the IDE.

Thanks for the GitHub tutorial. I work for a software company and we are moving to GitHub enterprise, so it’s a good lesson for me!

So when you guys update code in the branches, I guess it’s easier to just change the line of code then replace all of the existing code? I noticed @copyninja just updated his v4 code about an hour ago.

My only suggestion would be to add some comments in your smartapp code for each version also.

As of now, I am running @copyninja’s v4 code all morning and so far so good!

You can always click on the commit log beside the file. I’ve named it “v4.02”. I try to maintain change logs as much as possible

1 Like

App has been running great for the past 1+ day. Nice job!

The question is, was it something we did or did ST quietly fix their scheduling issues?

My restarter didn’t have to fire all weekend. The original schedule has just run without any problems. Either way, I’m not complaining!


Perhaps a little of both? In any case I tip my hat to you @brbeaird and @copyninja for your recent code updates. I’m still using yours at the moment (“schedulerFix”) and it’s been rock solid for the past 2 days!