Hurting2Ride

From a technical standpoint, yes it will work. However, because of the state nature of the ISY and some limitations currently in how variables can be used you will run in to a couple of ease-of-use issues. 1) if you have more than a few devices that you want to include you will end up with either quite a number of individual programs, 1 per device or an extremely complicated and hard to read set of IF/THEN clauses. 2) you will have quite a number of additional state variables, again 1 per device 3) If you have to account for devices that are not simply on/off, your set of IF/THEN statements has to account for every possible status. An AC or other temperature control would be a royal pain. 4) You cannot easily see what state the devices are all supposed to be in. Think of looking at a single scene vs having to look in each individual program. 5) Any time you decide you want to include a new device you have to set up a new variable and a new program. If you use a scene, you simply add the device to the scene and you're done. Hope that helps.

You can also do this by sorta combing all 3 ideas with an iMeter Solo. Poll it every so often and watch for it stop responding, which you can tell mainly by getting the exact same reading for an extended period of time whereas most things have at least a very slight variation in their power draw over time. That tells you the power is out and at which point you can send a notification (assuming your router and such are also on UPS) and then begin to watch for the power to come back on for your cleanup process. There's another idea to help with dealing with return to state after a power outage that requires no polling or additional devices nor the ISY on UPS. If you have "mission critical" items that need to be on/off, add them to a scene (lets called it MS). When you turn the critical devices on/off, also set their status in MS. Have your ISY run a program that turns on the "MS" scene about 20-30 seconds after the ISY powers up (that should give any other programs that run at boot enough time to get out of the way) and now you're not returning to a hot house or a flooded basement.

Updated from 3.1.6. No issues in the update process. Have reviewed my devices, programs and variables and do not see any issues as of yet. I think I might actually sleep easier tonight knowing that I have a working backup again...

Jumping in here and hopefully not adding to the confusion but I have a Silly Question. From what I see it looks like the motion sensor is added in to a scene but it does not look like it is actually linked to the light itself. Is that the case?

Hard to say w/o knowing more about your alarm system but the option you mentioned is possible, probably the least difficult, least expensive and most basic. Others include: - A standalone device that can bridge Zwave and Insteon, such as Vera 2. Could be overkill. http://www.micasaverde.com/vera.php - Software that can bridge Zwave and Insteon, such as Homeseer, Linux MCE, etc. Again, possibly overkill and requires a PC or equivalent device. - If your alarm system can set generic relays (as most can), you could relay power to the input of an IOLinc Your decision probably has a lot to do with just how much information you want to pass back and forth. Simply armed/disarmed? Then the Synchrolinc or relays are pretty simple and inexpensive. If you want to pass more information w/o going as far as bridging software or hardware, you could use something like a iMeter instead of the Synchrolinc. Then assuming you can set a dim level of the Zwave device, you could use the wattage reading of the iMeter to pass a bit more info but still keep the integration itself pretty lightweight. Hope that helps.

Here's a way that I know works within certain limits. Using an iMeter Solo, plug it in to an outlet that is not on UPS and not Insteon controlled. Plug in a device that does NOT remain at a constant power draw and remains "on" at all times, i.e. typically some kind of electronic device. Computers work well; I have a laptop plugged in to mine. Even a low power device will work fine so long as it does not remain at a constant level as measured by the iMeter. That includes not remaining at a level of "0", too. Use the following program. Make sure it is enabled and ALSO enable it to run at startup. Program: Query iMeter for Power Outage If Status '.Unassigned Devices / Spare iMeter Solo 1' > -1 Watts Then Repeat 30 times Wait 15 seconds Set '.Unassigned Devices / Spare iMeter Solo 1' Query Repeat 1 times Send Notification to 'System Admins' content 'Possible Power Outage' Run Program 'Query iMeter for Power Outage' (If) Else - No Actions - (To add one, press 'Action') The program constantly queries the iMeter. In my case it I have it loop 30 times with a 15 second delay between each time. This means that in the case of a power outage I will be notified after the power has remained off for 30 x 15 seconds = 450 seconds = 7.5 minutes. If you need to be notified faster, reduce the number of times the program loops. You can also reduce the wait time but keep in mind that increases the amount of traffic as well as amount of time the ISY is spending trying to get the iMeter to respond. Based on the IF clause what happens is that as long as the amount of power that is being pulled through the iMeter changes during that 7.5 minutes the program restarts itself. That effectively makes a never-ending loop UNLESS the power fails, at which point 7.5 minutes later it will send me an e-mail that the power has failed. I also have the program restart itself after sending the e-mail to make sure it continues to attempt polling when the power returns or in case of a false positive. Depending on how frequently the device that you have plugged in changes the amount of power that it draws, the smaller a number you can make the number of loops. Just keep in mind that amount of power must change some time during the loop x wait time-period or you will receive false positive notifications. Hope that helps.

