ECONNRESET || No HomeKit Notifications on Status change

[fatal1010]

Checking the logs, I see the following, is this a concern and what could be the cause?

0|homebrid | [11/17/2019, 00:54:28] [Garage Door] FetchError: request to https://api.myqdevice.com/api/v5/accounts//devices/ failed, reason: read ECONNRESET 0|homebrid | at ClientRequest. (/usr/lib/node_modules/homebridge-chamberlain/node_modules/node-fetch/index.js:133:11) 0|homebrid | at ClientRequest.emit (events.js:210:5) 0|homebrid | at TLSSocket.socketErrorListener (_http_client.js:406:9) 0|homebrid | at TLSSocket.emit (events.js:210:5) 0|homebrid | at emitErrorNT (internal/streams/destroy.js:92:8) 0|homebrid | at emitErrorAndCloseNT (internal/streams/destroy.js:60:3) 0|homebrid | at processTicksAndRejections (internal/process/task_queues.js:80:21) { 0|homebrid | name: 'FetchError', 0|homebrid | message: 'request to https://api.myqdevice.com/api/v5/accounts//devices/ failed, reason: read ECONNRESET', 0|homebrid | type: 'system', 0|homebrid | errno: 'ECONNRESET', 0|homebrid | code: 'ECONNRESET' 0|homebrid | }

Info

iOS Version: 13.2.2 Plugin Version: latest HomeBridge Version: latest Node/Npm Version: 12.13 / 6.12

Also, this is probably related to iOS 13 (HomeKit just acting weird), but, I don't get consistent notifications on my phone when garage opens/closes...I sometimes randomly get an Open or Close status, but, very very sporadic.

Let me know.

[iRayanKhan]

Is there a chance you may have mistyped your login info?

[fatal1010]

No, this is randomly scattered in the error log file, sometimes once a day, sometimes multiple times a day ... the std output has the normal garage state change log lines in it and the Home app opens/closes the garage as expected.

Don't know if this is an issue or not, just thought I'd point it out to you that my error log has these entries.

As a side note, I don't receive any Home app alerts anymore though (or, again, very randomly sometimes that the garage has opened or closed), but I think it is related to iOS 13 (was working well in iOS 12).

[iRayanKhan]

Is there a chance you may have enabled "DND" for the Home App? I did that once for messages on accident. In Settings > Notifications > Home it should show. It seems like since it's scattered the request just fails. Issue #51 had a similar issue, and an update fixed it. I'll keep track of this.

[fatal1010]

Hey, nope, nothing in listed under Settings -> Notification -> Home...chalk it up to random request failures.

[xDiavelS]

I am also this exact same error message throughout my logs. Sometimes it happens multiple times in a row, other times it can be hours in between. The door still opens through HomeKit and Siri, so doesn't seem to be a major problem though.

[iRayanKhan]

If notifications never show, it means something is really wrong. If it was just a request failure, then the status would also not report in HomeKit. But since the Status does poll in HomeKit (As far as I can tell), it may be a Home App issue. Maybe re-adding the accessories may help?

[iRayanKhan]

@kbardai In the Home App, top Left Corner (Home Image), tap "Home Settings", select your home, then go to "Notifications", then "Doors and Locks". See if they were disabled.

[fatal1010]

The "Doors and Locks" notification is enabled. I've tried turning it off and on again but the notifications are very sporadic, sometimes I get notifications/sometimes none.

I'll try your suggestion of removing homebridge and re-adding to see if that helps...dunno if I need to go all nuclear and clear accessories/cache from homebridge as well, maybe as last resort.

[iRayanKhan]

Hey @kbardai did anything work so far?

[fatal1010]

Hey,

Removed and re-added homebridge from home app, no success...still sporadic notifications for garage. Removed accessories/persit, removed homebridge from home app, restarted, re-added homebridge to homeapp, setup all accessories again (PITA), still no success, sporadic notifications.

Imma chalk it up to iOS13 issues?

Edit: to clarify, garage is the only notification I have setup in Home app.

Take Care

[DMBlakeley]

I am seeing the same behavior, same iOS revision, random in occurrence. Just updated to nom version 6.13.2 and will monitor.

[fatal1010]

Just installed the Schlage Sense door (HomKit) and get alerts consistently and almost instantly (whether manually unlocking or through homekit or schlage app)...dunno why garage alerts are a hit/miss :/

Edit: to add, sometimes I get notifications when I open the Home App, notifications that should have gotten hour+ ago/etc.

Edit2: https://github.com/KhaosT/HAP-NodeJS/issues/543 https://github.com/nfarina/homebridge/issues/2160

[seldridge1]

I’m also having similar results re: status change notifications. Would estimate I’m only receiving a notification about 10% of the time the door is opened or closed whether I’m on WiFi or cellular.

