Hmm, lemme take a look. Ive done a few attempts to make it switch branches via the CLI and then update, but still shows 3.0.1 =/
I just upgraded to 3.1.0M3 so I could configure myQ.
My jar is: org.openhab.binding.myq-3.1.0.M3.jar
MyQ binding is is bound to my account and showing ONLINE.
The MyQ switch shows UNKNOWN and is not controlling the switch to open/close the door.
The status also shows UNKNOWN.
MyQ model is MYQ-G0301-E. Is this supported? If so, what could I be missing in the configuration?
Thanks!
I was just about to follow up with my post here too, got upgraded and finally was able to add the binding. My account shows online, but the door and lights show unknown after adding the serial numbers, and the channels show null for any data. Did i miss something?
My account shows online,
but the door and lights show unknown after adding the serial numbers,
and the channels show null for any data
I have the same issue.
openHAB 3.1.0.M4
Can you be more specific please? How have you configured the binding? How have you added the account thing? How have you added the door and light things? Are you using thing files, or the UI. Can you post configuration examples, log files, screen shots, anything ?
After adding a MyQ account, the binding should automatically add doors and lights to the inbox , did this happen?
I got it working.
How have you added the account thing? How have you added the door and light things?
I manually added the garage door. From your post I deleted then restarted openhab with the myq account still enabled. I went to add the thing from the binding page and then it came online. Thank you.
I have updated to openHAB 3.1, but still cannot get this binding to work. The bridge thing will not connect to the myq servers. This is what is in the logs:
2021-07-16 18:56:26.569 [TRACE] [q.internal.handler.MyQAccountHandler] - Sending POST to https://api.myqdevice.com/api/v5/Login
2021-07-16 18:56:26.788 [TRACE] [q.internal.handler.MyQAccountHandler] - Account Response - status: 0 content: null
I have tried clearing cache, recreating the bridge thing, and updating java certificates with no change. As indicated in my January 2 post above, a packet capture shows a âCertificate Unknownâ error. Does anyone have an idea on what I could try next?
You wrote that you updated the ca-certs. Did you check if the java cacerts keystore is updated as well ?
Thanks for the suggestion. I have regenerated the java cacerts keystore, restarted openhab, but still no dice. The are 95 entries in the keystore, and it is in JKS format. The keystore.type.compat option in java.security is set to true, so it should load it fine. I have tried passing extra options to openhab including:
-Djavax.net.ssl.trustStoreType=JKS
-Djavax.net.ssl.trustStore=/etc/ssl/certs/java/cacertsây
-Djavax.net.ssl.trustStorePassword=XXXXXXXXXXXXXX
and still no changes in the MyQ binding behavior. This is with openjdk-11 on Ubuntu 20.04. Somewhere, there is a parameter configured wrong, but I donât know what else to try.
The official answer would be: use zulu 11.
You can try to set -Djavax.net.debug=all or -Djavax.net.debug=ssl
The first one should provide lots of debug information. The second one is related to ssl âonlyâ. It might give some more details about the root cause e.g. which certificate is checked.
You wrote you did a network trace. Doesnât it show which cert cannot be checked/validated ?
With that info you should be able to check if that cert is missing.
Wolfgang_S, thank you for the recommendations. I finally got it working. The short answer is that Zulu 11 was the fix. I looked back at my packet trace and saw that the myq SSL certificate signed by GoDaddy wasnât being accepted. I checked my java keystore and the GoDaddy root certificate was in there. After numerous unsuccessful configuration changes, I came across a thread that mentioned potential keystore abnormalities when multiple versions of openjdk are installed. In my case, I had both openjdk-8 and openjdk-11 installed (I need 8 for unifi and some other legacy applications, unfortunately). I purged openjdk-11 and installed Zulu 11 and the binding immediately started working.
I am currently on openHAB 3.1.0.M1 and have had the MyQ binding working properly without a hitch for about a year until yesterday. I only have 1 garage door opener attached to it. All of the sudden, the MyQ Bridge started throwing the following error:
COMMUNICATION_ERROR
Invalid Response { âSecurityTokenâ: ââ, âReturnCodeâ: â0â, âErrorMessageâ: âplease contact customer care, supportID: 14941968167609047574â, âCorrelationIdâ: ââ }
I have removed the thing and installed several times without any success. Have restarted Openhab several times as well. Same error every time.
Any ideas?
Thanks
I am also having this problem exactly.
I apologize if I am late to the party but I am running openHAB 2.5 and am having an issue with the binding. See logs below.
Binding version:
2.5.0.202005061425 â openHAB Add-ons :: Bundles :: ChamberlainMyQ Binding
Restarting the binding did not work. Did Chamberlain change something?
2021-08-26 09:06:12.944 [ERROR] [handler.ChamberlainMyQGatewayHandler] - An exception occurred while executing a request to the Gateway: 'null'
==> /var/log/openhab2/events.log <==
==> /var/log/openhab2/openhab.log <==
2021-08-26 09:06:23.144 [ERROR] [nal.common.AbstractInvocationHandler] - An error occurred while calling method 'ThingHandler.handleCommand()' on 'org.openhab.binding.chamberlainmyq.handler.ChamberlainMyQDoorOpenerHandler@164d9e0': null
java.lang.NullPointerException: null
at org.openhab.binding.chamberlainmyq.handler.ChamberlainMyQGatewayHandler.findAccount(ChamberlainMyQGatewayHandler.java:204) ~[?:?]
at org.openhab.binding.chamberlainmyq.handler.ChamberlainMyQGatewayHandler.getAccountID(ChamberlainMyQGatewayHandler.java:179) ~[?:?]
at org.openhab.binding.chamberlainmyq.handler.ChamberlainMyQGatewayHandler.executeMyQCommand(ChamberlainMyQGatewayHandler.java:270) ~[?:?]
at org.openhab.binding.chamberlainmyq.handler.ChamberlainMyQDoorOpenerHandler.setDoorState(ChamberlainMyQDoorOpenerHandler.java:87) ~[?:?]
at org.openhab.binding.chamberlainmyq.handler.ChamberlainMyQDoorOpenerHandler.handleCommand(ChamberlainMyQDoorOpenerHandler.java:74) ~[?:?]
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:1.8.0_252]
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[?:1.8.0_252]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:1.8.0_252]
at java.lang.reflect.Method.invoke(Method.java:498) ~[?:1.8.0_252]
at org.eclipse.smarthome.core.internal.common.AbstractInvocationHandler.invokeDirect(AbstractInvocationHandler.java:152) [bundleFile:?]
at org.eclipse.smarthome.core.internal.common.InvocationHandlerSync.invoke(InvocationHandlerSync.java:59) [bundleFile:?]
at com.sun.proxy.$Proxy563.handleCommand(Unknown Source) [?:?]
at org.eclipse.smarthome.core.thing.internal.profiles.ProfileCallbackImpl.handleCommand(ProfileCallbackImpl.java:74) [bundleFile:?]
at org.eclipse.smarthome.core.thing.internal.profiles.SystemDefaultProfile.onCommandFromItem(SystemDefaultProfile.java:48) [bundleFile:?]
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:1.8.0_252]
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[?:1.8.0_252]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:1.8.0_252]
at java.lang.reflect.Method.invoke(Method.java:498) ~[?:1.8.0_252]
at org.eclipse.smarthome.core.internal.common.AbstractInvocationHandler.invokeDirect(AbstractInvocationHandler.java:152) [bundleFile:?]
at org.eclipse.smarthome.core.internal.common.Invocation.call(Invocation.java:52) [bundleFile:?]
at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:1.8.0_252]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:1.8.0_252]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:1.8.0_252]
at java.lang.Thread.run(Thread.java:748) [?:1.8.0_252]
version 2.5x binding is also having this issue. Something must of changed at their API level.
Best, Jay
same problem here. It started just after going from 3.1.0 to 3.2.0 so I assumed it was my system (as I hadnât seen any reports) and did all the usual jiggling (clean cache, restart, downgrade, remove thing, remove binding, etc.). All to no availâŠ
I am running openHAB 3.1 and it worked this morning for me.
I checked again and am still continuing to receive the same error. Iâm located in the US. I know that Europe uses a different API I believe.
I live in the US.
Back in February Chamberlain did start using a new API v6 that uses OAUTH. The 3.1 binding uses the v5.1 API still. The homebridge guys have already reverse engineered the v6 API but it would take some work to add it to openHAB. The v5.1 will probably continue to work for a while but it could be shut down at any moment. Not trying to scare people, this is just the reality of the cat and mouse game we play.