Yes - on android and iOS actually…that’s actually how I’ve been using it thus far…but like so many others, it was a key link missing in my openhab setup 
Alas - I guess that means I’m SOL…or a device hard reset… sigh lol
I am working now. I have three garages so that might have been the problem. It is very slow though so it may be the logging I turned on per your suggestion. I will turn that off and see if it speeds up.
Thanks.
Looks like Sears resells a version of the MyQ under the name of “Craftsman AssureLink Garage Door Opener Gateway”. Any change someone can extend this binding to support the AssureLink as well?
I addded Craftsman support in my personal github branch. I’ll try to build a JAR for you.
Did you push the commit to GitHub? I didn’t see it on your account.
I have a branch called “myq_lamp” that has all my new code changes. I compiled a JAR for you to try. In your config just add “myq:craftman=true”. If you have any issues please let me know. Link to JAR is below.
https://drive.google.com/open?id=0Bx6EpCMtJQHVRWZKSmV0NUtZU0E
Thanks,
Scott
Scott,
Thanks so much for creating an sharing this. It was exactly what I was looking for.
PS - I noticed in your repo that you were working on a Wink remote API binding. I’ve been working on a version for OH2 which does dynamic discovery and the like. It’s a bit unusual in that I’ve been writing it to use some general rules of thumb and an “override” file in lieu of the XML definition files for thing/channel/item structure and creation. My thought was that I wanted it to be flexible enough so that any new device that’s not too radically different from the base line V2 API could be supported without code changes. I pretty much learned Java, and ESH internals in the process so needless to say the code need refactoring and cleanup in the worst kind of way. That being said, I’ll be happy to share if you ever would like.
Thanks!
Alan
Hi @scooter_seh
Thanks for creating this binding. I would like to use it for in my setup. I’m trying OH2, and your binding is for OH1. Are you planning to migrate the binding to OH2 binding?
I’m learning how to create new binding in OH2 (I’m a newbie). And I’m thinking of how to create a binding for MyQ in OH2. But there’s a problem in discover the devices. I know I can use Discovery Service. And it seems natural that the devices associate with my MyQ account can be found as things via it. However, I’m not sure how to create configurations (e.g. username/password) for the Discovery Service. The documented configuration in Eclipse Smart Home seems to be for things only.
I started a OH2 binding for MyQ in my personal github but I haven’t worked on it much yet. The 1.x binding is compatible with OH2 and worked the last time I tried it.
@scooter_seh Thanks so much. I looked at your repo and realized there’s bridge-type that can be used in this case.
I follow the page https://github.com/openhab/openhab/wiki/Chamberlain-MyQ-Binding to setup items and sitemap in OH2. I can tell from the log that it’s updating the status successfully. But from the UI, I don’t see a thing for my device. Is there a way to show that in OH2?
openHAB 1.x bindings don’t deal with Things. You have to bind them to items in .items files as documented in their respective wiki pages.
Thanks for your reply @watou. I created a new topic and got it work. How to show the item for OH1 binding
There are somehow illegal characters in your openhab.cfg file. Open it with a text filed editor and remove the garbage characters, save, and restart openHAB.
I have 9 MyQ Items
1 Universal MyQ Gateway + GDO
4 Lamp modules
5 Switches
I’m using the 1.9.0 Snapshot Binding from the 1.9.0 Binding Package.
2016-12-29 20:45:12.803 [ERROR] [inding.myq.internal.MyqBinding] - Could not connect to MyQ service java.io.IOException: Null response from MyQ server at org.openhab.binding.myq.internal.MyqData.request(MyqData.java:208) ~[bundlefile:na] at org.openhab.binding.myq.internal.MyqData.getMyqData(MyqData.java:120) ~[bundlefile:na] at org.openhab.binding.myq.internal.MyqBinding.poll(MyqBinding.java:204) [bundlefile:na] at org.openhab.binding.myq.internal.MyqBinding.access$0(MyqBinding.java:196) [bundlefile:na] at org.openhab.binding.myq.internal.MyqBinding$1.run(MyqBinding.java:401) [bundlefile:na] at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [na:1.8.0_65] at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308) [na:1.8.0_65] at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180) [na:1.8.0_65] at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294) [na:1.8.0_65] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [na:1.8.0_65] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [na:1.8.0_65] at java.lang.Thread.run(Thread.java:745) [na:1.8.0_65]
I get this error pretty often. I find that if I disable most of the attributes it happens less. Is this something that can be fixed by adjusting the timeout or the refresh interval?
Any one have any clue why I periodically get Cannot connect to MyQ Service?
Am I hitting a limit on the API.
Is anyone else seeing this type of behaviour?
When I take a look at the code of the binding it looks like when the binding gets a command it enters in to a rapid poll rate. Which makes sense for a garage door openers (GDO) to get the open/close and intermediate states.
I think with multiple MyQ none-(GDO) items I’m maybe overwhelming the API with the rapid refresh and this also introduces some oddities in to the Bus.
I notice that when I’m using a switch for a scene or a rule that links many MyQ items that when for example Item myQ_light1 changes to ON sendcommand MyQ_light2 ON and another condition for an off condition. Light2 during the rapid refresh period will do on off on off cycle because the MyQ API reports the changing status of Light1 about 3 times a second. This also results in more commands being sent for light2 than desired and floods the bus. So far I’ve been using thread::sleep (5000) to ensure that I don’t send too many updates/commands in to the bus.
Does anyone notice this? Would disabling rapid refresh for non-GDO be a good change for the lamp portion of the plugin and let the bus post the updates?
Or am I completely off base?
``} else if (device instanceof LampDevice) {
-
LampDevice lampModule = (LampDevice) device; -
if (command.equals(OnOffType.ON)) { -
myqOnlineData.executeMyQCommand( -
lampModule.getDeviceId(), "desiredlightstate", -
1); -
**beginRapidPoll(true);** -
} else if (command.equals(OnOffType.OFF)) { -
myqOnlineData.executeMyQCommand( -
lampModule.getDeviceId(), "desiredlightstate", -
0); -
**beginRapidPoll(true);** -
} else { -
logger.warn("Unknown command {}", command);``
After you first post I thought the start rapid polling code might be the problem. I will change it and get you a jar to try soon.
Thanks,
Scott
@ scooter_seh
You’re fast.
I had built my own Jar to test my theory.
I was going to report back after I had confirmed it.
I had set the code to false for lamp modules and fixed some typos in the
MyQResponseCode.java
``` UNKNOWN(-1, “Unknow resonse”);``
The jar with the disabled rapid poll for lamp modules fixes the first error I saw and reported.
The response of lamp modules especially in groups is slightly faster and more robust as now it’s only reporting status on change and @ 1 per minute as per the configured refresh interval.
From my short test I think having rapid poll false for lamp modules is the way to go.
I have 11 MyQ items in total and with the official 1.9.0 SNAPSHOT binding anytime I was sending commands to myq group triggered by a myq status change would result in some disney’s haunted mansion craziness and slow response on my Rpi2 due to the bus getting flooded.