[fatal1010]

Here are some debug log info when I opened/closed the garage...received no notifications on any device. The IPs listed below are homepods and/or iphones/macbook. Also, let me know if this is getting off topic from the original post I made.

Accessory [Homebridge] Processing characteristic set: [{"aid":2,"iid":10,"ev":true},{"aid":2,"iid":11,"ev":true}] +0ms Accessory [Homebridge] Registering Characteristic "Current Door State" for events +0ms Accessory [Homebridge] Registering Characteristic "Target Door State" for events +1ms EventedHTTPServer [::ffff:192.168.1.6] Sending HTTP event '2.10' with data: {"characteristics":[{"aid":2,"iid":10,"value":0}]} +11s EventedHTTPServer [::ffff:192.168.1.151] Sending HTTP event '2.10' with data: {"characteristics":[{"aid":2,"iid":10,"value":0}]} +1ms EventedHTTPServer [::ffff:192.168.1.7] Sending HTTP event '2.10' with data: {"characteristics":[{"aid":2,"iid":10,"value":0}]} +1ms EventedHTTPServer [::ffff:192.168.1.246] Sending HTTP event '2.10' with data: {"characteristics":[{"aid":2,"iid":10,"value":0}]} +0ms EventedHTTPServer [::ffff:192.168.1.167] Sending HTTP event '2.10' with data: {"characteristics":[{"aid":2,"iid":10,"value":0}]} +1ms [12/7/2019, 15:59:49] [Garage Door] doorstate changed from closed to open EventedHTTPServer [::ffff:192.168.1.6] Sending HTTP event '2.11' with data: {"characteristics":[{"aid":2,"iid":11,"value":0}]} +2ms EventedHTTPServer [::ffff:192.168.1.151] Sending HTTP event '2.11' with data: {"characteristics":[{"aid":2,"iid":11,"value":0}]} +1ms EventedHTTPServer [::ffff:192.168.1.7] Sending HTTP event '2.11' with data: {"characteristics":[{"aid":2,"iid":11,"value":0}]} +1ms EventedHTTPServer [::ffff:192.168.1.246] Sending HTTP event '2.11' with data: {"characteristics":[{"aid":2,"iid":11,"value":0}]} +1ms EventedHTTPServer [::ffff:192.168.1.167] Sending HTTP event '2.11' with data: {"characteristics":[{"aid":2,"iid":11,"value":0}]} +0ms EventedHTTPServer [::ffff:192.168.1.6] Sending HTTP event '2.10' with data: {"characteristics":[{"aid":2,"iid":10,"value":1}]} +2m EventedHTTPServer [::ffff:192.168.1.151] Sending HTTP event '2.10' with data: {"characteristics":[{"aid":2,"iid":10,"value":1}]} +1ms EventedHTTPServer [::ffff:192.168.1.7] Sending HTTP event '2.10' with data: {"characteristics":[{"aid":2,"iid":10,"value":1}]} +1ms EventedHTTPServer [::ffff:192.168.1.167] Sending HTTP event '2.10' with data: {"characteristics":[{"aid":2,"iid":10,"value":1}]} +0ms EventedHTTPServer [::ffff:192.168.1.246] Sending HTTP event '2.10' with data: {"characteristics":[{"aid":2,"iid":10,"value":1}]} +1ms [12/7/2019, 16:05:17] [Garage Door] doorstate changed from open to closed EventedHTTPServer [::ffff:192.168.1.6] Sending HTTP event '2.11' with data: {"characteristics":[{"aid":2,"iid":11,"value":1}]} +2ms EventedHTTPServer [::ffff:192.168.1.151] Sending HTTP event '2.11' with data: {"characteristics":[{"aid":2,"iid":11,"value":1}]} +1ms EventedHTTPServer [::ffff:192.168.1.7] Sending HTTP event '2.11' with data: {"characteristics":[{"aid":2,"iid":11,"value":1}]} +0ms EventedHTTPServer [::ffff:192.168.1.167] Sending HTTP event '2.11' with data: {"characteristics":[{"aid":2,"iid":11,"value":1}]} +1ms EventedHTTPServer [::ffff:192.168.1.246] Sending HTTP event '2.11' with data: {"characteristics":[{"aid":2,"iid":11,"value":1}]} +1ms [12/7/2019, 16:05:17] [Garage Door] desireddoorstate changed from open to closed

[iRayanKhan]

Personally I'm a few revisions behind of this plugin on my main setup since it works for me (pretty sure it goes as far as the last V4 Api version I updated) so I can try this version with the V5 Api and see if there's more to it.

[twentyNoise]

Edit: to add, sometimes I get notifications when I open the Home App, notifications that should have gotten hour+ ago/etc.

