Hurting2Ride

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

Hi Steve, If you don't mind me asking, what weatherstation hardware and software are you using? And how do you like it? The closest WB weatherstation to me is far enough away that the readings are a couple of degrees off from my home. Since I just installed a couple of whole-house fans I want to automate them to turn on when there's enough temp difference between the inside of the house, the attic and the outside so I'm in the process of deciding weather (haha, get it...) to just buy some temp sensors or to go all the way and buy a weatherstation. Thanks!

I also have the new 7-day integrated thermostat w/ the humidity module. My thermostat is rev 2.2 build 1810. I checked and my humidity is being correctly reported regardless of Thermostat Mode. However, I am not receiving updates from the thermostat automatically and have to use a program to poll it every few minutes to catch changes. I am running 3.1.6.

I believe Trigger Reverse is specific to how the IOLinc reports on the connected sensor, i.e. my sensor to determine if my garage door is open uses this to turn ON a KPL6 key when the sensor circuit is OPEN rather than CLOSED and vice versa. I'm guessing this is what Oberkc was referring to as well.

Just be cautious in your use of it that way since it would be shared between any programs that happen to trigger during the same time. Such as the one that runs a sprinkler valve to top off your pool for 5 minutes and the one that closes your garage after an hour.