search

node-alarm-dot-com / homebridge-node-alarm-dot-com

Alarm.com plugin for Homebridge using Node.js
MIT License
58 stars 23 forks source link

Error on Post: ECONNRESET #63

Closed joewilliamsca closed 3 years ago

joewilliamsca commented 3 years ago

Creating a bug ticket for an error that started to appear in my log file a couple days ago.

sounds like there are a couple others running into the same error.

Using Node 14.16.0 with the Homebridge UI on a Raspberry Pi 4

Error: POST https://www.alarm.com/web/Default.aspx failed: request to https://www.alarm.com/web/Default.aspx failed, reason: read ECONNRESET at C:\Users\Administrator\AppData\Roaming\npm\node_modules\homebridge-node-alarm-dot-com\node_modules\node-alarm-dot-com\dist\index.js:83:19 at runMicrotasks () at processTicksAndRejections (internal/process/task_queues.js:97:5)

happyzorro commented 3 years ago

I am getting similar errors that started to pop up a few days ago. Nothing at all has changed in my alarm configuration and we have not added any new accessories or sensors.

Error: POST https://www.alarm.com/web/Default.aspx failed: request to https://www.alarm.com/web/Default.aspx failed, reason: read ECONNRESET at C:\Users\Administrator\AppData\Roaming\npm\node_modules\homebridge-node-alarm-dot-com\node_modules\node-alarm-dot-com\dist\index.js:83:19 at runMicrotasks () at processTicksAndRejections (internal/process/task_queues.js:97:5)

Stugatza commented 3 years ago

same here

happyzorro commented 3 years ago

Just a quick update that the errors have stopped for me since around midnight last night. Nothing changed on my configuration, plugins, or sensors. Hopefully whatever caused this has been resolved on Alarm.com's side.

chase9 commented 3 years ago

I'm glad to hear they've gone away for you, happyzorro, but it appears others are still having this issue. Could anyone affected please let me know:

joewilliamsca commented 3 years ago

Hi @chase9

Im still running into the issue.

screenshot_08

The provider is ADT

Im using the Onzu UI on a Raspberry PI running Buster. On the latest version of homebridge (1.3.4) using Node (14.16.0). I don't have any child bridges set up with Homebridge. This config I've had for a while. The only other things that my RPI are running outside of home bridge is Mosquitto and a Wireguard VPN

Not using MFA with Alarm.com (ADT)

Let me know if you need anything further. -Joe

chase9 commented 3 years ago

Thanks for the information @joewilliamsca . FYI, looks like you left an email in that screenshot. Not sure if you would prefer to censor that.

joewilliamsca commented 3 years ago

Thanks for the information @joewilliamsca . FYI, looks like you left an email in that screenshot. Not sure if you would prefer to censor that.

Thanks Chase for catching that. I have updated the screenshot :)

kaganae commented 3 years ago

I am also having this issue:

OS | Raspbian GNU/Linux Stretch (9) Homebridge: v1.3.4 Node.js Version v14.16.0 Npm Version v6.14.11 homebridge-node-alarm-dot-com v1.7.2-beta.4 (I updated to the beta to see if it resolved the issue - it did not)

Not using MFA either.

[3/21/2021, 10:47:34 AM] [Security System] Error: GET https://www.alarm.com/web/api/devices/sensors?ids%5B%5D=96622429-28&ids%5B%5D=96622429-27&ids%5B%5D=96622429-30&ids%5B%5D=96622429-29&ids%5B%5D=96622429-3&ids%5B%5D=96622429-4&ids%5B%5D=96622429-2&ids%5B%5D=96622429-26&ids%5B%5D=96622429-6&ids%5B%5D=96622429-25&ids%5B%5D=96622429-9&ids%5B%5D=96622429-10&ids%5B%5D=96622429-16&ids%5B%5D=96622429-31&ids%5B%5D=96622429-7&ids%5B%5D=96622429-8&ids%5B%5D=96622429-95&ids%5B%5D=96622429-1&ids%5B%5D=96622429-17&ids%5B%5D=96622429-18&ids%5B%5D=96622429-11&ids%5B%5D=96622429-5&ids%5B%5D=96622429-96&ids%5B%5D=96622429-12&ids%5B%5D=96622429-13&ids%5B%5D=96622429-14&ids%5B%5D=96622429-15&ids%5B%5D=96622429-99 failed: request to https://www.alarm.com/web/api/devices/sensors?ids%5B%5D=96622429-28&ids%5B%5D=96622429-27&ids%5B%5D=96622429-30&ids%5B%5D=96622429-29&ids%5B%5D=96622429-3&ids%5B%5D=96622429-4&ids%5B%5D=96622429-2&ids%5B%5D=96622429-26&ids%5B%5D=96622429-6&ids%5B%5D=96622429-25&ids%5B%5D=96622429-9&ids%5B%5D=96622429-10&ids%5B%5D=96622429-16&ids%5B%5D=96622429-31&ids%5B%5D=96622429-7&ids%5B%5D=96622429-8&ids%5B%5D=96622429-95&ids%5B%5D=96622429-1&ids%5B%5D=96622429-17&ids%5B%5D=96622429-18&ids%5B%5D=96622429-11&ids%5B%5D=96622429-5&ids%5B%5D=96622429-96&ids%5B%5D=96622429-12&ids%5B%5D=96622429-13&ids%5B%5D=96622429-14&ids%5B%5D=96622429-15&ids%5B%5D=96622429-99 failed, reason: read ECONNRESET at /usr/lib/node_modules/homebridge-node-alarm-dot-com/node_modules/node-alarm-dot-com/dist/index.js:470:15 at runMicrotasks () at processTicksAndRejections (internal/process/task_queues.js:93:5) at async Promise.all (index 1) at async Promise.all (index 0) [3/21/2021, 10:52:39 AM] [Security System] Error: GET https://www.alarm.com/web/api/systems/systems/6660189 failed: request to https://www.alarm.com/web/api/systems/systems/6660189 failed, reason: read ETIMEDOUT at /usr/lib/node_modules/homebridge-node-alarm-dot-com/node_modules/node-alarm-dot-com/dist/index.js:470:15 at runMicrotasks () at processTicksAndRejections (internal/process/task_queues.js:93:5) at async Promise.all (index 0) [3/21/2021, 10:53:19 AM] [Security System] Logging into Alarm.com as xxxxx@gmail.com [3/21/2021, 10:53:35 AM] [Security System] Error: POST https://www.alarm.com/web/Default.aspx failed: request to https://www.alarm.com/web/Default.aspx failed, reason: read ECONNRESET at /usr/lib/node_modules/homebridge-node-alarm-dot-com/node_modules/node-alarm-dot-com/dist/index.js:85:19 at runMicrotasks () at processTicksAndRejections (internal/process/task_queues.js:93:5)

