Nameless, I agree with several things you said except the last. “They don’t play nice with other companies”. To be more specific, “they don’t play nice with other companies who don’t work with them”. Their system still work with Alexa, it still works with Google Home, it still works with IFTTT. I believe it still works with other companies who have chosen to align themselves with the MyQ group. Vera depended on independent developers to make the connection and chose to directly align themselves with very few devices. Many of us hoped eZLO would change all that and expand the devices they supported natively. We are still waiting for that to happen. Without native support, independent developers will come and go and we, the users, will suffer the consequences.
I am not blaming eZLO for this one. I cannot find an official Alexa skill nor a Google integration that doesn’t require something like OpenHAB. Yes, they have IFTTT, but require a subscription.
I do feel we need more integrations like IFTTT, though.
I stand corrected. You are correct, there is no official Alexa skill and both IFTTT and Google Assistant require a monthly or annual fee. I believe the fee is a requirement from Chamberlain. Also, I was not blaming eZLO for this situation. This was a leftover from Vera being so dependent on outside developers. I believe as we move forward we will see more and more APPS stop working with our systems. I have been a fan of Vera for several years. I am just concerned about what lies ahead. I think this issue is just the beginning.
If I may chime in… Having experienced similar to various extent events (server outage, API changes, or bankruptcy) with:
Ecobee, Nest and Google, WeatherUnderground, Logitech Harmony, mios itself, lowe’s iris, plantlink, and I am sure I am missing some, the lesson to learn here is that we should not be relying on the cloud for anything close to be as critical as home control. I am actually advocating to not integrate IFTTT and any device which does not offer a local API. Logitech has turned back, SONOS and Philips Hue still offer it. Everything else I had which had no local API unless it is a device which is designed to go out of my home network, has been replaced by a local zwave or zigbee solution which ended up offering more control and automation options than its cloud equivalent. I too am not blaming eZLO on this one. I had considered the MyQ early on but found the solution not adequate and to some extent absurd. You are exposed to chasing your tail with this type of solution because, the cloud, will always be a security liability and will always require security upgrades and therefore changes to the API to patch the security weaknesses. The cloud has no place in critical home control. It is fun to turn a couple of light switches but anything beyond that is a recipe condemned for failure. I learned this the hard way and have gotten tired of chasing all these API changes.
I am new to all this, just a consumer, and feel caught in the middle.
Since I have a Liftmaster garage with MyQ, and since if I understand correctly there will not be a fix to the interface software, can someone explain how I add a ZWAVE device to my physical install that leaves everything that MyQ does intact, but add an ability to use my Vera to also monitor and control my garage door?
This link above may help. @Sorin suggested a couple of devices which could replace the MyQ. Not knowing your wiring and how your MyQ is setup makes it difficult for me to make further recommendations but these devices should be wired in series to the MyQ I believe.
Has anyone approached the previous developer with some kind of compensation? I know I’d be willing to chip in something worthwhile to get this fixed. I know we’re still relying on the cloud and Chamberlain could easily change it again, but all the other options aren’t really great, at least for me. It seems like there are many people who use this plugin and if we all put in a little bit, it might be enough for him to make whatever small change is necessary to get this to work again. Anyone else think this might be an idea?
The first step in fixing this is to figure out what changed and Since it isn’t documented anywhere, it will need to be reversed engineered/hacked somewhere. Not a sustainable solution.
For your specific needs, why aren’t any of the other solutions as good? To my MyQ was the worst possible one due to cost, reliability and capability. I have chamberlain GDOs and I found the zwave go control to be at least as good with the biggest downfall being the problem you are facing now.
I don’t have access to the code right now.
but if someone who does, can you check the following:
DEFAULT_USER_AGENT = “Chamberlain/3.73”
liftmaster authentication string: ‘NWknvuBd7LoFHfXmKNMBcgajXtZEgKUh4V7WNzMidrpUUluDpVYVZx+xT4PCM5Kx’
craftsman authentication string:
‘eU97d99kMG4t3STJZO/Mu2wt69yTQwM0WXZA5oZ74/ascQ2xQrLD/yjeVhEQccBZ’
the liftmaster and craftsman strings appear to have changed…
The authentication strings in the code are different from what you mentioned. I tried updating the code with the new strings but it still doesn’t work.
I’ve updated the following rows in L_MyQGateway.lua
Row 25 old:
USER_AGENT = “Mozilla/5.0 (Linux; Android 4.4; Nexus 4 Build/KRT16E) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/30.0.1599.105 Mobile Safari”,
Row 25 new:
USER_AGENT = “Chamberlain/3.73”,
Row 234 old:
APPID = “Vj8pQggXLhLy0WHahglCD4N1nAkkXQtGYpq2HrHD7H1nvmbT55KqtN6RSF4ILB/i”, – android Liftmaster appid - v3.73
Row 234 new:
APPID = “NWknvuBd7LoFHfXmKNMBcgajXtZEgKUh4V7WNzMidrpUUluDpVYVZx+xT4PCM5Kx”, – android Liftmaster appid - v3.73
Row 242 old:
APPID = “YmiMRRS1juXdSd0KWsuKtHmQvh5RftEp5iewHdCvsNB77FnQbY+vjCVn2nMdIeN8”, – android craftsman appid - v3.70.1
Row 242 new:
APPID = “eU97d99kMG4t3STJZO/Mu2wt69yTQwM0WXZA5oZ74/ascQ2xQrLD/yjeVhEQccBZ”, – android craftsman appid - v3.73
and then uploaded, restarted LUA, rebooted the controller, updated login credentials, still no auth or check past Jun 18th. Any other ideas?
I am attached the entirety of the old lua that worked up until mid-Jun, as well as my changed version since you said you didn’t have access to it. (Disclaimer, I’m not a developer).
L_MyQGateway.zip (43.9 KB)
Not the best solution, but MyQ is now running a free year of IFTTT and Google Assistant connections. I just signed up myself on both services.
I have the same issue… hoping someone figures this out.
I took a quick pass at incorporating the changes above as follows:
(base) [blacey@bbl ~/Projects/Vera/Vera-MyQGateway (new_api *)]$ git diff
diff --git a/L_MyQGateway.lua b/L_MyQGateway.lua
index ce19320..812cc15 100644
--- a/L_MyQGateway.lua
+++ b/L_MyQGateway.lua
@@ -1,4 +1,4 @@
-local version = "v1.60 10-Nov-2017" -- @CybrMage @macrho @djrobx @BOFH @kornev @JoeyD"
+local version = "v1.6.1 06-Jul-2019" -- @CybrMage @macrho @djrobx @BOFH @kornev @JoeyD"
local PLUGIN_CONFIG = {
WEB_MODE_DISABLED = false, -- debug option - disable web mode fallback - normally false
@@ -22,7 +22,7 @@ local PLUGIN_CONFIG = {
USER_DATA_URL = "",
APPID = "",
BRAND = "",
- USER_AGENT = "Mozilla/5.0 (Linux; Android 4.4; Nexus 4 Build/KRT16E) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/30.0.1599.105 Mobile Safari",
+ USER_AGENT = "Chamberlain/3.73",
NAME = "MyQGateway"
}
@@ -231,7 +231,7 @@ local BRANDING = {
BASE_URL = "https://myqexternal.myqdevice.com/"
},
["Liftmaster"] = {
- APPID = "Vj8pQggXLhLy0WHahglCD4N1nAkkXQtGYpq2HrHD7H1nvmbT55KqtN6RSF4ILB/i", -- android Liftmaster appid - v3.73
+ APPID = "NWknvuBd7LoFHfXmKNMBcgajXtZEgKUh4V7WNzMidrpUUluDpVYVZx+xT4PCM5Kx", -- android Liftmaster appid - v3.73
BASE_URL = "https://myqexternal.myqdevice.com/"
},
-- ["Merlin"] = {
@@ -239,7 +239,7 @@ local BRANDING = {
-- BASE_URL = "https://myqexternal.myqdevice.com/"
-- },
["Craftsman"] = {
- APPID = "YmiMRRS1juXdSd0KWsuKtHmQvh5RftEp5iewHdCvsNB77FnQbY+vjCVn2nMdIeN8", -- android craftsman appid - v3.70.1
+ APPID = "eU97d99kMG4t3STJZO/Mu2wt69yTQwM0WXZA5oZ74/ascQ2xQrLD/yjeVhEQccBZ", -- android craftsman appid - v3.73
BASE_URL = "https://myqexternal.myqdevice.com/"
}
}
(base) [blacey@bbl ~/Projects/Vera/Vera-MyQGateway (new_api *)]$
but it still fails with…
02 07/06/19 15:21:02.102 luup_log:106: (MyQGateway::MYQ_API::retrieveSecurityToken): POST request URL: [https://myqexternal.myqdevice.com/api/v4/User/Validate] Headers [{ ["Culture"] = en,["Content-Type"] = application/json; charset=utf-8,["Accept"] = */*,["BrandId"] = 2,["Host"] = myqexternal.myqdevice.com,["Content-Length"] = 55,["User-Agent"] = Chamberlain/3.73,["App-Version"] = 3.88.30470,["MyQApplicationId"] = NWknvuBd7LoFHfXmKNMBcgajXtZEgKUh4V7WNzMidrpUUluDpVYVZx+xT4PCM5Kx,["ApiVersion"] = 4.1,} ] Data [{"username":"********","password":"********"}] <0x75620520>
02 07/06/19 15:21:02.196 luup_log:106: (MyQGateway::MYQ_API::retrieveSecurityToken): received response: NIL <0x75620520>
01 07/06/19 15:21:02.197 luup_log:106: (MyQGateway::MYQ_API::retrieveSecurityToken): Unsuccessful at connecting with the authorization URL! <0x75620520>
01 07/06/19 15:21:02.197 luup_log:106: (MyQGateway::startupdeferred): INITIAL API LOGIN **FAILED** Attempting WEB MODE fallback <0x75620520>
01 07/06/19 15:21:02.197 LuaInterface::CallFunction_Timer-5 function startupDeferred failed [string "local version = "v1.6.1 06-Jul-2019" -- @Cy..."]:430: attempt to index field '?' (a nil value) <0x75620520>
I’m pretty time constrained these days but if you can point me to the source for this information I will double-check that the aforementioned changes are all that is needed.
A few weeks ago someone reported having problems with SiteSensor connecting to a particular HTTPS target. After some digging, I discovered that the version of LuaSec running on current firmware does not support SNI, and the connection was failing as a result–SSL negotiation failed and the request could not even be sent. LuaSec is the library underlying http.request+SSL/https in Lua. My workaround was to add a switch to make SiteSensor use curl as an alternative to http.request, and this worked handily.
When I last looked at the MyQ code, it used both curl and http.request. You might try replacing the request calls with command line curls to see if you get a successful connection to the Chamberlain server. I’m thinking it’s quite possible they didn’t change their API at all, just upgraded their server software and created a sudden SNI requirement. I’d try this myself, but I don’t use MyQ. You seem to have a live test case and perhaps willing hands.
Based on the discussions in the Homeseer forum, the MyQ API has not been changed. Chamberlain changed the TLS cipher suites to a higher set of algorithms that does not function properly on the current Luasec version. I think Richard is right on to give using curl a try.
@rigpapa, looks like your hunch may be correct. In sniffing a login session from my browser, it looks like they are using SNI.
Same here…
I found the strings in git repositories while in the office, which is why I said I didn’t have access to the code.
Looks like that may not have been the issue after all, though, based on other comments.
I’ll see if I have time to dink around and play with the idea of replacing http.request with curl calls.
one more thought, looking at the lua code…
The request is forced to use TLSV1, which was deprecated 06/30/2019.
response, status, header = https.request{
url = URL,
method = "GET",
headers = HEADERS,
verify = "none",
mode = "client",
protocol = "tlsv1",
options = "all",
redirect = false,
sink = ltn12.sink.table(user_response)
}
So I did a search “tlsv1” and replace to “tlsv1_2”
uploaded the new “L_MyQGateway.lua” file.
That’s all that’s needed. just update that string, upload the changed file, restart and done. 