apostolakisl

ISY evaluates time expressions at the start time and end time by default (except where they are swapped chronologically as previously discussed.) ISY evaluates "if" statements (with or without time expressions) whenever triggered. Lots of ways to be triggered include external "run if", change in status of a listed device or variable, and other stuff. ISY evaluates time statements as per common English understanding of from/to. Like, "I work the third shift, from 10pm to 6am the next day." It is obvious to anyone reading that when this person will be at work.

Oops. Yes.

Neither did I. But good to know! Had to edit my post like 4 times as I tested and eventually narrowed it all down.

Here is the the final deal. 1) from "a time" is that time every day unless otherwise stated. Like a hotel says "check-in is 3pm", they don't qualify that with "everyday" or "today" unless it isn't the same everyday. 2) To (same day/next day) means a day as defined by the calendar (meaning 12pm start time). 3) That line of code is always true between those two times no matter when you check. 4) If "to" time is after "from" time, it is false, but is NOT a trigger at either time. All of those seem pretty self evident to me except the last one, which is just the convention ISY chose so you just have to know it and write programs accordingly.

I don't follow. It doesn't say "today". That would be confusing. You can choose between everyday or just days of the week when writing the program and then it displays it as follows. Which seems to follow common English understanding in my way of thinking. I suppose you could have it say "On Everyday" for the everyday one like it says for just specific days, but to me, just saying at 8pm in a schedule means every time it is 8pm.

You shouldn't really need to access polisy except for rare configuration changes. If this is the case, I would suggest using team viewer to take over your son's computer and then from there you can access all the stuff on his network. Team viewer is free if you only use it every once in a while. I use it to fix my dad's computer a couple times per year. Team viewer doesn't require opening any ports.

@Michel KohanimIt is my recollection that if you factory reset and restore a device, the previous backlight level is not restored. Perhaps the latest firmware has this fixed, but my last experience with restoring a switch with altered backlight maybe a year ago required my manually fixing the backlight.

@larryllix @Michel Kohanim I tend to agree with Larry that a link to a login page in an email being suspicious when the email wasn't specifically solicited. I also agree that an "account" tab or "billing" tab would be a good idea. The current location is not where I would expect to find billing information.

OK, that explains it. Yes, I deleted that program a long time ago. I had some "status" programs and when the status changed at 3am because of a missed com earlier in the day, stuff would happen at 3am. Most disconcerting was the occasional turning on of the whole house music system. The WAF on that was quite low. Also, I wasn't too fond of it either.

True, but that requires you put the logic to run the else inside the "if" of your program that isn't in a conditioned folder. So what is to stop you from putting that same logic in the "if" section of your program inside a conditioned folder? For the handful of programs (for most people) using waits/repeats a simple "if time is not x" where x slightly precedes the end time of the folder. Or, if you are in the minority and use a lot of waits/repeats, one program that does a "run else" and lists out all those programs that need to terminate. Lots of ways to handle it, and like I said, when you use waits/repeats, you are going to have to do something no matter what to ensure the proper outcome.

true or false is not an action. Enabled and Disabled is the action taken based on true or false. As I mentioned, only programs with repeats/waits would ever be "abruptly" terminated. Repeats and Waits are of course also abruptly terminated by their own "if" clauses. As is always the case, you need to be careful using those statements, folder conditions or not.

I was thinking the 3am query was something people did via a program, not ISY doing it on its own. I swear I used to have a program do that, but stopped because I would get programs running at 3am if the status of a device was corrected and that status was part of a program.

I use google voice as my phone carrier and this is what shows up as my text in the laundry example. This is a copy and paste from my google voice interface on my PC. The one on my phone is similar.

Folders do have both a "then" and "else" Then: programs are enabled Else: programs are disabled. I can't think of how a folder condition could ever have any other "then" or "else".

I only send short messages and the whole thing goes through. They have a link to the "whole email" in the text, so I suppose that means they cut you off at some point. My messages are things like "upstairs laundry done". If you are sending large messages, texting really isn't designed for that. Of course, you actually get the email, so really all the text needs to say is, "check your email". They send both the subject line and body of the email. I put the same info in both, so my SMS ends up being "upstairs laundry done" "upstairs laundry done".

Timed folder conditions and the fact that programs simply don't run at all outside of those times regardless of everything should be thought of as a useful feature. Outside of the folder conditions, programs within the folder effectively don't exist. This is of course not the case otherwise since aside from a conditioned folder, all programs can be forced to run despite its own "if" conditions not being met. When you truly only want a program to run during certain conditions, a folder is the only option. Typically speaking, night time lighting is ideally suited to conditioned folders. The only type of program that could fail to complete within a conditioned folder would be a program with a "wait" or "repeat". Using wait/repeat is tricky no matter where you use them by the very nature that they can be interrupted regardless of how/where you use them. Those programs always require thoroughly considered "if" conditions not only within the programs own "if" clause but any "if" condition outside of the program that reference it, including other programs, network resources, and folder conditions.

