@digitaldan I merged Dan’s improvements and created a new jar. New features/improvements include:
https://drive.google.com/file/d/0Bx6EpCMtJQHVYjUwWXpPZVdGbTg/view?usp=sharing
Thanks @scooter_seh for starting this binding, did not realize there was a forum topic on it. It’s been really stable for me so far with the above changes. We probably need 2 more things before we could submit it for an official review and get it into 1.8. First is a good ReadMe file in the root of the project that describes the binding and gives some examples. Second is we need an easy way for users to look up their MyQDeviceID or an alternative binding strategy . Not sure if this has been discussed yet. One way I can think of would be to use the “desc” of the chamberlain device, users set this up when they register their device on the mychamberlain.com site, for example mine is called “Home”. I’m not sure if this is a unique value, but we could require that if a user has more than one that they need to have separate names for their doors. The second way would be to use an ordinal value, so for most users they would use “0” to represent the first door in their account, “1” for the second one and so on. I’m assuming that the order in which the devices are listed in the API won’t change. In openHAB 2 this won’t be an issue as we can auto discover stuff.
Now that I’m typing this I like the ordinal approach, it would be the easiest for end users I think.
Thoughts?
And ignore my readme comment did not realize you already had a wiki page!
I have an updated version (jar) with instructions here:
Please note that you now use {myq=“0”} in your items file for the first garage door in your account, {myq=“1”} for the second one and so on. See the above link for rollershutter examples as well. If you have more than one garage door device I would love to get your feedback here.
Thanks Dan
@digitaldan, I can confirm that the new version works well, with both of my garage door openers!
The only thing I’m missing from the Chamberlain app is the time since opening/closing, and the alerts that come up when the door has been left open for more than x minutes. Both of these can easily be done with rules, but if it’s something that can be pulled from the json, it would be a nice-to-have, as well.
@scooter_seh my code should be up to date in the myq branch in my repo which is what my pull request is based on, ignore the release tag in the link I posted for the jar, my branch is a few more commits ahead which should be reflected in the PR. If its not let me know. It was a very small change.
@bartus Thanks for the feedback good to know more than one device works 
The time open does not seem to be in the device JSON we get back. That’s not to say we can’t get it, but it’s not in the api calls we are using right now.
I’ve been waiting and hoping for this binding to come along for a long time, but unfortunately can not get it to work. I think the issue is that I do not have an actually MyQ Garage Door Opener. But rather I have the “Chamberlain MyQ Universal” This is the smaller MyQ Add on that is connected to my separate chamberlain garage door opener.
Can anyone confirm if the binding works with the ‘Universal’?
I have updated my OpenHab to 1.8, included the bindings and added to the config file. But I’m told in my logs that in can not find myq device 0.
I would prefer to not have to actually install a new garage door opener and to get the MqQ Universal working with it.
Thanks
PT
I do not know if anyone has tried that device yet. I personally have a MyQ Gateway and I know others have Wifi Openers. If you start the binding in debug you should see the raw JSON data from the MyQ API. If you could PM the JSON to me I can take a look and figure out what is not working with the binding.
I’ll be happy to send over the raw JSON data. But please pardon my ignorance… where do I find that?
I stared OpenHab in debug mode so see additional information in the log. Is that the information you need?
Should be a line in the log file that starts with “Received MyQ JSON:” It normally is a very long line with lots of data.
I wanted to give a big thanks out to Scott for helping me get the MYQ Universal working with OpenHab. After some other strange (my own) issues in having to also reset the unit and add a new door sensor battery, thing have been working well.
I am still getting an ‘Unknown’ door state when the door is open, bu t only on the String Item in my setup which seems strange. I’ll be checking for any typo later today. But trying to play with OH2 first for a bit. 
Unfortunately there is a small error in the code here that prevents it from logging the number representing the door state. @scooter_seh would it be possible for you to fix that? But if you can see the raw JSON data in the log (turn on DEBUG or TRACE logging for the binding), that would help the binding developers figure out how to map the door state correctly for your model.
@watou I made a pull request with a couple fixes. @ptmuldoon The JSON you send me had a “doorstate” of “2” which means the garage door was closed. If you could open your garage door then start openHAB in debug and send me the JSON I can take a look at it. The JAR I sent you already has the fixes so you should be able to see the doorstate in the debug traces. There are 5 current states in the binding. If you can send me the JSON in the different states that help a lot.
“Open”, 1
“Closed”, 2
“Partially Open/Closed”,3
“Opening”, 4
“Closing”, 5
Thanks,
Scott
quick question, why change the code from trace to debug? For functions that generate a lot of noise like this trace is the more appropriate loge level. Users then only need to add the following line to their logback.xml or logback_debug.xml to start seeing the added logging, they don’t even have to restart openhab.
<logger name="org.openhab.binding.myq" level="TRACE" />
I just changed the code to make it more consistence with the JSON and HTTP logging. If you think its better as trace level than I can change it back.
Scott.
I can try and run in debug mode and get that JSON info all later this evening for you. Just having ‘fun’ in the office for a few more hours today.
I believe I changed it to trace logging b/c during opening and closing events it generated a lot of redundant noise that really was not useful. My thoughts would be to not merge this upstream and if we need those logging statements in the future to have a user modify the logback file (that’s what its there for)… Many of us (including me) run in debug mode all the time, so noisy bindings can be a pain. I think its fine to test those changes now of course. Thanks!
Right now the other logging is debug but your logic makes more sence so I will change it to trace level.