These are all the same issues I’ve been seeing since I installed this plugin a few years back. It may be worse in iOS 13 but always been an issue. I first posted about it here: https://github.com/caseywebdev/homebridge-chamberlain/issues/40

Been trying to get to the bottom of it for a while.

[joker1138]

Same issues, same iOS. Usually early in the morning will get the error in home bridge. On Homekit, if I press all the items that are "no response", they eventually reconnect. Of course, restarting home bridge clears everything up.

[hepcat72]

I have the same log errors, however I disabled the notifications (they're reliable from the MyQ app). I ended up here to figure out what I needed to do to quiet the errors.

[iRayanKhan]

Seeing as this is becoming more widespread and splitting into more issues here's what I propose:

For the lack of notifications can you please confirm the following:

• Notifications aren't silenced by iOS: Settings -> Notifications -> Home Ensure everything is as expected, and there is a special tab in blue text called "Home Notification Settings), make sure your Doors, Locks, Windows, and Garages are either on/off to your liking.

I would like more logs please. If possible in your current environment, run home bridge with the debug flag.

Homebridge -D

I would like a reply of the most recent debug output. I also would like:

• Node Version:

  Node -V

• NPM version:

  Npm -v

  Also the current home bridge version.

I would like more logs and more environment info from other people to see if I can isolate a common variable or condition.

Also please let me know what your environments are, like the platform and hardware you are running this on. I want to see if y'all can rollback your installation version as a temporary fix since an older version works for me. (Away from home atm, but will report back my version).

I appreciate y'all for bringing this to my attention and I am working as hard as I can to fix this for y'all.

Enjoy y'alls new year!

[hepcat72]

I would like more logs please. If possible in your current environment, run home bridge with the debug flag.

Homebridge -D

I would like a reply of the most recent debug output.

It may take awhile to get the error, so it's not like I can stop homebridge, and manually run that on the command line and see the error. I've been wanting to regularly run homebridge with the -D flag for awhile for other reasons, but if you run homebridge using pm2, like me, I don't know how to supply that flag and have the process managed (i.e. restart if it quits, start up on boot, etc). I would need that if I'm going to be running it this way long enough to get that error in this debug mode.

(I'd paste current non -D logs, but I'm VNC'd in ATM and the clipboards aren't linked.)

I also would like:

• Node Version:

Node -V

>node -v
v11.12.0

• NPM version:

 Npm -v

>npm -v
6.13.4

Also the current home bridge version.

>homebridge --version
0.4.49

I would like more logs and more environment info from other people to see if I can isolate a common variable or condition.

Can you be more specific?

Also please let me know what your environments are, like the platform and hardware you are running this on.

rPi 3 jesse

I want to see if y'all can rollback your installation version as a temporary fix since an older version works for me. (Away from home atm, but will report back my version). I appreciate y'all for bringing this to my attention and I am working as hard as I can to fix this for y'all.

Enjoy y'alls new year!

Happy New Year to you as well.

[dqtech]

I have the same ECONNRESET issue and also experience sporadic HomeKit Notifications when opening and closing the garage door.

IOS Home App Notifications: Using iOS 13.2.2. I checked this an I have notifications enabled for the garage door. I also have a Schlage Sense Lock and it notifies me consistently. The big difference here is the lock is native HomeKit compatible and not using homebridge.

Hardware I am running CoreELEC v9.2.1 on an X96 Android Box. The X96 uses an Amlogic S905X (arm64v8) with 1GB RAM.

Environment:

/homebridge # uname -a
Linux CoreELEC 3.14.29 #1 SMP Wed Nov 27 06:02:54 GMT 2019 aarch64 GNU/Linux

Versions: Homebridge is running in a docker container (oznu/homebridge) with host networking setup.

/homebridge # node -v
v12.14.0
/homebridge # npm -v
6.13.4
/homebridge # homebridge --version
0.4.50

Log File: Here is a standard log file showing lots of examples of this ECONNRESET error. I am running homebridge with the debug (-D flag) as I reply to this post, but the ECONNRESET error hasn't popped up yet. I will reply with the log file once the error occurs.

homebridge.log

Originally I first tried out the homebridge-myq2 plugin to connect to my Chamberlain Smart Garage Door Hub. Myq2 functions to open/close the door in the Home App, but notifications didn't work reliably. This is how I came across this plugin -I wanted to see if the homebridge-chamberlain plugin would give me consistent notifications.

Scanning through the attached log file, it appears that myq2 also suffers from ECONNRESET issues even though it looks like they are using v4api.

One last thing to note. I also have an old iPhone 5c running iOS 10. The garage door open/close notifications are consistent. Strange eh?!

[iRayanKhan]

Two things I can think of at the moment. (Please read the whole thing before doing any of this as there's multiple workarounds for each workaround.) When I get home I will supply the version of the plugin I am using for my main setup. The fact it works on iOS furthers my theory about HomeKit no response issues.

If possible, clear Persist and cachedAccessories, unpair bridge from HomeKit, make a new HomeKit Home, see if notifications show there. If you can't remove the bridge from your HomeKit home due to having multiple plugins, make another instance of this plugin. Steps here:

mkdir GarageTestBridge
cd GarageTestBridge/
nano config.json 
(If on non command line systems, drag and drop your config.json file here with only the chamberlain plugin in the config).
Then start this new instance of HomeBridge by doing: homebridge -U ~/GarageTestBridge/ 
(Cases Matter)
Add this new HomeKit bridge to your new HomeKit home, and see if you can get notifications. 

Be sure to change the homebridge Username, port, and name, (set-up pin code is fine as default) for the new Config file.

Reasoning: I had a HomeKit home created in iOS 11.4 and users I shared the home with started having major issues where they couldn't control accessories locally or remotely. My assumption, was that with big HomeKit app changes with new iOS updates, something didn't convert properly for a iOS 13 version home. Also I recommend staying away from older iOS devices for your HomeKit home. I had tried to use an old iPad (runs iOS 10.3.3 max), as a HomeKit hub instead of the Apple TV's or HomePods, and it converted my light switches to Garages, and swapped all accessory states and ended up breaking my home. So If Making a new HomeKit Home works and the notifications along with it, it means it just have been a migration issue Apple is yet to fix in iOS for new Home.app versions. I fixed my issues by making a new HomeKit home, and factory resetting All HomeHubs and it's been flawless so far. I plan to raise a feedback ticket with Apple to address this since I had an open Support case for now 7-8 months regarding HomeKit instability. Sorry to the mini rant, but here's a

tldr; iOS migration issues cause home.app to not make HomeKit's core functions work, and making a new HomeKit home worked for me.

[iRayanKhan]

Thanks for the logs @dqtech I noticed that you have homebridge-tplink-smarthome, I have this plugin too and you have to declare something for that plugin or this method to add a new homebridge instance won't work. I have a config just for this I will send in 4 or so hours.

I am doing more research on ECONNRESET, but since it's not that major as compared to Garage notification states, the priority is the notifications. Edit: I noticed that this error as stated happens every once in a while and at max happens 3 times a day, or once every day within the same time span. Do the times in the logs mean anything to you like, do you check the Home App during this time, or have anyone arrive then? I want to see if this is just background polling that fails, and the request just re-requests it's self.

[iRayanKhan]

Hey @hepcat72, thanks for the reply.

but if you run homebridge using pm2, like me, I don't know how to supply that flag and have the process managed

I also run PM2 on my environment too, I managed to get pm2 to run homebridge using the -U flag (specified folder), using a shell script to start PM2 in that certain instance, I'll send the file (it's 2 lines long), and how to have PM2 use the -D Flag. I know the -U flag works, -D should too.

[rajbala]

I also have the ECONNRESET issues sporadically through the logs.

/homebridge # node -v
v12.14.0
/homebridge # npm -v
6.13.4
/homebridge # homebridge --version
0.4.50
/homebridge #

I am running Homebridge in a Docker container on a RPi4 with 4GB of RAM. Happy to help debug this if I can.

[iRayanKhan]

So I was working on some tweaks for this plugin to make getting the version info and such easier, anyways I am using V1.0.6 of the plugin. I will upgrade to V1.0.8 and get back with y'all tonight and see if notifications work.

Also thank you everyone for replying and providing logs and such I appreciate it a lot.

I am hoping to have this issue resolved within a week, it also seems to be non-severe (the ECONNRESET) since it's just seems like an API call back failure and it resend a request. But the notifications thing is a big deal 'cuz that's a big integration part in HomeKit. V1.0.9 will maybe suppress this error if that's what fixes it, and V1.10.0 or may just call it V2.0 will add Accessory info in the Home App to report plugin version (good for debugging), and add light controller support if I can make it info one plugin and not 2 branches, will still release the other branch.

[iRayanKhan]

Has anyone tried making a new Home and trying notifications?

[DMBlakeley]

If you startup Homebridge without defining a "deviceID" in the config.json file you receive an error "Multiple controllable devices found". In my case with 1 garage door opener 2 devices are reported. Both seem to work although one is shown in the "myQ" app on my iPhone. I was using the second device reported and receiving the errors previously reported. Have now switched to the first device reported and monitoring for errors.

Is there a difference between the 2 reported devices?

[DMBlakeley]

No luck ... already received following error with alternate deviceID:

[1/15/2020, 10:28:54 AM] [Garage Door] FetchError: request to https://api.myqdevice.com/api/v5/accounts/4a7c96bd-0609-4770-90e4-b6d45f87a98e/devices/GW0A0006841A failed, reason: read ECONNRESET
    at ClientRequest.<anonymous> (/usr/local/lib/node_modules/homebridge-chamberlain/node_modules/node-fetch/index.js:133:11)
    at ClientRequest.emit (events.js:223:5)
    at TLSSocket.socketErrorListener (_http_client.js:406:9)
    at TLSSocket.emit (events.js:223:5)
    at emitErrorNT (internal/streams/destroy.js:92:8)
    at emitErrorAndCloseNT (internal/streams/destroy.js:60:3)
    at processTicksAndRejections (internal/process/task_queues.js:81:21) {
  name: 'FetchError',
  message: 'request to https://api.myqdevice.com/api/v5/accounts/4a7c96bd-0609-4770-90e4-b6d45f87a98e/devices/GW0A0006841A failed, reason: read ECONNRESET',
  type: 'system',
  errno: 'ECONNRESET',
  code: 'ECONNRESET'
}

[iRayanKhan]

So to confirm for everyone; is econnreset just a warning that a request failed, but then it re-requests and starts responding in HomeKit, or complete no response 100% api fails?

[seldridge1]

@iRayanKhan, the former is my experience.

[DMBlakeley]

@iRayanKhan request that fails and then re-requests. API does not fail.

[madmattd]

@iRayanKhan For me, it would work for a while, then drop out, but it seemed to take too long to come back up. Did some searching and poking, looks like updating the api.js from ApiVersion: '4.1', to ApiVersion: '5.1', might resolve this.

Change: const req = ({body, headers, method, pathname, query}) => fetch(url.format({host, pathname, protocol, query}), { body: body == null ? body : JSON.stringify(body), headers: _.extend({ 'Content-Type': 'application/json', 'User-Agent': 'myQ/14041 CFNetwork/1107.1 Darwin/19.0.0', ApiVersion: '5.1', BrandId: '2', Culture: 'en', MyQApplicationId }, headers), method }).then((res) => { if (res.status < 200 || res.status >= 300) { return res.text().then(body => { throw new Error('invalid response, got HTTP ' + res.status + ': ' + body) }) } return res.text() }).then(data => { if (data) { return JSON.parse(data); } else { return null } });

From my log: [1/16/2020, 3:40:01 AM] [Garage Door] FetchError: request to https://api.myqdevice.com/api/v5/accounts/.... failed, reason: read ECONNRESET at ClientRequest. (C:\Users\Matt\AppData\Roaming\npm\node_modules\homebridge-chamberlain\node_modules\node-fetch\index.js:133:11) at ClientRequest.emit (events.js:223:5) at TLSSocket.socketErrorListener (_http_client.js:406:9) at TLSSocket.emit (events.js:223:5) at emitErrorNT (internal/streams/destroy.js:92:8) at emitErrorAndCloseNT (internal/streams/destroy.js:60:3) at processTicksAndRejections (internal/process/task_queues.js:81:21) { name: 'FetchError', message: 'request to https://api.myqdevice.com/api/v5/accounts/.... failed, reason: read ECONNRESET', type: 'system', errno: 'ECONNRESET', code: 'ECONNRESET' } [1/16/2020, 4:44:50 AM] [Garage Door] FetchError: request to https://api.myqdevice.com/api/v5/accounts/.... failed, reason: read ECONNRESET at ClientRequest. (C:\Users\Matt\AppData\Roaming\npm\node_modules\homebridge-chamberlain\node_modules\node-fetch\index.js:133:11) at ClientRequest.emit (events.js:223:5) at TLSSocket.socketErrorListener (_http_client.js:406:9) at TLSSocket.emit (events.js:223:5) at emitErrorNT (internal/streams/destroy.js:92:8) at emitErrorAndCloseNT (internal/streams/destroy.js:60:3) at processTicksAndRejections (internal/process/task_queues.js:81:21) { name: 'FetchError', message: 'request to https://api.myqdevice.com/api/v5/accounts/.... failed, reason: read ECONNRESET', type: 'system', errno: 'ECONNRESET', code: 'ECONNRESET' } [1/16/2020, 12:07:38 PM] [Garage Door] FetchError: request to https://api.myqdevice.com/api/v5/accounts/.... failed, reason: connect ETIMEDOUT #.#.#.#:443 at ClientRequest. (C:\Users\Matt\AppData\Roaming\npm\node_modules\homebridge-chamberlain\node_modules\node-fetch\index.js:133:11) at ClientRequest.emit (events.js:223:5) at TLSSocket.socketErrorListener (_http_client.js:406:9) at TLSSocket.emit (events.js:223:5) at emitErrorNT (internal/streams/destroy.js:92:8) at emitErrorAndCloseNT (internal/streams/destroy.js:60:3) at processTicksAndRejections (internal/process/task_queues.js:81:21) { name: 'FetchError', message: 'request to https://api.myqdevice.com/api/v5/accounts/.... failed, reason: connect ETIMEDOUT #.#.#.#:443', type: 'system', errno: 'ETIMEDOUT', code: 'ETIMEDOUT' }

[madmattd]

spoke too soon, just got the ECONNRESET error again.

@iRayanKhan For me, it would work for a while, then drop out, but it seemed to take too long to come back up. Did some searching and poking, looks like updating the api.js from ApiVersion: '4.1', to ApiVersion: '5.1', might resolve this.

Change: const req = ({body, headers, method, pathname, query}) => fetch(url.format({host, pathname, protocol, query}), { body: body == null ? body : JSON.stringify(body), headers: _.extend({ 'Content-Type': 'application/json', 'User-Agent': 'myQ/14041 CFNetwork/1107.1 Darwin/19.0.0', ApiVersion: '5.1', BrandId: '2', Culture: 'en', MyQApplicationId }, headers), method }).then((res) => { if (res.status < 200 || res.status >= 300) { return res.text().then(body => { throw new Error('invalid response, got HTTP ' + res.status + ': ' + body) }) } return res.text() }).then(data => { if (data) { return JSON.parse(data); } else { return null } });

From my log: [1/16/2020, 3:40:01 AM] [Garage Door] FetchError: request to https://api.myqdevice.com/api/v5/accounts/.... failed, reason: read ECONNRESET at ClientRequest. (C:\Users\Matt\AppData\Roaming\npm\node_modules\homebridge-chamberlain\node_modules\node-fetch\index.js:133:11) at ClientRequest.emit (events.js:223:5) at TLSSocket.socketErrorListener (_http_client.js:406:9) at TLSSocket.emit (events.js:223:5) at emitErrorNT (internal/streams/destroy.js:92:8) at emitErrorAndCloseNT (internal/streams/destroy.js:60:3) at processTicksAndRejections (internal/process/task_queues.js:81:21) { name: 'FetchError', message: 'request to https://api.myqdevice.com/api/v5/accounts/.... failed, reason: read ECONNRESET', type: 'system', errno: 'ECONNRESET', code: 'ECONNRESET' } [1/16/2020, 4:44:50 AM] [Garage Door] FetchError: request to https://api.myqdevice.com/api/v5/accounts/.... failed, reason: read ECONNRESET at ClientRequest. (C:\Users\Matt\AppData\Roaming\npm\node_modules\homebridge-chamberlain\node_modules\node-fetch\index.js:133:11) at ClientRequest.emit (events.js:223:5) at TLSSocket.socketErrorListener (_http_client.js:406:9) at TLSSocket.emit (events.js:223:5) at emitErrorNT (internal/streams/destroy.js:92:8) at emitErrorAndCloseNT (internal/streams/destroy.js:60:3) at processTicksAndRejections (internal/process/task_queues.js:81:21) { name: 'FetchError', message: 'request to https://api.myqdevice.com/api/v5/accounts/.... failed, reason: read ECONNRESET', type: 'system', errno: 'ECONNRESET', code: 'ECONNRESET' } [1/16/2020, 12:07:38 PM] [Garage Door] FetchError: request to https://api.myqdevice.com/api/v5/accounts/.... failed, reason: connect ETIMEDOUT #.#.#.#:443 at ClientRequest. (C:\Users\Matt\AppData\Roaming\npm\node_modules\homebridge-chamberlain\node_modules\node-fetch\index.js:133:11) at ClientRequest.emit (events.js:223:5) at TLSSocket.socketErrorListener (_http_client.js:406:9) at TLSSocket.emit (events.js:223:5) at emitErrorNT (internal/streams/destroy.js:92:8) at emitErrorAndCloseNT (internal/streams/destroy.js:60:3) at processTicksAndRejections (internal/process/task_queues.js:81:21) { name: 'FetchError', message: 'request to https://api.myqdevice.com/api/v5/accounts/.... failed, reason: connect ETIMEDOUT #.#.#.#:443', type: 'system', errno: 'ETIMEDOUT', code: 'ETIMEDOUT' }

[DMBlakeley]

Have been searching other posts on this problem and wonder if the SecurityToken is expiring between polls of MyQ?

Reference this posting. Believe current implementation of home bridge-chamberlain is consistent but don't know the answer to the SecurityToken.

Also learned from a discussion on stackoverflow.com:

"ECONNRESET" means the other side of the TCP conversation abruptly closed its end of the connection. This is most probably due to one or more application protocol errors. You could look at the API server logs to see if it complains about something.

What could also be the case: at random times, the other side is overloaded and simply kills the connection as a result. If that's the case, depends on what you're connecting to exactly…

[iRayanKhan]

@DMBlakeley very helpful, thank you for that info. I guess there was more to the V5 Api upgrade than we thought... Working on a fix, but if anyone can reverse the API again for me and see if it accepts any new user-agents or other info please tag me.

[fatal1010]

@iRayanKhan

Below is to try to resolve notifications issue, as you said, the econnreset is minor.

on iOS/HomeApp - All my notifications are on/active (not silenced) Node v12.14.0 npm v6.13.4 homebridge v0.4.5 iOS v13.3.1 (same on homepods)

Running homebridge in debug mode doesn't give any additional information...during this test I did not receive any notifications on any devices.

pi@raspberrypi:~/.homebridge $ DEBUG=* pi@raspberrypi:~/.homebridge $ homebridge -D [1/29/2020, 21:57:01] Loaded config.json with 1 accessories and 1 platforms. [1/29/2020, 21:57:01] --- [1/29/2020, 21:57:01] Loaded plugin: homebridge-chamberlain [1/29/2020, 21:57:01] Registering accessory 'homebridge-chamberlain.Chamberlain' [1/29/2020, 21:57:01] --- [1/29/2020, 21:57:01] Loaded plugin: homebridge-tplink-smarthome [1/29/2020, 21:57:01] Registering platform 'homebridge-tplink-smarthome.TplinkSmarthome' [1/29/2020, 21:57:01] --- [1/29/2020, 21:57:01] Loading 1 platforms... [1/29/2020, 21:57:01] [TplinkSmarthome] Initializing TplinkSmarthome platform... [1/29/2020, 21:57:01] [TplinkSmarthome] homebridge-tplink-smarthome v4.0.1, node v12.14.0, homebridge v0.4.50 [1/29/2020, 21:57:02] [TplinkSmarthome] config.json: {"platform":"TplinkSmarthome","name":"TplinkSmarthome","timeout":10,"switchModels":["HS200","HS210"]} [1/29/2020, 21:57:02] [TplinkSmarthome] config: {"platform":"TplinkSmarthome","name":"TplinkSmarthome","timeout":10,"switchModels":["HS200","HS210"],"addCustomCharacteristics":true,"deviceTypes":[],"discoveryOptions":{"discoveryInterval":10000,"deviceTypes":[],"deviceOptions":{"defaultSendOptions":{"timeout":10000}},"macAddresses":[],"excludeMacAddresses":[]},"defaultSendOptions":{"timeout":10000}} [1/29/2020, 21:57:02] Loading 1 accessories... [1/29/2020, 21:57:02] [Garage Door] Initializing Chamberlain accessory... ... ... lots of lines for tplink ... [1/29/2020, 21:57:29] [Garage Door] doorstate changed from closed to open [1/29/2020, 21:57:29] [Garage Door] desireddoorstate changed from closed to open [1/29/2020, 21:58:12] [Garage Door] doorstate changed from open to closed [1/29/2020, 21:58:12] [Garage Door] desireddoorstate changed from open to closed [1/29/2020, 21:58:43] [Garage Door] doorstate changed from closed to open [1/29/2020, 21:58:43] [Garage Door] desireddoorstate changed from closed to open [1/29/2020, 21:59:24] [Garage Door] doorstate changed from open to closed [1/29/2020, 21:59:24] [Garage Door] desireddoorstate changed from open to closed [1/29/2020, 21:59:30] Got SIGINT, shutting down Homebridge...

looking at the code (although I don't understand it 100%), I don't see where the value for doorstate is being set by you (I see the desireddoorstate.setValue) ... and I don't know if the issue is related to using setValue and instead we should use Characteristic.updateValue()? (see the two links I posted above in my previous post)

Also, do we need a return here?: https://github.com/caseywebdev/homebridge-chamberlain/blob/09a9712c7bcac68a2eb3a1db17426bc40f4055a8/src/chamberlain-accessory.js#L67

Thanks for looking into.

Take Care

[iRayanKhan]

I can look into this, but the main issue is it works for me, and I can't test to see if it work for y'all. If anyone is willing to run their chamberlain instance on another Pi (I have one someone can connect to), and see if a fresh install fixes it, then we can try that.

Edit:

Only reason I mention running it on another Pi, is to see if something is cached from your homebridge instance on your device.

[DMBlakeley]

I was reviewing the posted article that I referenced above and believe that there may be an error in api.js, line 140. I changed from:

pathname: '/api/v5/accounts/' + AccountId + '/devices/' + MyQDeviceId,

to:

pathname: '/api/v5.1/Accounts/' + AccountId + '/devices/' + MyQDeviceId,

Note the capitalization of “Accounts”. I have only been running now for a few hours without error but the error seems to be random and would consider 24 hours without an error a success. Will update.

——

UPDATE - unfortunately no dice. After a few hours received the same FetchError resulting in a ECONNRESET.

[jsrivatsan]

I have the same issues with inconsistent notifications and ECONNRESET errors in the log file. I am running homebridge on rpi 3B. I will send you the logs and environment info tomorrow.

[iRayanKhan]

@DMBlakeley Thanks for the update.

I currently don't have a phone to add my Garages to HomeKit in, would anyone be willing to try untested changes this weekend?

[iRayanKhan]

I also had one other thing, If you can, make a new HomeKit home, and add your garages to it and see if you get the notifications. Also, if possible, running this plugin on a new device (no prior files), and in a new HomeKit home would eliminate this being a Home app issue.

[iRayanKhan]

Has anyone had a chance to try the suggestions above? I am eager to resolve this issue asap to ensure a smooth transition to 5.1.

[DMBlakeley]

I have been experiencing connection issues with this app as well as the Ring and Alarm.com plug-ins so I did not rush to do additional tests. Noticed today that Node.js was updated to v12.15.0 and have updated my configuration to see if there are any changes in behavior.

UPDATE - didn't take long to get the ECONNRESET error from the getDeviceAttribute(options = {}) routine.

[jsrivatsan]

I tried making a new home and adding this plugin. I have been testing this setup for the past two days and the inconsistency is still there. I have not tested on a different device yet. I need to convince my wife on using her device and I have not had much success there :-(

[DMBlakeley]

I have been looking into the "Fetcherror" and "ECONNRESET" errors which I have been getting from this plugin.

I compared the routines in the api.js routine to other implementation of myQ including a recent one that I found which controlled the garage door through a Shortcut on my iPhone. The implementation of checking status, opening, and closing the door were pretty consistent other than the question if you should be using v5 or v5.1 in the calls. There was one location in api.js, line 154, where I changed v5 to v5.1 and this did not resolve the issue but also did not seem to break any functionality.

While searching for causes of "Fetcherror" I learned that this can be the result of too frequently polling the server. I only ever had this problem with the garage door closed for several hours and the plugin was polling the myQ servers to determine the garage door status. The error always occurred in the getDeviceAttribute subroutine.

This train of thought led me to look at the chamberlain-accessory.js routine. Line 6 was const IDLE_DELAY = 1000 * 10; which I changed to const IDLE_DELAY = 1000 * 11; to reduce the polling frequency. Yes, a small amount but it appears to be significant. Almost 24 hours since making this change and I have not seen an error. Prior to this change I would see the error 2 to 3 times per day.

As reference I am on node v12.15.0 and npm v6.13.7.

Does this make sense?

[DMBlakeley]

Received an error after about three 36 hours. Bumped from 11 to 12 on the iDLE_DELAY. Can't seem to find any details on minimum poll time for api.myqdevice.com.

Looks like I must have just been lucky. Changed multiplier to 12 then 13. Both produced errors. Suppose I was a bit optimistic.

[iRayanKhan]

Thanks for investigate work @DMBlakeley.

I did a fresh install (was forced) and now notifications are broken for me too. I still get them, I just have to open the home app, or sometimes they don't deliver.

I wonder if it is a dependancy issue, or iOS 13. Maybe even this ECONNRESET issue.

Is there a chance setting the delay to 15 or even 20 fix it? When using the shortcut does it limit polls or use a different user agent?

[DMBlakeley]

I did try 15 and even 20. Both resulted in errors. Seemed to go a bit crazy yesterday getting 20+ errors in an hour when I changed the multiplier back to *11.

Yesterday I found this reference on openHAB for myQ which indicates that "refresh" should be set at "60000" and "quick refresh" after an event is triggered should be set to "2000". This is the only reference I have been able to find on the required intervals.

Based on this reference I have changed the multiplier to *60. Still in the monitoring phase but not long enough to claim victory.

From my investigation, "Fetcherror" is the error and ECONNRESET is the response from the myQ servers. I want to say the error is not connected with iOS13 as Homebridge via this plugin (running on a Mac mini in my case) is interfacing with api.myqdevice.com and sending the status requests or change in state commands. Homekit also runs on the Mac now which also seems to eliminate iOS13 as the cause.

Will give you an update on the *60 multiplier.

[DMBlakeley]

Over 36 hours with multiplier at 60 and no FetchError from Chamberlain plugin. Have noticed that change in state (closed-opening-open) are not necessarily logged realtime when door is opened manually through wall button or Home connect in car. Will try reducing multiplier in 10 increments to see when errors start occurring.

UPDATE: Back to 60 and monitoring for errors. Didn't take long at 50 for an error to occur.