apostolakisl

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.

Are they mounted in a metal box? A metal box that is in the shade would be a better heat sink for the switch than a plastic one. Might even consider some heat transfer paste where the ears are screwed down. Might also drill some ventilation holes provided you can keep rain off the box.. You could also consider the high wattage Insteon switches which have better heat sinks even though you aren't dealing with high watts. In my case, I have 2 Insteon switches mounted side by side in a plastic gang box in an outbuiliding that is virtually never heated or cooled (it has hvac but I only turn it on when I'm working in there). Summers here have plenty of sunny 100-107 degree days. Not sure how hot the garage gets inside, probably not the full 100+ degrees since it does have thermal mass that buffers it a bit. These switches control outdoor lights that ISY turns on every night for a few hours. These are led lights, so not very many watts to heat things up. I am pretty sure these particular switches have been in place ever since I pulled all of my 2476D's and replaced them with 2477D's. The 76 ones never died out there and so for the 77 ones have not either. Between those two switches, there has been an Insteon switch there for 10 years. I want to say roughly 5 years each. In summary, Insteon switches are capable of being in a hot environment so your switch might just have been a weak one or maybe the particular run of whatever component in your switch wasn't as good, I don't know.

I'm sure the heat hasn't helped the switch. But I live in Texas and we have 2 plus months of 100 plus degree heat. I have several Insteon switches in an un-conditioned out-building which have survived many years now. I even had a small workbench fire that melted the paddle on one of them. Now having said this, I'm sure I'll have them die tomorrow. But my point is that the heat isn't necessarily a death sentence.

@madcodger Couple things. 1) You have two buildings hooked up with copper. This is asking for trouble. Unless they are pretty close together and share the same electric service, they are going to each have their own grounds and any lightening strikes nearby will cause electrons to flow through your data cabling as the ground difference equalizes. This will tend to let the magic smoke out. It is very tricky and expensive to have proper protection. I would suggest using fiber to connect the two buildings for data and put that worry to rest. Or, as I have just been researching, using a couple of Ubiquiti LiteBeam 5ac Gen2 devices. If you are only a few hundred feet apart you should get 450mbs. 2) As far as the alarm panel. I use DSC at my office and use IOGuy's node server (slightly different than the polyglot node but fundamentally is the same). I have multiple partitions on that panel and it all works well as if it were multiple independent alarms. The DSC is like an order of magnitude cheaper than Elk which is what I have at home. DSC is a lot more of headache to program as you pretty much have to program it through the keypad with all sorts of cryptic code and limited feedback. Also, DSC logic isn't as flexible as Elk. I have a water valve that shuts off at the office when both partitions are armed after a 45 minute delay as well as when any of the water sensors are tripped. It took me some creative thinking along with a relay to get this to work letting ISY doing the logic. Anyway, all the zones show up on ISY and I can control each partition from ISY. If you wanted two DSC panels it is not a problem to have two separate DSC nodes on ISY, or like I did, one DSC node with two partitions.

"triac" spell check I'm sure. Of course that doesn't explain it not responding to Insteon commands.