larryllix Posted January 25, 2018 Posted January 25, 2018 I discovered lots of lines of "Can't contact ISY" so I just rebooted NodeLink to clean it off with a fresh start = no error list. Lost all previous knowledge of ISY, and of course all devices. config.xml was fresh and raw.= about 10 lines Thank gawd for your config-bak.xml file process! rm config.xml cp config-bak.xml config.xml reboot NodeLink from it's webpage. all good!
Toddimus Posted January 25, 2018 Posted January 25, 2018 Interesting! I didn't have any problem with NodeLink's config. It survived the firmware update on my system.
larryllix Posted January 25, 2018 Author Posted January 25, 2018 Interesting! I didn't have any problem with NodeLink's config. It survived the firmware update on my system. Did you actually view the file, and/or reboot NodeLink after?
Toddimus Posted January 25, 2018 Posted January 25, 2018 I rebooted Nodelink (and actually my whole Synology NAS with all of the Docker Nodeservers/Polyglot running on it). Everything came back up nicely.
larryllix Posted January 25, 2018 Author Posted January 25, 2018 Weird! My NodeLink thinks it's is a virgin every (well some) system hiccoughs and starts the config over again for some reason.
Bumbershoot Posted January 25, 2018 Posted January 25, 2018 Weird! My NodeLink thinks it's is a virgin every (well some) system hiccoughs and starts the config over again for some reason. I upgraded to 5.0.11C just after it was released, after which all my Nodelink nodes were fine. I reboot both Nodelink and Polyglot every morning via crontab on my Pi, but I've never seen the problem you're having. I keep my version of Mono updated via regular updates. 2018-01-25 03:43:01 - ISY NodeLink Server v0.9.1 started 2018-01-25 03:43:02 - Mono version: 5.4.1.7 (tarball Wed Jan 17 22:33:48 UTC 2018) 2018-01-25 03:43:02 - ISY resolved to 192.168.1.20 2018-01-25 03:43:02 - ISY Node Server config detected (profile 2) The thing just runs...
larryllix Posted January 25, 2018 Author Posted January 25, 2018 I upgraded to 5.0.11C just after it was released, after which all my Nodelink nodes were fine. I reboot both Nodelink and Polyglot every morning via crontab on my Pi, but I've never seen the problem you're having. I keep my version of Mono updated via regular updates. 2018-01-25 03:43:01 - ISY NodeLink Server v0.9.1 started 2018-01-25 03:43:02 - Mono version: 5.4.1.7 (tarball Wed Jan 17 22:33:48 UTC 2018) 2018-01-25 03:43:02 - ISY resolved to 192.168.1.20 2018-01-25 03:43:02 - ISY Node Server config detected (profile 2) The thing just runs... Scyto had the same file problem using mono 5.4.1.? My RPi3 has been stuck at Mono version: 5.2.0.215 (tarball Mon Aug 14 16:25:12 UTC 2017) for months now and doesn't upgrade any further. This has only happened to me on three rare times. The first time when I clicked on the logging option, the whole RPi3 hung and the file was gone. Was there another way to force encourage an update of mono?
Bumbershoot Posted January 25, 2018 Posted January 25, 2018 Scyto had the same file problem using mono 5.4.1.? My RPi3 has been stuck at Mono version: 5.2.0.215 (tarball Mon Aug 14 16:25:12 UTC 2017) for months now and doesn't upgrade any further. This has only happened to me on three rare times. The first time when I clicked on the logging option, the whole RPi3 hung and the file was gone. Was there another way to force encourage an update of mono? I've always been a bit leery of forcing updates, as I've had bad experiences in the past with dependencies getting borked/broken. It's the *nix version of DLL hell. My 2¢, don't do it. That said, you can use the '--force-yes' option for apt-get. From the apt-get man page: --force-yes Force yes; this is a dangerous option that will cause apt to continue without prompting if it is doing something potentially harmful. It should not be used except in very special situations. Using force-yes can potentially destroy your system! Configuration Item: APT::Get::force-yes. I'd do a couple of things: make certain I had the correct/current repositories for Mono: pi@raspberrypi:/etc/apt/sources.list.d $ more mono-official.list deb http://download.mono-project.com/repo/debian raspbianjessie main If that's current, then you've likely got some outdated dependency that's keeping Mono stale. Have you recently done the 'sudo apt-get update; sudo apt-upgrade; sudo reboot' routine is a while? EDIT: Beyond that, maybe trying to uninstall Mono will reveal a dependency that's gumming up the works? I'm better than 10 years out from my Linux sysadmin days, so I'm bound to be missing something.
larryllix Posted January 25, 2018 Author Posted January 25, 2018 I've always been a bit leery of forcing updates, as I've had bad experiences in the past with dependencies getting borked/broken. It's the *nix version of DLL hell. My 2¢, don't do it. That said, you can use the '--force-yes' option for apt-get. From the apt-get man page: --force-yes Force yes; this is a dangerous option that will cause apt to continue without prompting if it is doing something potentially harmful. It should not be used except in very special situations. Using force-yes can potentially destroy your system! Configuration Item: APT::Get::force-yes. I'd do a couple of things: make certain I had the correct/current repositories for Mono: pi@raspberrypi:/etc/apt/sources.list.d $ more mono-official.list deb http://download.mono-project.com/repo/debian raspbianjessie main If that's current, then you've likely got some outdated dependency that's keeping Mono stale. Have you recently done the 'sudo apt-get update; sudo apt-upgrade; sudo reboot' routine is a while? EDIT: Beyond that, maybe trying to uninstall Mono will reveal a dependency that's gumming up the works? I'm better than 10 years out from my Linux sysadmin days, so I'm bound to be missing something. Yes. I do the update/upgrade every month or two if I think of it, along with my play RPI3, more frequently. Just found another event from installing v5.0.11c and rebooting ISY, exactly the same as happened the other times when the config.xml file got wiped out. It set my ecobe4e down to 16 degrees again. Ecobee event charts show the time match. I was sitting here wondering why it was getting cold in here. The cooler air drop down the staircase right onto my legs. Thanks for the bash lines!
Bumbershoot Posted January 25, 2018 Posted January 25, 2018 Yes. I do the update/upgrade every month or two if I think of it, along with my play RPI3, more frequently. Just found another event from installing v5.0.11c and rebooting ISY, exactly the same as happened the other times when the config.xml file got wiped out. It set my ecobe4e down to 16 degrees again. Ecobee event charts show the time match. I was sitting here wondering why it was getting cold in here. The cooler air drop down the staircase right onto my legs. Thanks for the bash lines! I found this on the mono-project site. Might be of some help with the current repositories. To get your Debian version #: pi@raspberrypi:~ $ cat /etc/debian_version 8.0 pi@raspberrypi:~ $
paulbates Posted January 25, 2018 Posted January 25, 2018 I rebooted Nodelink (and actually my whole Synology NAS with all of the Docker Nodeservers/Polyglot running on it). Everything came back up nicely. Todd Watching docker from afar. I thought one of the benefits for using docker, like VMs, was software (stack) isolation and that you can discretely manage software instances without rebooting the HW(?) My "prod" pi/linux setup is very basic, just nodelink, so I've shied away from adding docker for a single function prod server. I can quickly copy my current config.xml to my "dev" pi and un-comment a few lines on its rc.local and be back in business were anything to happen. Paul
Bumbershoot Posted January 25, 2018 Posted January 25, 2018 My "prod" pi/linux setup is very basic, just nodelink, so I've shied away from adding docker for a single function prod server. I can quickly copy my current config.xml to my "dev" pi and un-comment a few lines on its rc.local and be back in business were anything to happen. Same here, just Nodelink and Polyglot on an RPi3. It handles them both easily and is simple to manage. I want to play with Docker, but there's no production advantage I see in this setup.
Bumbershoot Posted January 25, 2018 Posted January 25, 2018 I was sitting here wondering why it was getting cold in here. The cooler air drop down the staircase right onto my legs. Motivation to get this fixed! The Mrs. here would be all over it!
Toddimus Posted January 25, 2018 Posted January 25, 2018 Todd Watching docker from afar. I thought one of the benefits for using docker, like VMs, was software (stack) isolation and that you can discretely manage software instances without rebooting the HW(?) My "prod" pi/linux setup is very basic, just nodelink, so I've shied away from adding docker for a single function prod server. I can quickly copy my current config.xml to my "dev" pi and un-comment a few lines on its rc.local and be back in business were anything to happen. Paul Yeah, it's nice to be able to stop/start/restart the docker instance without having to reboot the hardware. Also, if you screw something up, it is much easier to recover from because you just use the image you downloaded that already has all of the addons you previously specified. With the RPi, I've had to get a new Raspian image and then do all of the update/upgrade stuff, then load the software packages, which can take >1 hour. With docker, it's literally a few minutes. I had been using a couple of RPis for NodeLink, Polyglot and OpenHAB. Another benefit of running docker on my Synology NAS is that it has a quad core Intel chip on it that runs much faster so restarting a docker container is quicker too. This especially matters when doing stuff with OpenHAB because it is much more processor intensive than Polyglot or NodeLink. There is a little bit of a learning curve with docker but it's really not too bad. You create the text file for your dockerfile and maybe a docker-yaml file and run a few command lines on SSH and you're good to go.
larryllix Posted January 25, 2018 Author Posted January 25, 2018 Motivation to get this fixed! The Mrs. here would be all over it! Unfortunately I had the minimum stat, setpoint allowed, to 16C as well as my vacation setpoint. Without the vacation indicator on the screen (I only saw "Hold 16c until 11:00 PM") I have to conclude it was set to the lowest setting allowed somehow. The next thing this brings up is when setting the setpoint remotely (ISY?) below the setpoint allowance range, what happens? I really doubt anything could keep decrementing the setpoint until it bottomed out. That takes more intelligence than I can see happening. Some more experimenting is necessary here.
io_guy Posted January 25, 2018 Posted January 25, 2018 I'm changing the topic name - the ISY has nothing to do with this.
Bumbershoot Posted January 25, 2018 Posted January 25, 2018 Unfortunately I had the minimum stat, setpoint allowed, to 16C as well as my vacation setpoint. Without the vacation indicator on the screen (I only saw "Hold 16c until 11:00 PM") I have to conclude it was set to the lowest setting allowed somehow. The next thing this brings up is when setting the setpoint remotely (ISY?) below the setpoint allowance range, what happens? I really doubt anything could keep decrementing the setpoint until it bottomed out. That takes more intelligence than I can see happening. Some more experimenting is necessary here. I don't see how your Nodelink config disappearing would do anything to the stat, much less rejigger a setpoint. It would have to have been set otherwise. In situations like this, a view-able history file/log would be handy on these devices (though I can understand why companies don't make these available to general consumers - can you imagine the support calls something like that might generate?) Maybe only for ISY users...
larryllix Posted January 25, 2018 Author Posted January 25, 2018 I don't see how your Nodelink config disappearing would do anything to the stat, much less rejigger a setpoint. It would have to have been set otherwise. In situations like this, a view-able history file/log would be handy on these devices (though I can understand why companies don't make these available to general consumers - can you imagine the support calls something like that might generate?) Maybe only for ISY users... Very strange one, This is the third time my config.xml file was wiped out. My stat was set to 16C at the same time at least two of those times for both events. This may have happened the third time but I do not recall if the stat was set to 16C that time.
larryllix Posted January 25, 2018 Author Posted January 25, 2018 OK. I ran a few tests. Rebooted ISY with no ill effects. ISY has been rebooted several times in the past without event. The reboot in question was an automated one after installing the new version 5.0.11C so many more ISY things were happening in that instance. I wrote a small test program to send 5C degrees heat setpoint to ecobee4 via NodeLink. This is below the stat setpoint allowance inside the ecobee4 and it resulted in "Hold 16C until 11:00 PM" on the ecobee4. I wrote a small test program to send 0C degrees (variable value) heat setpoint to ecobee4 via NodeLink. This is below the stat setpoint allowance inside the ecobee4 and it resulted in "Hold 16C until 11:00 PM" on the ecobee4. Conclusion: Sending a below the ecobee4 "setpoint range limit" from ISY to to ecobee4, results in the minimum temperature being set. This is the setting I found in both cases.
Bumbershoot Posted January 26, 2018 Posted January 26, 2018 OK. I ran a few tests. Rebooted ISY with no ill effects. ISY has been rebooted several times in the past without event. The reboot in question was an automated one after installing the new version 5.0.11C so many more ISY things were happening in that instance. I wrote a small test program to send 5C degrees heat setpoint to ecobee4 via NodeLink. This is below the stat setpoint allowance inside the ecobee4 and it resulted in "Hold 16C until 11:00 PM" on the ecobee4. I wrote a small test program to send 0C degrees (variable value) heat setpoint to ecobee4 via NodeLink. This is below the stat setpoint allowance inside the ecobee4 and it resulted in "Hold 16C until 11:00 PM" on the ecobee4. Conclusion: Sending a below the ecobee4 "setpoint range limit" from ISY to to ecobee4, results in the minimum temperature being set. This is the setting I found in both cases. Interesting. I don't understand, though, how a bailout by Nodelink, ISY or anything else would send an erroneous setpoint signal to the stat. Maybe some extraneous bits wind up on the network as Nodelink goes down that the ecobee understands as an illegal setpoint so it sets a minimum temperature. Seems pretty farfetched to me, but improper bounds checking, or a buffer overrun on the ecobee might allow for something like that to happen. When I look at my logs, it seems that Nodelink chatters quite a bit with the ISY and attached devices, so it's not impossible, I suppose. Obviously, I'm speculating and likely full of nonsense.
larryllix Posted February 1, 2018 Author Posted February 1, 2018 NodeLink, along with ISY reconfigure / reboot set my ecobee4 down to the minimum setpoint allowance again. Upgraded to NodeLink v0.9.3. Upgraded fine. Upon NodeLink reboot it complained my ISY setup file needed to be updated. The auto-update option was enabled but a wait period of a few minutes and another reboot still complained of setup outdated. Finally I clicked the Install Setup File in NodeLink and then clicked the Reboot ISY. ISY rebooted OK and I got all the usual notifications from ISY. The setup file mismatch has disappeared now on reboot of NodeLink. I did have to set my second ecobee3 [ecobee2] to the correct room name on the NodeLink device page, as advised. Thanks! When I went to acknowledge the notifications I noticed the ecobee4 [stat ecobee1] temperature setpoint was set down to 16C again. At least I found it right away, this time. The config.xml file must have been OK because NodeLink found everything OK.
io_guy Posted February 1, 2018 Posted February 1, 2018 Larry, if you're blaming your exobee setpoint on NodeLink or the ISY then give me a log. 47 ecobee NodeLink users and you're the only one this happens to.
larryllix Posted February 1, 2018 Author Posted February 1, 2018 Well I finally figured out how to install Mono version: 5.4.1.7 (tarball Wed Jan 17 22:33:48 UTC 2018) It takes a complete install and compile to upgrade it from 5.2.?. apt-get update + upgrade just doesn't do it. The reinstall process contunually reported installing over debian7?. I am running raspbian 8 apparently. Hopefully this will corect something here. The next few days should prove the two ecobee "array index out of bounds" errors still happening almost every 23:59:50 PM You have cleaned up all the other ecobee twists and quirks quite nicely. Here's to fingers crossed. Thanks so much.
io_guy Posted February 1, 2018 Posted February 1, 2018 If you're compiling mono you're doing something wrong. And i can promise you mono has nothing to do with your setback issue.
larryllix Posted February 1, 2018 Author Posted February 1, 2018 If you're compiling mono you're doing something wrong. And i can promise you mono has nothing to do with your setback issue. After several tries to upgrade mono and it never changed versions, I just followed the mono website instructions to upgrade mono, whatever that did for an hour or so. I can't see anything else that could cause the setpoint to be set to the lowest possible setpoint (Probably set to 0c) each time my ISY rebooted, three coincidental times now. Possibly a fourth time before I made note of it. Ecobee website ultimately could have initiated the low setpoint to l my stat but ecobee shouldn't know my when ISY was rebooted.
Recommended Posts
Archived
This topic is now archived and is closed to further replies.