Error on Post: ECONNRESET #63
Comments
|
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 |
|
same here |
|
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. |
|
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:
|
|
Hi @chase9 Im still running into the issue.
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. |
|
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 :) |
|
Add me to the list of people experiencing this. Provider: CPI Security (Alarm.com) w/o MFA |
|
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 |
|
Same problem here Provider: Securiteck (Alarm.com) w/o MFA |
|
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 |
|
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: Anyone have more ideas on how to troubleshoot this? |
|
@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 |
|
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
|
|
sadly, ECONNRESET error is back. I have re-started my network again, but no luck. |
|
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 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!) |
|
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 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 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 |
|
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. |
|
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: |
... 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. |
|
@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. |
|
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: Not sure why this is happening yet. |
|
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. |
@chase9 Hmmm. Can you force TLSv1.2? |
|
@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. |
|
I tried 2 minute intervals and it hasn’t helped. 😢 |
|
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 <#63 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABN4B25FODEPWXWRW5APIGDTK5E3NANCNFSM4ZBT5Y4Q>.
|
|
@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 I've tried fiddling with the User Agent string and more. I did note that if I "stole" the 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. 🤷🏻♂️ |
|
(Honestly at this point I'm probably just going to start shopping for a new alarm system that is HomeKit compatible.) |
|
@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. |
|
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? |
|
I am experiencing the something. [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 |
|
Anyone have an update on this? Also where do you get the beta branch? |
|
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 [email protected] |
|
After having been error-free for a couple of weeks, they are back for me. |
|
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 |
|
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! |
|
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. |
|
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 #71 |
|
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. |
|
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. |
|
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 |
|
Same issue here!!!! Tried on a clean install with all the latest NPM and Node.js but still have the same issue. It’s intermittent. I need at least the alarm and smoke detectors to work. I use it to turn off my HVAC system in case of a fire saving me $300 per floor to get Zwave thermostats. |
Err, I wouldn’t trust the safety of my home with an unofficial integration that can break at any time. Your life is worth $900. This bug is a perfect example of why you shouldn’t be doing so. IMO, this plugin is a nice convenience, nothing more. |
I don’t disagree but I’ve had this alarm without the feature for 8 years. I’ve only had this for 2 months and really like the added feature but like you said it isn’t full proof. Alarm.com isn’t the most reliable either… I’m considering some alternatives like echo guard mode and Wyze cameras that listen for the smoke detectors. I think the plug-in needs to get fixed so I don’t have to worry about it. |
|
I'm closing this thread to consolidate discussion in #72. Also, @Nbr1Sniper, I believe Alarm.com has a built-in automation template for shutting HVAC down when a fire alarm is triggered. I would strongly recommend looking into this instead of a third-party plugin. |
You’re correct but it only works with alarm.com thermostats. Potentially it may work with any Zwave thermostats however the ones I have won’t work with any other Zwave controller. They are their own controller (nexia system with Trane). |
|
Why is this closed? Still an issue |
There's no point in having multiple open issues about the same problem. |
|
Hi All, I recently encountered this problem. My solution was:
Hope this helps |
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)
The text was updated successfully, but these errors were encountered: