apostolakisl

Did you have a backup of your ISY994? Hopefully yes. You should be able restore that backup to EISY and have most systems functioning again. Depending on how you had the IP address assigned you may need to do something there so that EISY is on the same IP as before (only necessary if you had other devices set to talk to ISY at its IP address). There may be issues if your backup (assuming you have one) is on a somewhat distant firmware version. But regardless, restoring the backup would be the first step and then you would implement any corrections that may be needed after that.

If you are getting the 24v adapter and standard smart thermostats, what is it you are needing? There are several brands of smart thermostats that have node servers, If you pick one of them, you should be good. Though I would be surprised if you ever came close to recovering the cost of buying 8 smart thermostats with electricity savings. I would speculate you are spending $2000 to get 8 smart thermostats plus whatever the 24v adapters cost.

Just know that if you used an integer variable for $night that it will not be a trigger where "from sunrise/sunet" statement is a trigger so it will behave diffeently. If you use a state variable, it will be identical. I would also suggest you use the naming convention of placing an "i" on all of your integer variables and an "s" for state. ie $iNight or $sNight It is helpful for yourself and also when you post to the forum with questions everyone will know.

The question is do any other programs run. You know that one runs correctly because you put notifications in the "then" and "else" clause already and tested, as I believe you stated a few posts ago. If indeed you received the correct notification showing that the correct clause ran, then it is something else that is turning the light on and that is what you need to look for.

The quickest way to find out is to watch the program summary page while opening the door and see which programs trigger. Click on the "last run time" column to sort by most recent run time.

@CoolToys I understand your use of variables, I usually use cascading programs instead for that, often having program 2 disable program 1 and then reenable it when complete. However, there is still no need to convert "dark outside" program to a variable. Since the state of the program works exactly the same as the actual sunrise to sunset clause, anywhere you used sunrise/sunset clause, the dark outside program status will produce identical results.

@CoolToys You don't need any variables. You just use the true/false status of the program dark outside (see my example). You would only need to use a variable (an integer one) if you didn't want the sunrise/sunset times themselves to be triggers. Mostly this would be the case if you have items in your "else" clause that you don't want running at sunrise/sunset times. Whenever you "and" sunrise/sunset times to another condition (either through a dark outside program or directly in the program), getting triggered at sunrise/sunset won't matter provided the else clause is empty. Using a "Dark outside" program like I did works exactly the same as putting sunrise/sunset times in the actual program, but it is simpler if you have a bunch of programs that use sunrise to sunset (or vice versa) logic since it is now just a single line. Sunrise/Sunset times are triggers when in a program, and a program changing status is also a trigger when that status is referenced in another program. So it is the same exact behavior. If you got the correct notifications of the program running true/false, then you must have some other program or scene doing something.

@CoolToys Changing the order of the conditions when they are all "anded" will not have any affect. I would start with adding an email or text notification to your "then" and a different one to your "else" and then you will be able to follow the program's every execution. This will confirm if it is running incorrectly. If indeed it is running incorrectly, which would be a new one for ISY, I would delete the sunrise to sunset clause, save it, then re-add that condition and save again. I also have the Elk node and I have a Polisy, while not eisy, it is still running the same code. I do not use the sunset to sunrise in individual programs. I have a single program called "dark outside" that just says from sunset to sunrise the next day. It has no then/else clauses. Then all other programs that I want to only run while it is dark outside simply reference that program's status as true or false. This works. I have a number of programs that perform the same function. Below is an example. Patio Door - [ID 000F][Parent 0013] If Program 'Dark Outside' is True And 'Elk / Family Rm Door' Logical Status is Violated Then Set 'Family Room / Patio-FamRm-Fans Coach Lts L' On Else - No Actions - (To add one, press 'Action')

All good info, but I would also like to point out that the "if status light off" element of the program isn't needed at all. If the light is already on, and you send an on command to it, big whoop, nothing happens. You would only need that line if say the light being at some partial level of on meant you wanted it to stay at the level and not turn all the way on when the door opened.

Yes, indeed. This would make looking at the last status of the program ineffective. You can always add a line in the then clause that sends you an email or sets a test variable. I don't know what the variable that is already there is doing and what other programs might affect it so not sure if you could use that. You could also add a line in the else clause that does similar. In summary, I really don't think this program is turning the lights on. The only other thought is that the ISY clock is set wrong. I really doubt ISY is having a logic fail like this.

I can't explain your issue. Since all "if" statements are "anded", then any of them being false would make the whole thing false and it would run the "else" clause (which of course is blank). Please confirm that this actual program is what is turning on the lights and that you do not have another program lingering somewhere that maybe you were working on and forgot about. If you look at the program tree, the program will have a half red icon to the left of it if it last ran false and half green if it last ran true. The program summary page will also list it along with last run time and true/false. Try opening the door, then sort your program summary page by time last ran and see if some other program ran at that time and turned the lights on.