If you're rebuilding from the ground up you most likely will not need to reset your individual devices manually unless you run in to a problem. When you re-add the devices to the ISY, select the option that removes existing links. Chances are unless you were doing something really out of the ordinary before, this will be all you need as far as individual devices go. Of course, be sure to check the ramp rates, on levels, etc when you re-add the devices to make sure they match how you now intend for them to behave.

That is why I have been trying to use "Wait" or to launch program B only after program A completes (a pain in the butt but doable) if B relies on A. Reading the OP I was thinking something had changed in how programs were handled. It would be nice if we had access to "Last Finish Time" and "Next Scheduled Run" in the conditions, and "Next Scheduled Run" in the actions. Would simplify things of this nature.

I have been wanting to confirm that same thing but have much too lazy to actually test it. Thanks!

Thanks for the detailed post! And congratulations on becoming my go-to guy when I start messing with this thing next week...

After looking over various options to get temp readings around the house as well as having sensors that can grab the pool temp, level, etc. I actually decided on the CAI board. It's sitting here in front of me and my sensors should be showing up in a day or two. I'm hoping this works well - seems a number of people on various forums have used it, mostly with success, so I'm looking forward to getting it in place. However, the reason I bring up z-wave is because of the pre-built components & applications. For example, see this pool pump: http://www.smarthome.com/25109/Intermatic-PE653RC-MultiWave-Z-wave-Pool-Spa-Home-Control/p.aspx It [*:2zhcsxy6]1) controls the pump, including variable speed [*:2zhcsxy6]2) controls the heater [*:2zhcsxy6]3) has a separate control for the cleaner or another component which would be really handy if you have a solar diverter [*:2zhcsxy6]4) controls the pool light [*:2zhcsxy6]5) reports the water temp [*:2zhcsxy6]6) has a freeze sensor for those that live in cold climates [*:2zhcsxy6]7) has a remote. Can you do all of that with Insteon and various add-on components(i.e. WebControl)? Sure. But it will require about 5 different Insteon devices, will cost you about the same and require a whole lot more tinkering. IMO Z-wave is something to consider when discussing possible new, supported integrations.

A lot of the integrations I see requested could be solved by adding Z-wave since a lot of these products already exist in Z-wave flavors. Any thought to that happening?

Did you add them via linking or enter them manually? If manual, did you use Auto Discover or select the device type?

Not sure how many how many groups you have but I have the same scenario for my living room lights and the program is extremely simple. I used the status of the KPL keys themselves rather than the devices but you could do it either way, whichever is more important for you. Program: LR Lights Master On-Off If Status 'Controllers and Remotes / Living Room Lights.A' is On And Status 'Controllers and Remotes / Living Room Lights.B' is On And Status 'Controllers and Remotes / Living Room Lights.C' is On And Status 'Controllers and Remotes / Living Room Lights.D' is On Then Set 'Controllers and Remotes / Living Room Lights.1' On Else Set 'Controllers and Remotes / Living Room Lights.1' Off regards.

This is the same issue I identified the other day. Restores done from a 3.1.6. backup are corrupting the data as shown in his screenshot. If you have a backup that was done prior to 3.1.6 that should work (note: you can stay on 3.1.6 but the backup had to be from 3.1.5). This is exactly what happened to me. When I did a restore from a backup taken prior to my 3.1.6 upgrade, it restored fine. Hope that helps.

