The dreaded "ETIMEDOUT" error

[raisingskell]

MBS humming along nicely for a few months until this error began showing a few weeks ago. It only happens during MQTT --> ST, never during ST --> MQTT. The error shows in the MBS log but not in ST IDE Live Logging. Something in the environment obviously changed but not by intention.

2020-02-26 00:55:27 AM error: undefined
2020-02-26 00:55:27 AM error: Error from SmartThings Hub: Error: connect ETIMEDOUT 192.168.0.xx:39500
2020-02-26 00:55:27 AM error: {
"errno": "ETIMEDOUT",
"code": "ETIMEDOUT",
"syscall": "connect",
"address": "192.168.0.xx",
"port": 39500
}

I've verified all the ip addresses and ports. I removed the devices.yml. Rebooted ST and server. I believe I'm running the latest mbs-server.js, config.yml and mbs-smartapp-full. To the best of my knowledge this is only happening with MBS.

Any suggestions on where else to search? Much appreciated!

[sgupta999]

Yeah this has been know to happen in many 3rd party integration. If u reboot the hub it should go away. Hubs been acting weird for me for the past week in general - going offline / online - sure Samsung is up to something

…

Sent from my iPhone

On Feb 27, 2020, at 10:31 PM, raisingskell ***@***.***> wrote:  MBS humming along nicely for a few months until this error began showing a few weeks ago. It only happens during MQTT --> ST, never during ST --> MQTT. The error shows in the MBS log but not in ST IDE Live Logging. Something in the environment obviously changed but not by intention. 2020-02-26 00:55:27 AM error: undefined 2020-02-26 00:55:27 AM error: Error from SmartThings Hub: Error: connect ETIMEDOUT 192.168.0.xx:39500 2020-02-26 00:55:27 AM error: { "errno": "ETIMEDOUT", "code": "ETIMEDOUT", "syscall": "connect", "address": "192.168.0.xx", "port": 39500 } I've verified all the ip addresses and ports. I removed the devices.yml. Rebooted ST and server. I believe I'm running the latest mbs-server.js, config.yml and mbs-smartapp-full. To the best of my knowledge this is only happening with MBS. Any suggestions on where else to search? Much appreciated! — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[pittbull]

Hi.

I was planning to migrate to your fork from St. John because of this issue, but discovered this report.

I have this issue when my custom Python script is setting a person present in ST. It is random in nature and it seems to be consistent across reboots. I changed my script to loop until ST reports the device present and during my tests today it works on either the 2nd or 3rd retry.

If I monitor my ST logs I am also unable to see any indication of a failure, but I conclude that this is because we get a timeout on the connect call to ST. And since ST don’t know anything about a timed out connection nothing is logged.

Could perhaps the connect function be verified or robustified?

UT

[sgupta999]

I guess when it errors out one could technically program some retries.
your should be seeing errors on the server side in the log and error.log files - can you check if those are the errors you are actually gettting.

Like most people have reported most of the time a reboot reboot of ST fixes this error.

my development environment is completely shot so I cannot test but in the test directory i have uploaded a mbs-server-retries.js. download that and rename it to mbs-server.js and see if that helps - i have added 5 retries. like i said have not tested it so could faile even if i had a typo - i checked so hopefully no syntax or typos

[pittbull]

Thanks for reporting back, but as of right now I have not migrated to your fork yet, so I am unable to test.

How much reconfiguration needs to be done should I install yours?