majorgearhead commented 3 years ago

Add me to the list of people experiencing this.

Provider: CPI Security (Alarm.com) w/o MFA OS: Raspbian 10 (buster) Homebridge: v1.3.4 Node.js Version: v14.15.0 Npm Version: v6.14.8 Homebridge Node Alarm Dot Com: v1.7.1

[21/03/2021, 18:52:47] [Security System] Error: GET https://www.alarm.com/web/api/devices/locks/?ids%5B%5D=97124791-1200&ids%5B%5D=97124791-1201&ids%5B%5D=97124791-1202 failed: request to https://www.alarm.com/web/api/devices/locks/?ids%5B%5D=97124791-1200&ids%5B%5D=97124791-1201&ids%5B%5D=97124791-1202 failed, reason: read ECONNRESET
    at /usr/local/lib/node_modules/homebridge-node-alarm-dot-com/node_modules/node-alarm-dot-com/dist/index.js:466:15
    at runMicrotasks (<anonymous>)
    at processTicksAndRejections (internal/process/task_queues.js:93:5)
    at async Promise.all (index 2)
    at async Promise.all (index 0)
happyzorro commented 3 years ago

Well after a couple of days of no issues, the ECONNRESET error has popped up again for me.

Provider: ADT / Telus 2 factor authentication: No OS: windows 7 Homebridge: v1.1.7 Homebridge Node Alarm Dot Com: v1.7.1

Error: GET https://www.alarm.com/web/api/devices/sensors?ids%5B%5D=96239599-14&ids%5B%5D=96239599-7&ids%5B%5D=96239599-17&ids%5B%5D=96239599-9&ids%5B%5D=96239599-16&ids%5B%5D=96239599-15&ids%5B%5D=96239599-6&ids%5B%5D=96239599-2&ids%5B%5D=96239599-8&ids%5B%5D=96239599-5&ids%5B%5D=96239599-4&ids%5B%5D=96239599-13&ids%5B%5D=96239599-11&ids%5B%5D=96239599-12&ids%5B%5D=96239599-99&ids%5B%5D=96239599-1&ids%5B%5D=96239599-95&ids%5B%5D=96239599-10&ids%5B%5D=96239599-3 failed: request to https://www.alarm.com/web/api/devices/sensors?ids%5B%5D=96239599-14&ids%5B%5D=96239599-7&ids%5B%5D=96239599-17&ids%5B%5D=96239599-9&ids%5B%5D=96239599-16&ids%5B%5D=96239599-15&ids%5B%5D=96239599-6&ids%5B%5D=96239599-2&ids%5B%5D=96239599-8&ids%5B%5D=96239599-5&ids%5B%5D=96239599-4&ids%5B%5D=96239599-13&ids%5B%5D=96239599-11&ids%5B%5D=96239599-12&ids%5B%5D=96239599-99&ids%5B%5D=96239599-1&ids%5B%5D=96239599-95&ids%5B%5D=96239599-10&ids%5B%5D=96239599-3 failed, reason: read ECONNRESET at C:\Users\Administrator\AppData\Roaming\npm\node_modules\homebridge-node-alarm-dot-com\node_modules\node-alarm-dot-com\dist\index.js:466:15 at runMicrotasks () at processTicksAndRejections (internal/process/task_queues.js:97:5) at async Promise.all (index 1)

anthonyb82 commented 3 years ago

Just wanted to add that I am seeing this in my logs, but it’s sporadic. I will have this error for a short period of time, the everything logs in properly, and then several hours later it comes back for a few minutes. I am running the beta with 2FA. The behavior of the error lends me to believe it’s on alarm.com’s end and not the plugin

potrudeau commented 3 years ago

Same problem here

Provider: Securiteck (Alarm.com) w/o MFA OS: Alpine Linux (3.12.3) Homebridge: v1.3.4 Node.js Version: v14.15.4 Npm Version: v6.14.19 Homebridge Node Alarm Dot Com: v1.7.1

Error: GET https://www.alarm.com/web/api/devices/partitions/?ids%5B%5D=91396224-127 failed: request to https://www.alarm.com/web/api/devices/partitions/?ids%5B%5D=91396224-127 failed, reason: read ECONNRESET
    at /homebridge/node_modules/homebridge-node-alarm-dot-com/node_modules/node-alarm-dot-com/dist/index.js:470:15
    at runMicrotasks (<anonymous>)
    at processTicksAndRejections (internal/process/task_queues.js:93:5)
    at async Promise.all (index 0)
    at async Promise.all (index 0)
