Honeywell TCC: Timeout

[Scottmichaelj]

Anyone else noticing that Honeywell TCC timeouts after a while? I am not sure how fast it happens, I am going to keep an eye on it. However I have now had two times when I went back into NodeLink it showed Timeout. When I reboot NodeLink it works again. I don't have to update or do anything after the reboot. Thoughts? I will work out getting a log file. Never had to get it so will look into the instructions how to get it from Debian.

[paulbates]

Its not limited to Honeywell. I have Venstar but I have similar symptoms. Mono has a leak and keeps taking memory from the system. Eventually linux shuts mono down, taking nodelink with it. The way to validate this is use the "top" command and keep a tab on the "Free" value. It will continue drop over time, until it stops. 

One problem, I was attempting to use SSL between my devices and nodelink. io_guy advised turning that off and it helped, but still does leaks at a slower pace and in few weeks dies. 

[Scottmichaelj]

Its not limited to Honeywell. I have Venstar but I have similar symptoms. Mono has a leak and keeps taking memory from the system. Eventually linux shuts mono down, taking nodelink with it. The way to validate this is use the "top" command and keep a tab on the "Free" value. It will continue drop over time, until it stops. 

One problem, I was attempting to use SSL between my devices and nodelink. io_guy advised turning that off and it helped, but still does leaks at a slower pace and in few weeks dies. 

 

Thanks for the info Paul. Have you looked into how to create a script to auto reboot NodeLink every night or so? I will have to research as I am not Linux savvy. Not a fix but maybe a workaround for now.

[paulbates]

I'm in the same boat Scott. I've looked around and see some options for process supervision, but haven't wanted to start messing with it yet.

For some reason the restart button from Nodelink stops nodelink but the process doesn't restart. Could be my system, not sure, but I only run nodelink, nothing else.

[Scottmichaelj]

I'm in the same boat Scott. I've looked around and see some options for process supervision, but haven't wanted to start messing with it yet. For some reason the restart button from Nodelink stops nodelink but the process doesn't restart. Could be my system, not sure, but I only run nodelink, nothing else.

 

 

I am running NodeLink on a VM with Polyglot v2. There has to be a way to restart NodeLink service somehow via script. Once I restart NodeLink via the admin page it works again. Again not sure how long.

 

Edit: FWIW as of this post NodeLink has been running for 6 hours and still working. I’ll keep an eye on it and post back. Maybe a simple cron job to restart every night at midnight?

 

[Bumbershoot]

45 minutes ago, Scottmichaelj said:

 

I am running NodeLink on a VM with Polyglot v2. There has to be a way to restart NodeLink service somehow via script. Once I restart NodeLink via the admin page it works again. Again not sure how long.

 

Edit: FWIW as of this post NodeLink has been running for 6 hours and still working. I’ll keep an eye on it and post back. Maybe a simple cron job to restart every night at midnight?

 

Provided you manage Nodelink with systemctl, then you can restart Nodelink with cron job that looks something like this (the service file being called by the cron is '/etc/systemd/system/nodelink.service'):

# Edit this file to introduce tasks to be run by cron.
# 
# Each task to run has to be defined through a single line
# indicating with different fields when the task will be run
# and what command to run for the task
# 
# To define the time you can provide concrete values for
# minute (m), hour (h), day of month (dom), month (mon),
# and day of week (dow) or use '*' in these fields (for 'any').# 
# Notice that tasks will be started based on the cron's system
# daemon's notion of time and timezones.
# 
# Output of the crontab jobs (including errors) is sent through
# email to the user the crontab file belongs to (unless redirected).
# 
# For example, you can run a backup of all your user accounts
# at 5 a.m every week with:
# 0 5 * * 1 tar -zcf /var/backups/home.tgz /home/
# 
# For more information see the manual pages of crontab(5) and cron(8)
# 
# m h  dom mon dow   command
43 3 * * * systemctl restart nodelink >/dev/null 2>&1
27 3 * * * systemctl restart polyglot-v2 >/dev/null 2>&1
55 3 * * * systemctl restart weatherflow >/dev/null 2>&1

Nodelink restarts at 3:43 am every day.  Restarting Polyglot like this prevents it from properly rotating it's logs, but I haven't seen any problems with Nodelink.

'sudo crontab -e' should bring up an editor that will allow you to edit the crontab file.

[io_guy]

8 hours ago, paulbates said:

I'm in the same boat Scott. I've looked around and see some options for process supervision, but haven't wanted to start messing with it yet.

For some reason the restart button from Nodelink stops nodelink but the process doesn't restart. Could be my system, not sure, but I only run nodelink, nothing else.

What devices do you have installed?  Without https enabled on RainMachine I can run months without any memory issues (on a Pi3).

I run DSC, CallerID, ISY Data, Ecobee, GEM, MiLight, Modbus, OWFS, RainMachine and the Relay Server.

[paulbates]

13 minutes ago, io_guy said:

What devices do you have installed?  Without https enabled on RainMachine I can run months without any memory issues (on a Pi3).

I run DSC, CallerID, ISY Data, Ecobee, GEM, MiLight, Modbus, OWFS, RainMachine and the Relay Server.

1 Rainmachine, 2 ventars.. and I also use ISYData.

Paul

[io_guy]

10 hours ago, Scottmichaelj said:

Anyone else noticing that Honeywell TCC timeouts after a while? I am not sure how fast it happens, I am going to keep an eye on it. However I have now had two times when I went back into NodeLink it showed Timeout. When I reboot NodeLink it works again. I don't have to update or do anything after the reboot. Thoughts? I will work out getting a log file. Never had to get it so will look into the instructions how to get it from Debian.

I'll make the HTTP Client short-lived for this device, doesn't need to stay alive since the underlying OS will drop the socket anyway with the slow poll rates used.  That should kill the session with each request to avoid any stalled timeouts.

[Scottmichaelj]

Well it seems I cant keep TCC from timing out. Bummer ?

[io_guy]

See my post above.