io_guy Posted September 1, 2018 Posted September 1, 2018 The nameserver issue is unrelated to this one. Next version I'll dispose the client conpletely on an error to see if it helps. Problem is I have no info on what Honeywell's crappy server is doing. The "fixes" I'm doing go completely against standard coding practice. I don't see much wrong with your last log except for a crappy web server. You have 10 errors over 10 hours. An issue would be it constantly failing, but this one clearly recovers.
Scottmichaelj Posted September 1, 2018 Posted September 1, 2018 The nameserver issue is unrelated to this one. Next version I'll dispose the client conpletely on an error to see if it helps. Problem is I have no info on what Honeywell's crappy server is doing. The "fixes" I'm doing go completely against standard coding practice. I don't see much wrong with your last log except for a crappy web server. You have 10 errors over 10 hours. An issue would be it constantly failing, but this one clearly recovers. Well on this last log the downstairs Tstat didn’t “update” fully to all the info like upstairs. Edit: Meaning there is no current temp, set-point, humidity, etc. Last night I got a “timeout” error but both Tstat are still updated and seem to be working so I will keep my eye on which error stops the stats from having full info. I keep my system running (both upstairs and downstairs) 24/7 including the A/C right now.
Scottmichaelj Posted September 1, 2018 Posted September 1, 2018 Ok just got the “get status error” and lost my downstairs stat. It now doesn’t show temp/humidity etc. This is now when I have to reboot and when I do it will work again.
io_guy Posted September 5, 2018 Posted September 5, 2018 Think I found a bug with the StatusError. Will keeping running on my Pi and release something on the weekend.
Scottmichaelj Posted September 5, 2018 Posted September 5, 2018 Think I found a bug with the StatusError. Will keeping running on my Pi and release something on the weekend. Your the best, thank you.
Scottmichaelj Posted September 9, 2018 Posted September 9, 2018 Think I found a bug with the StatusError. Will keeping running on my Pi and release something on the weekend. NodeLink v0.9.20 and Honeywell TCC has been working and solid with zero issues since the update. Thanks again for looking at this and fixing it! What was the issue?
Scottmichaelj Posted September 19, 2018 Posted September 19, 2018 So running v.20 for 10 days now. Looks like this morning my upstairs tstat disconnected at 6am. Not sure why. Anyways just looking for feedback on how to best resolve things when this happens? Could we make a ISY program to check a "heartbeat" based on time and if its past that time limit we can send a network resource to restart NodeLink? I am suspecting these are not NodeLink issues but issues with the Honeywell TCC servers. That said my downstairs tstat still was working so it is interesting I just lost the upstairs rather than both, and that the upstairs never came back online. Here is my log: 2018-09-07 20:30:11 - ISY NodeLink Server v0.9.20 started 2018-09-07 20:30:11 - OS: Linux debian 4.9.0-6-amd64 #1 SMP Debian 4.9.88-1+deb9u1 (2018-05-07) x86_64 GNU/Linux 2018-09-07 20:30:11 - Mono version: 5.14.0.177 (tarball Mon Aug 6 09:13:21 UTC 2018) 2018-09-07 20:30:12 - Web config server started (http://192.168.0.130:8090) 2018-09-07 20:30:12 - ISY resolved to 192.168.0.81 2018-09-07 20:30:13 - ISY Node Server config detected (profile 2) 2018-09-11 12:25:40 - TCC Get StatusError - Forbidden [hwstat1] 2018-09-12 02:23:33 - TCC Get Error: Timeout [hwstat2] 2018-09-12 02:23:48 - TCC Get Error: Timeout [hwstat1] 2018-09-12 02:28:43 - TCC Get Error: Timeout [hwstat2] 2018-09-12 02:28:58 - TCC Get Error: Timeout [hwstat1] 2018-09-12 02:33:53 - TCC Get Error: The request was aborted: The request was canceled. [hwstat2] 2018-09-12 12:36:21 - TCC Get Error: Error: NameResolutionFailure [hwstat2] 2018-09-12 12:36:21 - TCC Get Error: No route to host [hwstat1] 2018-09-12 15:27:02 - TCC Get StatusError - Forbidden [hwstat2] 2018-09-12 18:17:43 - TCC Get StatusError - Forbidden [hwstat2] 2018-09-12 19:43:19 - TCC Get Error: Timeout [hwstat2] 2018-09-13 03:15:16 - TCC Get Error: Timeout [hwstat1] 2018-09-14 22:25:47 - TCC Get StatusError - Forbidden [hwstat2] 2018-09-14 22:25:47 - TCC Get StatusError - Forbidden [hwstat1] 2018-09-17 14:11:51 - TCC Get StatusError - Forbidden [hwstat1] 2018-09-18 08:35:41 - TCC Get StatusError - Forbidden [hwstat2] 2018-09-19 01:15:23 - TCC Get Error: Timeout [hwstat2] 2018-09-19 06:21:46 - TCC Get Error: Timeout [hwstat2] 2018-09-19 06:26:47 - TCC Get Error: Timeout [hwstat1] 2018-09-19 06:26:56 - TCC Get Error: Timeout [hwstat2] 2018-09-19 06:31:50 - TCC Get StatusError - InternalServerError [hwstat1] 2018-09-19 06:31:58 - TCC Get StatusError - InternalServerError [hwstat2] 2018-09-19 09:02:21 - TCC Get StatusError - ServiceUnavailable [hwstat1]
larryllix Posted September 20, 2018 Posted September 20, 2018 7 hours ago, Scottmichaelj said: So running v.20 for 10 days now. Looks like this morning my upstairs tstat disconnected at 6am. Not sure why. Anyways just looking for feedback on how to best resolve things when this happens? Could we make a ISY program to check a "heartbeat" based on time and if its past that time limit we can send a network resource to restart NodeLink? I am suspecting these are not NodeLink issues but issues with the Honeywell TCC servers. That said my downstairs tstat still was working so it is interesting I just lost the upstairs rather than both, and that the upstairs never came back online. Here is my log: 2018-09-07 20:30:11 - ISY NodeLink Server v0.9.20 started 2018-09-07 20:30:11 - OS: Linux debian 4.9.0-6-amd64 #1 SMP Debian 4.9.88-1+deb9u1 (2018-05-07) x86_64 GNU/Linux 2018-09-07 20:30:11 - Mono version: 5.14.0.177 (tarball Mon Aug 6 09:13:21 UTC 2018) 2018-09-07 20:30:12 - Web config server started (http://192.168.0.130:8090) <snipped> You have a heartbeat included in the NodeLink node? io_guy usually puts one in for sensitive data.
TJF1960 Posted September 20, 2018 Author Posted September 20, 2018 Just an FYI, heartbeat is included but it hasn't worked, for me anyway for quite a while. The program I have in ISY that monitors heartbeat hasn't run and every time I check the heartbeat it is always a 1. Never switches to -1. Again it may just be me. Its never bothered me so I just have never brought it up.
larryllix Posted September 20, 2018 Posted September 20, 2018 Here is a progrm I use for one of my ecobees. Note the multiple Wait timers. My programs want to know ASAP if the comm has failed (stale data) but me (yhe human) don'twant to be bothered with every hiccough. DinRm.Stat Comm.OK - [ID 009B][Parent 00CD][Run At Startup] If 'Dining Room / GathRm Stat' Heartbeat is 1 Or 'Dining Room / GathRm Stat' Heartbeat is -1 Then $GathRm.stat.updating = $cTRUE Wait 6 minutes <---allows two failures in a row plus a bit Run Program 'DinRm.Stat Comm.OK' (Else Path) <---Flag the program colour in A/C Else $GathRm.stat.updating = $cFALSE Wait 30 minutes $sAlarm.level = 1 <---- rings local noise makers Send Notification to 'Text Larry' content 'Device comm report' Send Notification to 'eMail Larry' content 'Device comm report' Repeat While $sHouse.vacation is $cFALSE Wait 8 hours <---rinse and repeat as urgency dictates Send Notification to 'Text Larry' content 'Device comm report'
io_guy Posted September 21, 2018 Posted September 21, 2018 23 hours ago, TJF1960 said: Just an FYI, heartbeat is included but it hasn't worked, for me anyway for quite a while. The program I have in ISY that monitors heartbeat hasn't run and every time I check the heartbeat it is always a 1. Never switches to -1. Again it may just be me. Its never bothered me so I just have never brought it up. Yep, that's a bug. Looks like I never put the code in for it to work. Fixed in next release.
Scottmichaelj Posted September 26, 2018 Posted September 26, 2018 Honeywell’s 'smart' thermostats had a big server outage and a key feature stopped working entirely — and customers were furioushttps://www.businessinsider.com/honeywell-iot-thermostats-server-outage-2018-9
giesen Posted September 26, 2018 Posted September 26, 2018 Local APIs FTWSent from my SM-N9500 using Tapatalk
larryllix Posted September 26, 2018 Posted September 26, 2018 13 hours ago, Scottmichaelj said: Honeywell’s 'smart' thermostats had a big server outage and a key feature stopped working entirely — and customers were furioushttps://www.businessinsider.com/honeywell-iot-thermostats-server-outage-2018-9 ...and yet the cloud to cloud propaganda continues to hook customers into addition to their "good-will" services.
io_guy Posted September 30, 2018 Posted September 30, 2018 Yea I don't really understand it. All these companies could easily write a local API in a few days. But they don't and they don't charge for their crappy cloud APIs. Only thing I can see - they make money from selling your usage data to 3rd parties.
paulbates Posted September 30, 2018 Posted September 30, 2018 I think its one of the general appeals of cloud software development: Companies can code and implement capabilities in a cloud environment and skip the pain of instructing and supporting thousands of users about how to download and upgrade. New capabilities easily introduced in a cloud API without touching user devices. There is one positive example; look at the ISY portal.. new capabilities continue to be introduced in the cloud that I can use on my ISY with no requirement to upgrade my ISY. I started using Alexa, IFTT, geofencing and remote Admin Console access without touching my ISY (outside of first authorizing the portal capability). But that's not a risk I'll accept for key devices. I follow @giesen's perspective. I don't care if an iot device has an optional cloud component. But for something critical like HVAC control, the conversation with the ISY requires a local API and is not leaving the house: I don't want what happened in this story to happen to me I don't get internet outages often, but they happen and want local management functions programmed in the ISY to work In my case, Venstar and Rainmachine can stop supporting their products I bought, or even go out of business; I'm still running. Paul
larryllix Posted October 1, 2018 Posted October 1, 2018 I think these cloud based companies just want control of everything....just in case. Most don't seem to know what the case would be, but they don't want to relinquish control. If they ever sold their product and you already gave it all away what would it be worth to the prospective buyer? Not much. Many of these online companies live to develop a great product and have google or microsoft come along and buy them for $XXX million before the politics become expensive. Many products have been bought, in the past with the intention ot make the product disappear.
Scottmichaelj Posted October 15, 2018 Posted October 15, 2018 Still having Honeywell TCC update errors. I have not updated Mono but I did update before to the newest at the time. I saw the other thread about mono issues so you think I should update or leave it alone? Upstairs is was fine. Reboot fixed it again. Any thoughts on what to do to fix this from keep happening?
io_guy Posted October 15, 2018 Posted October 15, 2018 Don't update mono. Strange how it recovered a number of times until the 10-13. Why do you say upstairs is fine, both stats show the timeout?
Scottmichaelj Posted October 15, 2018 Posted October 15, 2018 4 minutes ago, io_guy said: Don't update mono. Strange how it recovered a number of times until the 10-13. Why do you say upstairs is fine, both stats show the timeout? When I went into each stat via NodeLink (upstairs and downstairs) the upstairs stat showed that it was updated today and was correct however the downstairs stat wasnt updated since the 12th. I wont touch my mono Thank you. Strange huh? Downstairs hwstat1 Honeywell Thermostat Upstairs hwstat2 Honeywell Thermostat
io_guy Posted October 15, 2018 Posted October 15, 2018 Odd, hwstat2 has more errors in the log. I don't see anything special in the log dealing with why hwstat1 stopped updating. And the loop is still running since you're seeing timeouts on hwstat1 on 10-13.
Recommended Posts
Archived
This topic is now archived and is closed to further replies.