the need for next day/same day and the built-in ISY logic becomes quite evident in the following example. From 8am to sunrise. In the winter, sun rises maybe at 9am, light turn on at 8am and off at 9am. Sounds good. Now in the summer, the sunrise might be 7am. So, now the lights turn on at 8am and turn off the next day at 7am, only to turn back on an hour later. ISY logic fixes that. By using the "same day" in this example, the summer time lights never turn on. The statement triggers false at both times.

@gviliunas Have you considered putting your night light programs in a folder with condition from 8pm to 4am next day? Any program in the folder would become "available" to run from 8pm to 4am, but would not automatically trigger at those times. No variables needed. Any programs that you want to trigger at 8pm and 4am need to say from 8pm to 4am within the "if" clause. Again, no need for any variables. Or, have a nighttime program that is blank aside from "if time is from 8pm to 4am next day". Then any other program you want to trigger at those times states "if program nightime is true". A program referenced in an "if" clause will be a trigger when it changes state. Again, no variables needed. And it allows you to adjust your times on all programs by just changing one. Though, it is quite likely that anything you want to happen at 8pm (true) and 4am (false) can all be contained in the same single program with multiple items in the "then"/"else" clause. Or better yet, a single scene may encompass the whole lot so your "then"/"else" may each contain only a single line turning on/off that scene. Both of these schemes require the same or fewer programs you currently have and require no variables.

@MrBill Well you really tackled the question head-on. I just sorted my devices from the admin console by Insteon address which put all the Insteon nodes together, then I counted 40 lines fit on my screen and scrolled down to see that they filled 3 screens. I then subtracted for the 4kpl's to come up with roughly 100. The one thing that will slow you down a lot is if you have non-connected devices. It will dwell on those devices for a long time when they don't respond. So be sure to disable non-connected devices (ie Christmas lights)

@MrBill How many devices do you have? I think I have about maybe 100 or so Insteon devices and my startup query only takes a few minutes.

I set mine up like @MrBill and it works as he said. Another trick is to use gmail and install a plug in called cloud HQ SMS. You can set filters on it where any email sent to your gmail account that meets the filter criteria gets forwarded as a text. Those texts always arrive on my phone as having been sent by the same number. I started using the cloud HQ app maybe 2 years ago when IFTTT stopped supporting texts. So I have it send an email and Cloud HQ forwards that on as a text.

Querying a device once every 15 minutes should not put any sort of problematic load on your ISY com. I see no problem in the program posted by @MrBill above. @lhranch doesn't even seem to need that level of precision. So I suppose you could go with once every few hours if you want. But even once a minute should be fine. Many Insteon users have a house full of switches and motion sensors and stuff which altogether is going to have com running constantly. What is one more device query in that mix?

I am baffled by this thread. There is all kinds of arguing about a "problem" that does not exist. ISY logic handles the condition perfectly. If From [any time condition you like ie sunrise/sunset/specific time] to [any time condition you like] (next day) Then whatever Else whatever The above runs true any time the "if" clause executes between the two times. Period. It does not matter if it is before MN of day 0 or after MN next day. Just try it. change the parameters however you like and do a manual "run if". It will give the correct true/false EDIT: Here, I did it myself. The sun rose here at 6:20, or about 3 and a half hours ago. (currently 9:55am) Below runs false. New Program - [ID 017E][Parent 0093] If From 10:00:00PM To Sunrise + 3 hours (next day) Then - No Actions - (To add one, press 'Action') Else - No Actions - (To add one, press 'Action') Below runs true New Program - [ID 017E][Parent 0093] If From 10:00:00PM To Sunrise + 4 hours (next day) Then - No Actions - (To add one, press 'Action') Else - No Actions - (To add one, press 'Action')

The program will be true at all times between 10pm and sunrise. It doesn't matter when it is "invoked". So a second program that calls a "run if" on this program at, for example, 1am will still run "then". It doesn't matter that it is a different day. ISY logic doesn't reset at MN.

"is switched on" terminology (at least as it applies to kpl's) means one specific thing only . . . that someone physically pushed the kpl button. Upon power cycle, a KPL STATUS will return to its previous state, but that will submit a "status" message over the network, not a "control switched on/off" message. ISY at boot up may be set to "run at startup" for programs of your choice. If the program has a populated "if" clause, then ISY evaluates the contents and proceed to "then" or "else" as logic dictates. In the case that "if" clause is blank, it runs the "then" clause. If ISY is not set to run the program at startup, the program sits idle at boot. Your program has "if" populated, so "run at startup" whether checked or not really doesn't matter. It is going to be false and the "else" clause is blank, so the results are the same either way, nothing happens. So that isn't it. If you are 100% certain that no other program references this program with a "run then", then I have no idea what happened. The program should not have run. A KPL button should not have sent a "control switched on" message at power up. Even if it had, ISY (assuming it also rebooted on the power outage) would not have received the command since ISY takes far longer to boot up than the switch. I keep going back to there being some other program that executes this program's "then". If your ISY is on a UPS, then perhaps some errant message was sent and received by ISY. This would be an error on the part of the KPL. But I can't say I have ever heard of anyone having a switch send a "control switched on" message at boot. There is always the possibility that when your power returned, it was full of noise and somehow that messed with things, but again, ISY takes a little bit to boot up and I would have expected the power to have cleared by then.