apostolakisl

If you run conduit all over the place you won't ever have to worry about what wire will be needed down the road. Conduit is as cheap or cheaper than a lot of wire types and allows you to future proof things like crazy. Conduit runs all over the place!! Most of them will be empty at first, maybe forever. But it is worth it. You can dead-end conduit into various wall spaces so that later on you can just pop a little hole into the sheetrock if you want to add something weird in an area. Also, I highly recommend not going with a textured wall. They charge more for the "slick" finish but it just looks so much better and if you ever patch it, you can make it perfect. Matching texture is just never quite right. Put boxes in the wall in all of your closets that you run the conduits to and use larger conduit to connect the boxes to each other. A hub and spoke arrangement. Take tons and tons and tons of pictures, and video before the sheetrock goes up so you know where everything is. 1/2 inch pvc conduit is very cheap and easy to install. A propane torch and a nice smooth fanning technique turns it into flex conduit as well. Or you can run smurf tube, but the corrugation makes it harder to pull wires down the road. Personally, I would stick with Insteon for your switches. The switches they have been making in the last couple years are very good in my opinion. They look good, feel good, sound good, and work great. Plus you can pick them up at Christmas time for half price. Security in a 2 bedroom condo probably doesn't really need an Elk. I would just go with a DSC system and use the ISY node server for it. It is way cheaper and once integrated with ISY will have most of the features an Elk would offer.

ISY is definitely different than how most other languages structure things. Someday AI will be so intuitive that we'll just be able to tell it what we want to happen and it will ask us a bunch of questions to make sure it gets it right and then it will just happen. When that day comes, we will all become very stupid, but our HA will work.

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')