Aye. On the other hand his code is ignoring events for the 15 seconds the door is in motion so should he run in to this situation, he's got bigger problems

Do you get the lag back if you plug in the iolinc in a different location, circuit and/or phase?

IMO, if you have and plan to retain any significant amount of X10 units you should purchase the A10/X10 module. When I first purchased the ISY I went through a similar process to what it sounds like you are going through. I would read the manual and the wikis and the forums and then look at my ISY screen and go "huh?" because the simplicity of use I saw in all those manuals was not what I was seeing on my screen. As soon as I added the X10 module so that the X10 units are handled the same way as the Insteon units, everything clicked in to place for me.

Sounds to me like you're headed in to additional automation needs which probably boil down to: 1) Custom status codes and/or custom screen builds 2) Audio announcements and/or voice control 3) Easy-to-use, idiot-proof (no offense to yer family!) All 3 can be accomplished in 1 of 3 ways 1) Integrate with a security system. Security systems already have the kind of logic rules in them that you are looking for. They have more experience with things like keypads, doorlocks and touch-screens, all of which could serve your purposes (i.e. when your wife puts in the security code to leave, it passes the info along to the ISY and automatically locks the front and back doors, turns on some random lights every 20 minutes, and turns on a stereo to generate sound in the house but turns OFF the $5000 HDTV that is currently getting its screen burned in by the kids' game box) 2) Integrate with a highly customizable HA package like Homeseer. This can give you all the HA you're willing to pay for. Very flexible, very extensible (but you pay for the addons) and integration with anything HA related is already there. The downside? Can get expensive fairly quickly and 90% of the business rules that ARE there in a security system are not there in Homeseer. 3) Do a whole bunch of custom integrations to the ISY. While doable, this is going to be the most complex because of how the ISY currently addresses things like variables (don't get me wrong, what UDI is doing is great, they're just a ways behind something like Homeseer when it comes to that level of integration). Luckily UDI is finishing up with their ELK M1 integration, which is a fairly inexpensive security system that would do the things you're looking for. If I were in your shoes (and I sorta am, which is why I had this already thought through... ) I would see if that option could give you what you need. If you search on the forums you'll find all kinds of Q&A about it even through its not quite released yet. Regards,

Actually the Wiki recommended process has you placing the key in "toggle on" only mode so that's not an issue, either. With the wiki process the button light is still linked to and controlled by the sensor. In one sense the Wiki process has less chance at comm failures since it has "less moving parts". My $.02 - The only real reasons I can see for not using the recommended approach are if [*:2s8ht0wr]1) you want to to prevent a single touch of the key from activating the door, i.e. require a double-push to prevent open/close actions done by accident [*:2s8ht0wr]2) you want to disallow the ability to interrupt the open/close process (again, usually preventing this happening accidentally) [*:2s8ht0wr]3) you want to use a different key to open/close than the one you use to indicate status. However, in those cases I would take the wiki method and simply change the control of the garage scene to be set by your program. Leaves you with few programs and very little programming to still accomplish a whole lot.

Jay5, Did you get this set up how you want?

Since I live in a mosquito-free (and almost rain-free) area, perhaps this is a silly question but do you really want them to remain on all through the night?

What were you fixing by going to the 3.1.6 beta?