techfreakdad commented 3 years ago

Here too. Also linked to ticket #66

Error: GET https://www.alarm.com/web/api/devices/locks/?ids%5B%5D=96741200-1202 failed: request to https://www.alarm.com/web/api/devices/locks/?ids%5B%5D=96741200-1202 failed, reason: read ECONNRESET at /usr/local/lib/node_modules/homebridge-node-alarm-dot-com/node_modules/node-alarm-dot-com/dist/index.js:470:15 at runMicrotasks () at processTicksAndRejections (internal/process/task_queues.js:93:5) at async Promise.all (index 2) at async Promise.all (index 0)

chase9 commented 3 years ago

I'm stumped on how this doesn't seem to discriminate on provider, plugin version, or MFA usage. It's also odd that at least some people still have working setups while receiving this error. I'm wondering if alarm.com has changed their API limits and are starting so soft block some of our connections?

FWIW, here's my (working) refresh time: Timeout to Re-Authenticate Session: 10 Device Polling Interval: 60

Anyone have more ideas on how to troubleshoot this?

happyzorro commented 3 years ago

@chase9 I'm not sure if this helps, but since around 8:30 PM last night, the ECONNRESET errors completely stopped for me again. The only thing I did around that time is re-started my whole network and as such, my external IP address changed. FYI My HomeBridge server's internal IP did NOT change.

Next time the error pops up again I will re-start my network and let you know if the errors stop again.

techfreakdad commented 3 years ago

@chase9 I'm not sure if this helps, but since around 8:30 PM last night, the ECONNRESET errors completely stopped for me again. The only thing I did around that time is re-started my whole network and as such, my external IP address changed. FYI My HomeBridge server's internal IP did NOT change.

Next time the error pops up again I will re-start my network and let you know if the errors stop again.

So to clarify, you just restarted your router?

happyzorro commented 3 years ago

@chase9 I'm not sure if this helps, but since around 8:30 PM last night, the ECONNRESET errors completely stopped for me again. The only thing I did around that time is re-started my whole network and as such, my external IP address changed. FYI My HomeBridge server's internal IP did NOT change. Next time the error pops up again I will re-start my network and let you know if the errors stop again.

So to clarify, you just restarted your router?

Yes, I restarted my router and all the Mesh points. My ISP assigns dynamic IP's with a very short lease, so almost every time I restart my router I get assigned a new external IP address. If you plan to test this, check your external IP address before and after to make sure it's different

happyzorro commented 3 years ago

Just a quick update. It's been three days since my previous update and so far no ECONNRESET errors for me. I should note that about a week ago I added the following two lines to my configuration (as per @chase9 recommendations above) which at the time, didn't make any difference, but after refreshing my IP I haven't had any errors. Not sure if this made a difference or not.

Timeout to Re-Authenticate Session: 10 Device Polling Interval: 60

Screenshot 2021-04-02 225818

happyzorro commented 3 years ago

sadly, ECONNRESET error is back. I have re-started my network again, but no luck.

alw101 commented 3 years ago

Just wanted to add that I'm also having this issue, though it seems to just not work entirely after the sensors were added initially (and those initial states at setup appear to be preserved).

Provider: ADT/Telus OS: MacOs 11.2.3 Homebridge: v1.3.4 Node.js Version: v14.16.1 Npm Version: v6.14.12 Homebridge Node Alarm Dot Com: v1.7.1

Also, as a side note, alarm.com has been sending notifications that the account was successfully logged in every 10 minutes, so I don't think it's a login issue (also, if anyone knows how to disable these, it would be appreciated!)

dkolb commented 3 years ago

Some notes to help the next person:

I did some research. Some requests get through while others are held an excessively long time before the remote end closes the TCP connection without sending any data. The behavior seems randomish, though all requests seem to work timely when navigating the site in the browser.

It seems to be almost random though. Changing the User Agent to a recent Chrome string doesn't seem to help. At one point, I started getting ECONNRESET errors at the post to /web/Default.aspx when I forced node-alarm-dot-com to log me in every time it tried to do anything instead of reusing the previous auth data. I'm not sure what else can be said but it's definitely made the plugin unusable at the moment. Not that that's your fault!

That said, my browser doesn't have the same issue when browsing the site. Even if I'm browsing at the same time my script that just keeps calling getCurrentState() is brute forcing and failing more than half it's requests!

Speaking of, I've found brute force retries to be somewhat successful with requests going through on the third or fourth try most often. I was letting the server on the far end close the connection though, so requests could take up to 20 or 30 seconds to finally get forced through (counting logins which would fail several times also).

As the browser doesn't have this issue either something changed with the authentication data (making it an issue for node-alarm-dot-com/node-alarm-dot-com) or something is wrong between node-fetch and Microsoft IIS (which is what their servers claim to be). I've heard of various socket issues when running Node.js on IIS, but never talking to IIS.

chase9 commented 3 years ago

I just wanted to pop in and thank you all for your investigative work. I've been very busy personally so I'm sorry I haven't been more active here, but the project isn't abandoned. I've also started to get the ECONNECT errors (although my whole setup is working fine) so hopefully I can troubleshoot properly once I have more time.

JCallender73 commented 3 years ago

I am having the same issue. 2FA is disabled on ADT command website but when I try and login at alarm.com I get a message that says I must setup 2FA before I can continue. Could it be an issue that ADT is requiring 2FA when logging into Alarm.com?

ADT Security Customers:

To increase account security and prevent unauthorized access to your system, Two-Factor Authentication should be enabled for all account logins. It is only required when you first log in from a new device.