Seems I answered my own question. Indeed, there is a separate node for heat/cool state that is not listed on the summary page. It is found in programs under status/thermostat name (just the name, not cool ctl or heat ctl which even though they are control functions still have a "state" which is always the last control command received by ISY and can not be corrected via a query).

I have a bunch of Venstar thermostats with Insteon attachment at my church. I have noticed an issue where the HVAC unit will be in one state (ie cooling) and it will say it is cooling when you look at the device in the admin console. But when you click on the folder and see the page that lists everything in the folder, on that page it will say the unit is off. In addition, programs that should be running when the device is cooling will not be running. If I shut the unit down, then turn it back on, it will then be correct. This is sporadic and happens across the board on different units seemingly randomly. Below are the pages I am referring to. Now at this time, the pages are in agreement, but a few minutes ago they weren't. I had to shut the unit down for a minute and turn it back on, now they agree. Prior to that, the summary page showed "off" as the cool control current state for unit "upstairs south". But the device page showed "cooling" in the heating/cooling box. And indeed, the unit was cooling. Are there different nodes for these things even though they seem to be the same node? I have noticed that sometimes the "control on" command is a missed com to the PLM, and because of that, I have ISY set to run queries of the units every 15 minutes which corrects the device specific page to say "cooling" or "idle", but it does not correct the summary page and it does not cause programs that look for the state of the unit to run. Here is my summary page: Here is my device page

Nodelink works a little different. It is installed into ISY as a single node, however, you can have lots of sub nodes under that single ISY node and they all show up in ISY tree as if they were separate nodes (but under the "node servers" tab, it is just one node). In my case, ISYlink (for whatever reason the name on ISY node server tabs is "ISY Link" instead of "nodelink") it is node number 1. I currently have 3 nodes running on nodelink, 2 of which produce heartbeats (CAI webcontrol and DSC alarm). There is no setting to disable the heartbeats as far as I can find. I also have nodelink running on a 994i at my church. I have never had any issues with it. That ISY is on 5.0.16c firmware and has gone without a reboot now for almost a year and runs perfectly. I have had nodelink running for many years (probably going on 10) and I am not aware of any updates to nodelink in a very long time. Nodelink predates the existence of polyglot by quite a long time. This problem on the other hand is quite recent, just in the past few months, which makes me curious how something that didn't change would now change its behavior. The problem is also hard to predict. It has not happened now in almost a month. Prior to that, it went a couple weeks. Right after the most recent event, a new version of the polisy firmware came out and I installed it. So I don't know if that has anything to do with everything working now for a month. I do not know much about sockets. I assume there is some back and forth acknowledgement? I suppose an outsider requests a socket, and the ISY grants it. But is there an acknowledgement? Does the outsider get confirmation of an open socket and then continue to use the same socket? Does the outsider just send whatever packet it is sending and then close the socket until the next time it has data to send?

Sorry, not sure what you mean. If nodelink is connected it alternates the value of "heartbeat" value free 1 to -1 every 30 seconds. If heartbeat value doesn't change that means the node is either not working or not connected.

@Geddy Win10pro Interestingly, for the last few months, I wasn't able to use IoX either. I have to use the java console you access from ISY itself. And then after this update, java just wouldn't open at all. And just now, windows is showing another update. UHGGGG!

I wanted to share this in the IoX launcher, but it is locked. I was getting this error after doing a windows update, java update. I did the usual clearing of the temporary files/applets. Still go the error. Tried using windows control panel to delete Java and resinstalled from the Java website, same story. Unchecked and checked keep temporary files box and still. Finally, I fixed it by using the Java website's uninstaller and the offline installer. https://www.java.com/download/help/troubleshoot_java.html Perhaps this may save someone some time in the future.

Using Open Weather to do the same thing and mine works fine. Both Subject and Body. This is PG2. Guess they started using crazy strings for the address of the node instead of words like "weather".

