apostolakisl

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.

I can only ask if you have another program or something outside of ISY that sends a "run then" command to this program. The "if" clause here is only true at the instant when someone clicks the KPL button.

normally toggle. Meaning click changes the state from its current state (on or off) to the other state (off or on). Non-toggle means every click is an an on click, or, every click is an off click, depends on which you choose when setting it up.

sounds like a kpl problem, not a program problem. Do the other kpl buttons work? Have you tried a factory reset on the kpl and restore? I have an old kpl that does stuff like that sometimes. I should buy a new one, but I can always seem to get it to come back to life with a factory reset or two.

If it is a garage on the inside, I would definitely drill through. Even if your handwork isn't the prettiest, it won't much matter in a garage. Getting it out of the sun and rain has got to help. I assume your garage is not conditioned, but if it is attached to your house, it will likely have buffered heat swings.

He indicated it was mounted below the outdoor circuit box and mostly shaded. If it wee getting hit by rain, I'm sure it would have died very quickly. It shouldn't be so hard to block sun and rain on a wall that is allowed to be ugly (I've never seen a circuit breaker box mounted somewhere visible. . . but I suppose. But here is another option. What is on the other side of the wall it is mounted? Is it indoor conditioned space? Yes? Great. Drill a hole directly through the back wall of the outdoor j-box and all the way into the house. Splice 18 inches of wire onto the wires in the outdoor j-box and push it through to the inside where you install an "old-work" j-box. Now, your done. Switch is indoors.

Long story short, as long as the box/switch is not in direct sunlight or hit by precipitation, I don't think there should be an issue. Like I said, I have two switches in an outbuilding and I used to have a switch in my chicken coup. None exposed directly either to sun or precipitation, but all subject to 100 plus degrees quite often and none failed. All 2477D. Also, at the low end, they all experienced temps into the upper 20's and the full swings of outdoor humidity which will hit 90 percent on summer mornings. 85/85 temp/humidity is real common in August/September around sunrise. This particular switch that the OP had die may also have just been a switch that died. Those happen even in perfectly controlled environments.

As Larry said, metal feels hotter not because it is hotter but because it conducts better. I taught my kids with a little exercise. I asked them to tell me which objects in our kitchen counter were hotter and which were cooler. They said the towel was hotter, the granite the coldest, some papers a bit warmer. We then pointed the thermometer at them and of course they were all 73 degrees. The granite just is efficient at conducting. So, 2 points. 1) The switch heats up things 2) The sun heats up things The metal box will be better at conducting heat both into and out of the switch as compared to plastic. If you can keep the box in the shade, then it will not be conducting the heat of direct sunlight in, but rather conducting the heat of the switch out. This benefit is most pronounced at higher ambient temps. The higher the ambient temp, the better conductor you need to get the heat out of the switch. In summary, a well ventilated and shaded metal box with good thermal contact between it and the switch heat sink (the ears), the cooler the switch will be.

I feel bad for you metal guys, rf attentuation must be a bitch.