For questions or concerns, contact us at 800-238-2727.

Logs: 4/20/2021, 8:19:51 PM [ADT Command] UNHANDLED ERROR: Error: POST https://www.alarm.com/web/Default.aspx failed: request to https://www.alarm.com/web/Default.aspx failed, reason: read ECONNRESET at /home/hoobs/.hoobs/node_modules/node-alarm-dot-com/dist/index.js:83:19 at processTicksAndRejections (internal/process/task_queues.js:93:5) 4/20/2021, 8:20:33 PM [ADT Command] Logging into Alarm.com as Johnathan.Callender@icloud.com 4/20/2021, 8:20:34 PM [ADT Command] Error: No afg cookie: ASP.NET_SessionId=5svqi4zrkp2zkgkaepgwmtfo; cookieTest=1; twoFactorAuthenticationId=3EDE1EB24946950A5456CDF1AD85CB8D55FB632FF337F6FA68047EF64E0454F0; IsFromNewSite=1; fromASP=; IsFromSeamlessLogin=; login=; ST=; SeamlessLoginEnabled=; loggedInAsSubscriber=1; BIGipServer~AlarmApplication~Alarm_WEBADC_Alarm_HTTPS=!Sd15yNgGgaWte+3NzUFX+zqT5KjmGBe8Qu5XxMVITCObbT1w7CfHDdKqMWegGiIxd7HCbU8E2P2gsXo= at /home/hoobs/.hoobs/node_modules/node-alarm-dot-com/dist/index.js:91:23 at processTicksAndRejections (internal/process/task_queues.js:93:5) 4/20/2021, 8:21:33 PM [ADT Command] Logging into Alarm.com as Johnathan.Callender@icloud.com 4/20/2021, 8:21:34 PM [ADT Command] Error: No afg cookie: ASP.NET_SessionId=momdvc5bhguzqlu2hlncxjsy; cookieTest=1; twoFactorAuthenticationId=054C6BE172B761B8683C7171FD0712DC7690C80A72566003319080CA444F8699; IsFromNewSite=1; fromASP=; IsFromSeamlessLogin=; login=; ST=; SeamlessLoginEnabled=; loggedInAsSubscriber=1; BIGipServer~AlarmApplication~Alarm_WEBADC_Alarm_HTTPS=!hfxP5CuqTMebThnNzUFX+zqT5KjmGEqRGBLPQ97SOa3nqq//YZMmqnhgrFApL6BntC76WLY3fx+7S8Q= at /home/hoobs/.hoobs/node_modules/node-alarm-dot-com/dist/index.js:91:23 at processTicksAndRejections (internal/process/task_queues.js:93:5) 4/20/2021, 8:22:33 PM [ADT Command] Logging into Alarm.com as Johnathan.Callender@icloud.com 4/20/2021, 8:22:49 PM [ADT Command] Error: POST https://www.alarm.com/web/Default.aspx failed: request to https://www.alarm.com/web/Default.aspx failed, reason: read ECONNRESET at /home/hoobs/.hoobs/node_modules/node-alarm-dot-com/dist/index.js:83:19 at processTicksAndRejections (internal/process/task_queues.js:93:5) 4/20/2021, 8:23:33 PM [ADT Command] Logging into Alarm.com as Johnathan.Callender@icloud.com 4/20/2021, 8:23:49 PM [ADT Command] Error: POST https://www.alarm.com/web/Default.aspx failed: request to https://www.alarm.com/web/Default.aspx failed, reason: read ECONNRESET at /home/hoobs/.hoobs/node_modules/node-alarm-dot-com/dist/index.js:83:19 at processTicksAndRejections (internal/process/task_queues.js:93:5) 4/20/2021, 8:24:33 PM [ADT Command] Logging into Alarm.com as Johnathan.Callender@icloud.com 4/20/2021, 8:24:50 PM [ADT Command] Error: POST https://www.alarm.com/web/Default.aspx failed: request to https://www.alarm.com/web/Default.aspx failed, reason: read ECONNRESET at /home/hoobs/.hoobs/node_modules/node-alarm-dot-com/dist/index.js:83:19 at processTicksAndRejections (internal/process/task_queues.js:93:5) 4/20/2021, 8:25:33 PM [ADT Command] Logging into Alarm.com as Johnathan.Callender@icloud.com 4/20/2021, 8:26:33 PM [ADT Command] Logging into Alarm.com as Johnathan.Callender@icloud.com 4/20/2021, 8:26:34 PM [ADT Command] Error: No afg cookie: ASP.NET_SessionId=zq5yvzcnxee2yyzkh2133kq0; cookieTest=1; twoFactorAuthenticationId=916B1AF7B29AFD31C413C94E1C574704D41424831F41AC60EE053775CB4B9DDC; IsFromNewSite=1; fromASP=; IsFromSeamlessLogin=; login=; ST=; SeamlessLoginEnabled=; loggedInAsSubscriber=1; BIGipServer~AlarmApplication~Alarm_WEBADC_Alarm_HTTPS=!KqjeuEvt9nNLUWvNzUFX+zqT5KjmGHDcxU4HZVZszwdwGf6cnEizG4YuUMyyXsSj1FEmZF/azdiHaeE= at /home/hoobs/.hoobs/node_modules/node-alarm-dot-com/dist/index.js:91:23 at processTicksAndRejections (internal/process/task_queues.js:93:5) 4/20/2021, 8:27:33 PM [ADT Command] Logging into Alarm.com as Johnathan.Callender@icloud.com 4/20/2021, 8:27:34 PM [ADT Command] Error: No afg cookie: ASP.NET_SessionId=dnhjs3um2k1w0nl1t01ltket; cookieTest=1; twoFactorAuthenticationId=53767CE55A78E31A1980CC761C2FDFF085FD77725E1D5EEA38F226AC15429CD7; IsFromNewSite=1; fromASP=; IsFromSeamlessLogin=; login=; ST=; SeamlessLoginEnabled=; loggedInAsSubscriber=1; BIGipServer~AlarmApplication~Alarm_WEBADC_Alarm_HTTPS=!bkaKAAAr7EBYGc/NzUFX+zqT5KjmGBFlsyLoumtJyIHtjg2maZ2GFj7Y2tBibiow02eLjS+badgkHoI= at /home/hoobs/.hoobs/node_modules/node-alarm-dot-com/dist/index.js:91:23 at processTicksAndRejections (internal/process/task_queues.js:93:5) 4/20/2021, 8:28:33 PM [ADT Command] Logging into Alarm.com as Johnathan.Callender@icloud.com 4/20/2021, 8:28:34 PM [ADT Command] Error: No afg cookie: ASP.NET_SessionId=gptvrxzpjfmli01eiei4j2vb; cookieTest=1; twoFactorAuthenticationId=9D5BCE92057F60BE687F4638D768F64E5E0615541FF5FBCB30BB794B1D353F40; IsFromNewSite=1; fromASP=; IsFromSeamlessLogin=; login=; ST=; SeamlessLoginEnabled=; loggedInAsSubscriber=1; BIGipServer~AlarmApplication~Alarm_WEBADC_Alarm_HTTPS=!aBs6vEkTCVzg9oLNzUFX+zqT5KjmGJexmbk06upRbrXXX/4s3ec8ZjYK09p/TucqukbaxThKICyTYUo= at /home/hoobs/.hoobs/node_modules/node-alarm-dot-com/dist/index.js:91:23 at processTicksAndRejections (internal/process/task_queues.js:93:5) 4/20/2021, 8:29:33 PM [ADT Command] Logging into Alarm.com as Johnathan.Callender@icloud.com 4/20/2021, 8:29:49 PM [ADT Command] Error: GET https://www.alarm.com/login failed: GET https://www.alarm.com/login failed: request to https://www.alarm.com/login failed, reason: read ECONNRESET at /home/hoobs/.hoobs/node_modules/node-alarm-dot-com/dist/index.js:55:15 at processTicksAndRejections (internal/process/task_queues.js:93:5) 4/20/2021, 8:30:33 PM [ADT Command] Logging into Alarm.com as Johnathan.Callender@icloud.com 4/20/2021, 8:30:34 PM [ADT Command] Error: No afg cookie: ASP.NET_SessionId=ykl5lkg1x4eaz1h3j2skfdcc; cookieTest=1; twoFactorAuthenticationId=2B9D731E34C793733FBC957F4C8276AA8EB7CE0F8AE369D5E84A15D1B256EBA4; IsFromNewSite=1; fromASP=; IsFromSeamlessLogin=; login=; ST=; SeamlessLoginEnabled=; loggedInAsSubscriber=1; BIGipServer~AlarmApplication~Alarm_WEBADC_Alarm_HTTPS=!0iq+uzqD7OqgilrNzUFX+zqT5KjmGEBNfEP5oyGzzukBzEE0/nc3t+wioVuyv6kDfaPpu1pn3HbM+jk= at /home/hoobs/.hoobs/node_modules/node-alarm-dot-com/dist/index.js:91:23 at processTicksAndRejections (internal/process/task_queues.js:93:5)