I wrote a similar set of programs. I managed to squeeze it down to 4; one master program to increment the day variables and 3 subs to check the validity of the information (i.e. change of month, wrap from sat to sun, etc). Rather than have the master program trigger directly based on time, I have a program called "Midnight" that I use to control some lights. I have my master date program trigger off a "true" condition for the Midnight program. The same points you made about the "catch up" process hold true for these as well. (If someone can figure out a way to determine if a given program has already run that day, I'd love to know it! I've twisted my mind in to a pretzel trying to figure out how to do it with the current state and variable limitations.) Like you, I created this to have both Integer and State variables although I have yet to use the states to trigger anything. I expect I might as the holiday season comes up. If anyone wants these I can post the export files. Meanwhile here's the info and code. date.Changed - Master program. Calls the subs below. date.Check.Day.Of.Week date.Check.Month date.Check.Year Variable naming convention: $di. = integer variable. $ds. = state variable. I added the "d" to my normal convention so that I could sort by name and have them appear together in the variable lists. [*:gje3p121].Day.of.Month (1 or 2 digit) [*:gje3p121].Day.of.Week (1 digit. Sun=1) [*:gje3p121].Month (1 or 2 digit) [*:gje3p121].Year (4 digit) [*:gje3p121].Leap.Year (0 = leap year) [*:gje3p121].Day.of.Year (1-3 digit) [*:gje3p121].Day.of.Year.Odd (1=Odd 0=Even) Note that this variable is calculated from the day of the year which means that in a normal year the variable will be "1" for both Dec 31 (day 365) and the following day Jan 1 (day 1). You'll need to populate the state variables with day, month, year,day of week and day of year info prior to running the programs. Aug 20 is day number 232. Program: date.Changed If Program 'Midnight' is True Then $di.Day.of.Month = $ds.Day.Of.Month $di.Day.of.Week = $ds.Day.Of.Week $di.year = $ds.Year $di.Month = $ds.Month $di.Day.of.Year = $ds.Day.Of.Year $di.Day.of.Week += 1 $di.Day.of.Month += 1 $di.Day.of.Year += 1 $di.Leap.Year = $ds.Year $di.Leap.Year %= 4 $ds.Leap.Year = $di.Leap.Year $ds.Leap.Year Init To $di.Leap.Year $ds.Day.Of.Year = $di.Day.of.Year $ds.Day.Of.Year Init To $ds.Day.Of.Year $di.Day.of.Year.Odd = $di.Day.of.Year $di.Day.of.Year.Odd %= 2 $ds.Day.Of.Year.Odd = $di.Day.of.Year.Odd $ds.Day.Of.Year.Odd Init To $ds.Day.Of.Year.Odd Run Program 'date.Check.Month' (If) Run Program 'date.Check.Year' (If) Run Program 'date.Check.Day.Of.Week' (If) $ds.Day.Of.Week = $di.Day.of.Week $ds.Day.Of.Week Init To $ds.Day.Of.Week Else - No Actions - (To add one, press 'Action') Program: date.Check.Day.Of.Week If $di.Day.of.Week > 7 Then $di.Day.of.Week = 1 $ds.Day.Of.Week = $di.Day.of.Week $ds.Day.Of.Week Init To $ds.Day.Of.Week Else - No Actions - (To add one, press 'Action') Program: date.Check.Month If ( $di.Day.of.Month > 31 And ( $di.Month is 1 Or $di.Month is 3 Or $di.Month is 5 Or $di.Month is 7 Or $di.Month is 8 Or $di.Month is 10 Or $di.Month is 12 ) ) Or ( $di.Day.of.Month > 30 And ( $di.Month is 4 Or $di.Month is 6 Or $di.Month is 9 Or $di.Month is 11 ) ) Or ( $di.Day.of.Month > 29 And $di.Month is 2 And $di.Leap.Year is 0 ) Or ( $di.Day.of.Month > 28 And $di.Month is 2 And $di.Leap.Year is not 0 ) Then $di.Month += 1 $di.Day.of.Month = 1 $ds.Day.Of.Month = $di.Day.of.Month $ds.Day.Of.Month Init To $ds.Day.Of.Month $ds.Month = $di.Month $ds.Month Init To $ds.Month Run Program 'date.Check.Year' (If) Else $ds.Day.Of.Month = $di.Day.of.Month $ds.Day.Of.Month Init To $ds.Day.Of.Month Program: date.Check.Year If $di.Month > 12 Then $di.Month = 1 $ds.Month = $di.Month $ds.Month Init To $ds.Month $di.year += 1 $ds.Year = $di.year $ds.Year Init To $ds.Year $di.Day.of.Year = 1 $ds.Day.Of.Year = $di.Day.of.Year $ds.Day.Of.Year Init To $ds.Day.Of.Year $di.Day.of.Year.Odd = 1 $ds.Day.Of.Year.Odd = $di.Day.of.Year.Odd $ds.Day.Of.Year.Odd Init To $ds.Day.Of.Year.Odd Else - No Actions - (To add one, press 'Action')