Background: Polisy 5.6.2 (now .3); Nodelink 0.10.6 with 3 nodes DSC, CAI Webcontrol, and Date Data. Nodelink runs on 24/7 PC win10 that also runs blue iris and nothing else. Nodelink has been running for perhaps a decade on that PC. Nodelink predates Polisy by many years and was formerly connected to a 994i. It never had issues on 994i, or for the first couple years or so on Polisy. (I bought one of the very first Polisy units). Problem. In the past couple months I have had several incidents where ISY is having issues. First symptom is ISY stops getting updates from nodelink and a minute or so later I'll get an email from ISY that it has missed heartbeats from nodelink. After a while UD Mobile will lose its connection. I will not be able to connect from the admin console, it gets stuck on "starting subscription" and connections to PG2 and PG3 stop working as well. Michel logged in and says nodelink is leaving hundreds of abandoned open sockets that are blocking ISY from talking to other stuff. SSH does continue to work and Michel was looking at Polisy via SSH during the issue. ISY otherwise seems to keep running programs and doing things that it normally does via Insteon. ISY also continues to send emails every half hour as directed telling me that it is missing heartbeats even after all the other stuff goes down. I have continued to do updates to Polisy and this all seemed to start after an update not long ago from one version of 5. something to 5. something else (I forget exactly). The most recent incident ISY was on 5.6.2 but prior to that it happened on a previous 5 version. Of course there are PG updates and OS updates for Polisy that go along, but I don't know those version numbers. Nodelink has not changed. I have had that computer doing periodic windows updates but otherwise nothing much happens there for years. I don't really know much about sockets. My feeling here based on the timing of things, as gradually more and more things that use IP to communicate with ISY go down, is that for some reason nodelink starts opening more and more sockets until ISY can no longer talk via IP to other stuff. I don't know why nodelink would do this. Does nodelink open a socket and then get no response so it opens another? Or is nodelink just going nuts and opening sockets for no reason? And why does it just start doing this. . . .most recently at 11:06 yesterday with the other stuff connected to ISY totally crashing about a half hour later. Thanks!

The name "insteon" is a product of how fast the com is (like instant?). And in fact, it does pretty much live up to the name. A program can be quick, but it will sometimes take a second or more. You can easily see how fast Insteon works when you have a scene of switches and you push one of the paddles in the scene that is not the load switch, and yet, from a human perspective, it seems to be instant, as though you were pushing the load switch. This is certainly something that Insteon has over other technologies like Zwave. Anyway, if you are OK with the on time to be the same during the day or night and just want the brightness to be different, I would do it the way I just showed. Some have argued that re-writing the memory on the switches twice a day can "wear it out", but that does not appear to be an actual concern. The memory chips on Insteon devices do not seem to "wear out", the other stuff will be their demise (mostly caps).

In that case, this is totally something that you would do with direct links and just re-write the scene attributes with a program but let the motion sensor run all the on/off commands directly. I have a MS in my pantry that controls two devices. I wrote this program to show how I would make the MS turn the lights on to 50% while the sun is down and 100% while it is up. The actually turning on/off of the scene is directly controlled by the MS. New Program - [ID 001B][Parent 0093][Not Enabled] If From Sunrise To Sunset (same day) Then In 'Kitchen / Pantry Motion' Set 'Kitchen / Pantry - Light L' To 100% in 0.5 seconds, 1 retry In 'Kitchen / Pantry Motion' Set 'Kitchen / Pantry - Undercabinet L' To 100% in 0.5 seconds, 1 retry Else In 'Kitchen / Pantry Motion' Set 'Kitchen / Pantry - Light L' To 50% in 0.5 seconds, 1 retry In 'Kitchen / Pantry Motion' Set 'Kitchen / Pantry - Undercabinet L' To 50% in 0.5 seconds, 1 retry

It just seems to me that giving up the 15 second difference between night and daytime is trivial and would allow you to directly link the devices. Direct link will work faster, use less resources, and be more obvious to edit in the future when you forgot about this program because it is buried in with a hundred other programs. If you wanted to do something different night vs day, you could write a program that changes the on level and/or ramp rate at day vs night.

I wouldn't use programs to do any of this. Just make a scene with the motions sensors as controllers and set the motion sensor to 20 or 30 or 40 seconds timeout, or whatever you want (sorry, can't do 35). Not sure why you need to have the daytime timeout to be 15 seconds different from the nighttime one. Seems like a needless complication. But if indeed you do, you can have a program re-write the scene at sunset/sunrise. But if you want to keep the programs, probably you need to set the motion sensor to "report on only" commands.

I would expect "control" to work fine as the program is written. But the MS I have heard have some funny things. I have two of them but have them directly linked to the lights and use the time out from the MS. Basically, all default settings and used ISY to just link to the light switch, no programs. Work great for a pantry and laundry room where you are carrying things in and out and don't have free hands. And as long as you move around at least a little bit, the light stays on. But back to the OP, if he follows the status of the program in the admin console to completion, he will at least know where things are going wrong.

@photogeek54 I tried my key as well on Tuesday when you posted this and it didn't work. Then I tried it today, and it did work. I was able to use the 3.0 version very shortly after creating the key, but the 2.5 just started working now, after like 10 days or maybe more.