Sinandgrin commented 3 years ago

I am having the same issue. 2FA is disabled on ADT command website but when I try and login at alarm.com I get a message that says I must setup 2FA before I can continue. Could it be an issue that ADT is requiring 2FA when logging into Alarm.com?

ADT Security Customers:

To increase account security and prevent unauthorized access to your system, Two-Factor Authentication should be enabled for all account logins. It is only required when you first log in from a new device.

For questions or concerns, contact us at 800-238-2727.

...

I think this is what is going on. I noticed that starting this week, that when I try to open my Brinks iPhone app, that it asks me every time to enable Two-factor authentication. I have hit SKIP each time, log in to the app and arm/disarm my system there but it always appears. This morning I tried enabling it and seeing if I could then disable it and get that prompt to go away. I was not successful, it continues to show now that I have disabled 2FA.

Is there anyway we can get handling for 2FA/MFA built into this plugin? Seems like companies are not giving us a choice any longer. In the meantime, I was at least able to build a workaround using Siri shortcuts that the native Brinks app supports, so I can trigger alarm states from HomeKit scenes that way.

chase9 commented 3 years ago

@Sinandgrin This issue is not related to ECONNECT as far as I can tell. There is MFA support in the beta branch, but I'm able to recreate this issue with and without MFA enabled.

@dkolb I'm banging my head here trying to figure this out. What worries me is the idea that perhaps alarm.com found a way to identify and block our connections, but I don't really have a reason to believe this is the case. At any rate, I'll keep looking.

chase9 commented 3 years ago

I got a connection reset when trying to establish an SSL connection from my REST client (Insomnia) to alarm.com. Here's the log for others reference:

* Preparing request to https://www.alarm.com/web/Default.aspx
* Current time is 2021-04-25T21:50:11.339Z
* Using libcurl/7.73.0 OpenSSL/1.1.1j zlib/1.2.11 brotli/1.0.9 zstd/1.4.9 libidn2/2.1.1 libssh2/1.9.0 nghttp2/1.41.0
* Using default HTTP version
* Disable timeout
* Enable automatic URL encoding
* Disable SSL validation
* Enable cookie sending with jar of 3 cookies
* Too old connection (131 seconds), disconnect it
* Connection 0 seems to be dead!
* Closing connection 0
* Hostname in DNS cache was stale, zapped
*   Trying 192.155.71.71:443...
* Connected to www.alarm.com (192.155.71.71) port 443 (#1)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*  CAfile: /var/folders/k2/8fm0pjzx2639pmcwmb_9hc9r0000gn/T/insomnia_2021.2.2/ca-certs.pem
*  CApath: none
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* OpenSSL SSL_connect: Connection reset by peer in connection to www.alarm.com:443 
* Closing connection 1

Not sure why this is happening yet.

happyzorro commented 3 years ago

Hi @chase9 not sure if this helps but last week I set up a new Wifi mesh system and had to completely reset my network and haven't had any ECCON errors since then. This is the second time that re-setting my network cleared the error for me. I would suspect that the error will come back at some point just like it did last time. I think you may be right that Alarm.com found a way to identify and block our connections which explains why re-setting things appear to temporarily fix the problem.

ngori commented 3 years ago

@chase9 What about adding a bit of randomness to the polling interval? I was wondering if the regular cadence of polling could possibly be what is causing the errors. Detecting a poll every 60 seconds would be relatively straight forward. Perhaps coincidentally I use a 120 second polling interval and don't experience the ECONNRESET errors but I also do not have 2FA/MFA enabled nor does my provider require it

dkolb commented 3 years ago

Hi @chase9 not sure if this helps but last week I set up a new Wifi mesh system and had to completely reset my network and haven't had any ECCON errors since then. This is the second time that re-setting my network cleared the error for me. I would suspect that the error will come back at some point just like it did last time. I think you may be right that Alarm.com found a way to identify and block our connections which explains why re-setting things appear to temporarily fix the problem.

If you can confirm you got a new externally facing IP address from your provider, I may believe it. Resetting doesn't help me, but also Comcast likes to hand me the same IP address for a year at a time no matter how I reset my modem. @.@

dkolb commented 3 years ago

@chase9 What about adding a bit of randomness to the polling interval? I was wondering if the regular cadence of polling could possibly be what is causing the errors. Detecting a poll every 60 seconds would be relatively straight forward. Perhaps coincidentally I use a 120 second polling interval and don't experience the ECONNRESET errors but I also do not have 2FA/MFA enabled nor does my provider require it

I'll set up a 120 second interval and re-enable the plugin to see if that helps me. I have a similar situation: No 2FA required and it's not enabled.

dkolb commented 3 years ago
  • TLSv1.3 (OUT), TLS handshake, Client hello (1):

@chase9 Hmmm. 

❯ curl -v https://www.alarm.com/web/Default.aspx
*   Trying 192.155.71.71...
* TCP_NODELAY set
* Connected to www.alarm.com (192.155.71.71) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/cert.pem
  CApath: none
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384

Can you force TLSv1.2?

❯ /usr/local/opt/curl/bin/curl -v --tlsv1.3 https://www.alarm.com/web/Default.aspx

*   Trying 192.155.71.71:443...
* Connected to www.alarm.com (192.155.71.71) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS alert, handshake failure (552):
* error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure
* Closing connection 0
curl: (35) error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure
happyzorro commented 3 years ago

@dkolb last week I migrated from a Google WIFI mesh to an Eero 6 pro mesh and had to get my ISP to do a hard reset of my fibre ONT which cleared all the MAC addresses inside it. This was the only way I could get my new Eero's to connect to the internet. As a result, I had a new IP address assigned to my router's MAC address. I have not had any errors since the reset. Fingers crossed that it stays like that.

The previous time the errors went away, I had restarted my Google Wifi router (and all the mesh points). I can confirm that my ISP also assigned a brand new WAN IP address at that time. I was error-free for about a week, and then unfortunately the error came back.

dkolb commented 3 years ago

I tried 2 minute intervals and it hasn’t helped. 😢

chase9 commented 3 years ago

Were you able to see if you actually got a new public IP by checking your IP before/after restarting your modem? You can go to this website to check your public ip: https://whatismyipaddress.com

Chase Lau @.***

On Apr 27, 2021, at 6:52 PM, David Kolb @.***> wrote:

I tried 2 minute intervals and it hasn’t helped. 😢

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/node-alarm-dot-com/homebridge-node-alarm-dot-com/issues/63#issuecomment-828036100, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABN4B25FODEPWXWRW5APIGDTK5E3NANCNFSM4ZBT5Y4Q.

dkolb commented 3 years ago

@chase9 I have not gotten a new WAN IP. It's...quite a production to do that.

I was working with the code on the node-alarm-dot-com/node-alarm-dot-com repo. I noted that I'm not getting back the afg cookies from the example scripts' attempts to login. Logging in with the web browser I get that Set-Cookie header in the 302 that comes back from the post to https://www.alarm.com/web/Default.aspx.

I've tried fiddling with the User Agent string and more. I did note that if I "stole" the afg cookie from my browser and set ajaxKey to it, I'd get failures from the API faster and less ECONNRESETS from API calls. That said, I get a lot of ECONNRESETs on the login process.

I'm becoming pretty sure that there's some defensive measures we're tripping. I have the same WAN IP when using a browser and I have absolutely no issue making all these API calls from within the web app. I can refresh the login page all day and not get this issue.

If I get a chance in the next week or so I'll try to get a new WAN IP assigned and turn the plugin back on. 🤷🏻‍♂️

dkolb commented 3 years ago

(Honestly at this point I'm probably just going to start shopping for a new alarm system that is HomeKit compatible.)

ngori commented 3 years ago

@dkolb You may want to try another ADC provider before giving up entirely. If you own your equipment, I use Surety (https://suretyhome.com/) which is very DIY friendly, low cost with no long term contracts, and seems to work relatively well with the plugin. It was some time ago when I was looking at systems but Abode was the only monitored, native HomeKit compatible system at the time. Professional monitoring is/was important for us vs self monitoring. If self monitoring there are plenty of other options.

nelhenry commented 3 years ago

https://github.com/uvjustin/pyalarmdotcomajax

So, this seems to work fine with Home Assistant. Someone smarter than I might be able to use it to work out the issues here?

BinhM3 commented 3 years ago

I am experiencing the something. set the following: "authTimeoutMinutes": 60, "pollTimeoutSeconds": 120,

[BRINK] Error: GET https://www.alarm.com/web/api/devices/sensors?ids%5B%5D=94003690-5262&ids%5B%5D=94003690-5257&ids%5B%5D=94003690-8&ids%5B%5D=94003690-3&ids%5B%5D=94003690-10&ids%5B%5D=94003690-5263&ids%5B%5D=94003690-4&ids%5B%5D=94003690-5258&ids%5B%5D=94003690-229&ids%5B%5D=94003690-5&ids%5B%5D=94003690-9 failed: request to https://www.alarm.com/web/api/devices/sensors?ids%5B%5D=94003690-5262&ids%5B%5D=94003690-5257&ids%5B%5D=94003690-8&ids%5B%5D=94003690-3&ids%5B%5D=94003690-10&ids%5B%5D=94003690-5263&ids%5B%5D=94003690-4&ids%5B%5D=94003690-5258&ids%5B%5D=94003690-229&ids%5B%5D=94003690-5&ids%5B%5D=94003690-9 failed, reason: read ECONNRESET at /home/hoobs/.hoobs/node_modules/node-alarm-dot-com/dist/index.js:466:15 at runMicrotasks () at processTicksAndRejections (internal/process/task_queues.js:97:5) at async Promise.all (index 1) at async Promise.all (index 0)

JCallender73 commented 3 years ago

Anyone have an update on this? Also where do you get the beta branch?

kaganae commented 3 years ago

FWIW, I changed ISP's on Friday and, since then, zero ECONNRESET's. Could validate that they are flagging based on same IP address making requests.

[5/2/2021, 6:48:45 AM] [Security System] Logging into Alarm.com as xxxxxxx@gmail.com [5/2/2021, 6:48:45 AM] [Security System] Logged into Alarm.com as xxxxxxx@gmail.com [5/2/2021, 6:59:45 AM] [Security System] Logging into Alarm.com as xxxxxxx@gmail.com [5/2/2021, 6:59:45 AM] [Security System] Logged into Alarm.com as xxxxxxx@gmail.com [5/2/2021, 7:10:45 AM] [Security System] Logging into Alarm.com as xxxxxxx@gmail.com [5/2/2021, 7:10:45 AM] [Security System] Logged into Alarm.com as xxxxxxx@gmail.com [5/2/2021, 7:21:45 AM] [Security System] Logging into Alarm.com as xxxxxxx@gmail.com [5/2/2021, 7:21:45 AM] [Security System] Logged into Alarm.com as xxxxxxx@gmail.com [5/2/2021, 7:32:45 AM] [Security System] Logging into Alarm.com as xxxxxxx@gmail.com [5/2/2021, 7:32:45 AM] [Security System] Logged into Alarm.com as xxxxxxx@gmail.com [5/2/2021, 7:32:46 AM] [Security System] Updating sensor LIVING ROOM MOTION (96622429-5), state=0, prev=1 [5/2/2021, 7:37:45 AM] [Security System] Updating sensor LIVING ROOM MOTION (96622429-5), state=1, prev=0 [5/2/2021, 7:43:45 AM] [Security System] Logging into Alarm.com as xxxxxxx@gmail.com [5/2/2021, 7:43:45 AM] [Security System] Logged into Alarm.com as xxxxxxx@gmail.com [5/2/2021, 7:54:45 AM] [Security System] Logging into Alarm.com as xxxxxxx@gmail.com [5/2/2021, 7:54:45 AM] [Security System] Logged into Alarm.com as xxxxxxx@gmail.com [5/2/2021, 8:05:45 AM] [Security System] Logging into Alarm.com as xxxxxxx@gmail.com [5/2/2021, 8:05:46 AM] [Security System] Logged into Alarm.com as xxxxxxx@gmail.com [5/2/2021, 8:16:45 AM] [Security System] Logging into Alarm.com as xxxxxxx@gmail.com [5/2/2021, 8:16:46 AM] [Security System] Logged into Alarm.com as xxxxxxx@gmail.com [5/2/2021, 8:27:45 AM] [Security System] Logging into Alarm.com as xxxxxxx@gmail.com [5/2/2021, 8:27:46 AM] [Security System] Logged into Alarm.com as xxxxxxx@gmail.com [5/2/2021, 8:38:45 AM] [Security System] Logging into Alarm.com as xxxxxxx@gmail.com [5/2/2021, 8:38:46 AM] [Security System] Logged into Alarm.com as xxxxxxx@gmail.com [5/2/2021, 8:49:45 AM] [Security System] Logging into Alarm.com as xxxxxxx@gmail.com

happyzorro commented 3 years ago

After having been error-free for a couple of weeks, they are back for me.

JCallender73 commented 3 years ago

After upgrading my HOOBS device to Beta 4 and upgrading my plugin to the 2FA beta I am still getting errors. I'm not sure if this is an IP address blocking issue with Alarm.com that this plugin will ever work again. Any thoughts?

5/3/2021, 8:16:16 PM Node Alarm Dot Com Bridge Loaded plugin 'homebridge-node-alarm-dot-com' 5/3/2021, 8:16:16 PM Node Alarm Dot Com Bridge Loading 1 platforms... 5/3/2021, 8:16:16 PM Node Alarm Dot Com Bridge Security System Logging into Alarm.com as XXXXXX 5/3/2021, 8:16:16 PM Node Alarm Dot Com Bridge Bridge is running on port 51826. 5/3/2021, 8:16:32 PM Node Alarm Dot Com Bridge Security System ERROR UNHANDLED ERROR: Error: GET https://www.alarm.com/login failed: GET https://www.alarm.com/login failed: request to https://www.alarm.com/login failed, reason: read ECONNRESET at /var/lib/hoobs/nodealarmdotcombridge/node_modules/node-alarm-dot-com/dist/index.js:56:15 at processTicksAndRejections (internal/process/task_queues.js:93:5) 5/3/2021, 8:18:16 PM Node Alarm Dot Com Bridge Security System Logging into Alarm.com as XXXXXXX 5/3/2021, 8:18:17 PM Node Alarm Dot Com Bridge Security System Logged into Alarm.com as XXXXXXXX

joewilliamsca commented 3 years ago

Hi All!

So I have been seeing the ECONNRESET for the past two months, and I don't know if ADC is actually trying to block us from their API. I do get the error multiple times an hour, but the plugin still works for me for arming and disarming, and if I didn't look at the logs, I would have not known there was an issue with our connectivity to ADC

What I wonder is if there is some new encoding that might be causing the issue with "some" of the API calls. When I was trying to look up the ECONNRESET and NodeJS, this article came up in Stack Overflow...

https://stackoverflow.com/questions/59591058/econnreset-error-while-fetching-an-url-in-node-js

I do notice that the existing node-alarm-dot-com library uses node-fetch, not sure if a test with axios would be worth trying. I really don't have a good way of testing this, but it might be a thought. If we were being blocked by ADC, I would expect an error message about an invalid API use to be thrown, followed up by a nasty-gram from ADC.

I should note, the only thing I have with ADC, is the alarm itself. I don't have lights/locks and other smart devices hooked into ADC...

techfreakdad commented 3 years ago

Hi All!

So I have been seeing the ECONNRESET for the past two months, and I don't know if ADC is actually trying to block us from their API. I do get the error multiple times an hour, but the plugin still works for me for arming and disarming, and if I didn't look at the logs, I would have not known there was an issue with our connectivity to ADC

What I wonder is if there is some new encoding that might be causing the issue with "some" of the API calls. When I was trying to look up the ECONNRESET and NodeJS, this article came up in Stack Overflow...

https://stackoverflow.com/questions/59591058/econnreset-error-while-fetching-an-url-in-node-js

I do notice that the existing node-alarm-dot-com library uses node-fetch, not sure if a test with axios would be worth trying. I really don't have a good way of testing this, but it might be a thought. If we were being blocked by ADC, I would expect an error message about an invalid API use to be thrown, followed up by a nasty-gram from ADC.

I should note, the only thing I have with ADC, is the alarm itself. I don't have lights/locks and other smart devices hooked into ADC...

same here. the only reason i discovered was i wanted to add a new device from alarm.com and it won't work . however the security panel arming/ disarming works fine in HK. the irony for me is that i started using HB specifically to bring alarm.com to HK!

JCallender73 commented 3 years ago

After a lot of work and research I found that I was not using the proper string for my 2FA cookie in the beta version.

The plug-in still gives the error on first login attempt but I found all of my alarm.com devices on my system. One strange device says it's a light but I do not have any lights connected to my alarm.com system. I believe it is mis labeling this for my automatic garage door opener.

However like the previous 2 posts none of my devices work except the alarm arming and disarming panel. None of my contact sensor change states even though they are logged in the history for alarm.com. Sadly I also got Homebridge just to get my ADT system on HK.

ifeign commented 3 years ago

It looks like this plugin may meet the fate that the old Frontpoint plugin met, it’s being flagged and blocked by their server. Back when that happened I was actually contacted by one of their reps to ask about “suspicious activity” on my network. I explained what Homebridge was and they said they’d take me off their blocklist… but they never actually did that. You may have to either contact Alarm.com and plead your case (though I worry that might trigger them to investigate this further and actively close all loopholes), or maybe this plugin can spoof an Android device like the Ring plugin does? No idea if that would make a difference - but Qolsys panels are Android based and probably ping the server just as much or if not more than this plugin does.

Alternatively local control could solve many of these issues https://github.com/node-alarm-dot-com/homebridge-node-alarm-dot-com/issues/71

JCallender73 commented 3 years ago

I was able to get mine working once I got the proper 2FA cookie. Unfortunately the only thing that actually works is the arm and disarm. It sees my garage door opener as a light and none of the door sensors change state.

anthonyb82 commented 3 years ago

My knowledge with all this is very limited, but I wanted to share in case it’s possibly related. I updated my nodejs yesterday (14.17) and since doing so I am seeing this error almost constantly. I can still arm/disarm without issue though. Previously I was on node 14.15 and would see this only periodically, maybe once a day or once every two days. Not sure if there is any connection to this at all, but wanted to add it to the pile of puzzle pieces.

ngori commented 3 years ago

Well I'm on Node 12.8.12 (way behind). I also didn't have this issue more than every other day or so just checked my logs and getting them constantly. This is new as of today. I don't have 2FA enabled, nor is it required with my provider