Xathros

As seen above, Quote seems to work. At least on my Mac using Firefox. @oberkc, don't worry about second guessing me. I often miss things and you have offed much good advice here as well. As I stated in my first reply, either status or control SHOULD work in this scenario assuming the perfect operation of the door sensor. The only reason I suggested using status over control was due to the possibility of a sensor bounce occurring during the opening of the door causing a false close control message and starting the countdown while the door is open. Since only Control Off would trigger the program, the sensor stabilizing in the On position would not abort the countdown and the light would be turned off while the door is open. Status in this case would correctly abort the run when the sensor finally stayed on the open position. I have had to deal with sensor bounce on one of my garage doors and have helped a few others here with similar issues so it is a known possibility. In this particular case, I don't see an issue with status failing to accomplish the stated goal as any sensor bounce would only be a very momentary issue filtered by the waits and in the end the status will be correct for open or closed door positions. -Xathros

To add to what LeeG said, in the event this does happen again, you can log into the Admin console and reboot the ISY. This should correct the situation assuming the PLM is still functional. -Xathros

Hi Teken- In this instance, I don't believe it matters. Either control or status will achieve the same result. Only difference is that when using Status, the program will trigger on both door open and close. On open, it will run the empty Else clause and have no effect. On close it will run Then and do what you want. With Control, it should only trigger on the door closing. If you get some sensor bounce when the door is moving near the sensor, control might cause a false "Closed" trigger when opening the door while status would correct itself once the door moves away from the sensor. I would stick with Status in this case. Hope this helps. -Xathros

Right click the program name in the lefthand pane and select "Copy to Clipboard" from the bottom of the popup menu. My programs are also recognizing user codes correctly and executing appropriately. -Xathros

8 months is within warranty. Pick up a spare and have Smarthome replace the failing one for a future spare. -Xathros

If the switch is a dimmer, you could use adjust scene to set the local on level to 0 and set a long ramp rate when the alarm is active. As long as the thief is not insteon aware and doesn't do a FastOn or a fade up that should work. -Xathros

David- How old is your PLM? Do you have a spare on hand? If not, you might consider ordering one before this PLM quits. -Xathros

Anytime. Happy to help. -Xathros

I suspect we are talking about "Remove from folder" which would precede a delete if the device was in a folder. -Xathros

piconut- The way mine work is that right before midnight, I have a program that runs and enables all of my motion programs. This way if any were left disabled, they are reset each night. I have worked up a solution that should meet you specs and it looks something like this: Program: LivingRoomMotionLightsDisable If ( Control 'LivingRoomLight' is Switched On Or Control 'LivingRoomLight' is Switched Fade Up or Control 'LivingRoomLight' is Switched Fast On ) And Status 'LivingRoomLight' is not Off Then Disable Program 'LivingRoomMotionLights' Stop Program 'LivingRoomMotionLights' Wait 2 Hours Set 'LivingRoomLight' Off Else Enable Program 'LivingRoomMotionLights' This will disable the motion program when the switch is turned on manually and re enable the program when the light is turned off regardless of how it is turned off. Modify to fit your device and program names. Hope this helps. -Xathros

This is what I assumed when I read your initial post. On the surface this seems like a good idea but in practice, not so much. Here is why: Lets assume that for each count of the integer variable, you want to keep the light on for an additional 30 seconds. Your sensor is in "Sensing" mode with no timeout. This means the the sensor will continue to send "On" messages as motion is "Sensed". This can be numerous "On" events in a fairly short period of time (20 to 30 per minute depending on the activity in front of the sensor). Lets say a few people walk into the room and stay for a minute then leave, you could easily end up with a count of 30+ resulting in a delay of 15+ minutes. In my opinion, the better approach is to pick a reasonable fixed delay from last sensed motion like say 2 minutes. Every time the sensor sends an "on" event, you restart the 2 minute countdown. If you are concerned about the lights turning off while the room is still occupied, there are some suggestions to aid with that. Use a Dimmer for the lights. When turning off at the timeout, use a scene with a medium ramp rate so the lights slowly fade rather than just turn off. This will give the opportunity for the occupants to move and trigger the sensor without being left in the dark. Others will send "Beep" commands to devices in the affected area before the timeout to warn of the upcoming "Off" event again giving occupants the opportunity to avoid being left in the dark. Other things to consider are possibly disabling the motion programs when the light is operated manually at the switch, and re-enable the programs when the light is turned off at the local control. This way, the lights are on auto unless operated manually. This is how all of my motion controlled indoor lights are configured and my front porch and back deck as well. Easy to operate. The wife and kids don't need to think about how it works because it just does. Hope this helps. -Xathros

ejh3- I don't have an Elk yet either but I do believe that the transition between Armed Stay, Armed Away and Disarmed states should only trigger a program once at the change of state. Post the actual program that is sending the email. There must be additional triggers or a loop somewhere. -Xathros

ejh3- When setting a static address, make sure the address that you choose is outside of the router's DHCP pool. Many routers use 192.168.1.1 - 254 and have from 192.168.1.100-150 as the DHCP pool. Use an address like 192.168.1.10 for the ISY as long as that is not already assigned elsewhere. Also, you might consider setting your DNS in the ISY to 8.8.8.8 (Google's public DNS). This has proven quite reliable for me on my ISY. -Xathros

Even if UDI would allow the system information they current support in notifications to be written to variables, or just generally used in programs in place of direct values, it would resolve lots of these painful workarounds. I believe this is coming in 5.X -Xathros

I bought my CT-800's from ebay but I had found a manufacturer's source as well. I'll see if I can dig that up for you tomorrow. I love the way these things work. Paired with a CAI board or Raspberry Pi they make awesome little sensors for all sorts of things. I have one on my oil burners's induction motor, washer, dryer, water pump and i'm considering taping the runs to 2 electric stoves. -Xathros Sent from my iPhone using Tapatalk

Here is a long interesting thread on Laundry monitoring with a number of options discussed along the way. http://forum.universal-devices.com/viewtopic.php?f=48&t=10104&hilit=laundry+monitoring -Xathros

JeffWLeach- The new weather module does not work with Zipcodes. Enter your City/Town name then hit find and select the station that best suits your needs. -Xathros

Anytime. Happy to help. -Xathros

Same as pervious versions. System Preferences, Java pref pane, settings button, delete files, check all 3 boxes, Ok. -Xathros Sent from my iPhone using Tapatalk

I don't believe there is a way to change the sensor status after the query other than by cycling the door. The switch swap is the best solution and as above, can go at the top of the door. Thats where mine is too. Almost identical to EricK. -Xathros Sent from my iPhone using Tapatalk

Smarthome's decision to go with that switch left many of us scratching our heads. I don't believe that they expect you to leave your garage open . They just decided that closed should be represented by the sensor being on rather than door open being on. Most, from my experience, seem to disagree. -Xathros

You must have a newer Garage door kit from smarthome. The newer kits ship with a normally open reed switch whereas the older kits shipped with a dual contact switch (NO/NC) and we had our choice with On when Open or On when Closed depending on how we wired the switch. Most of us seem to prefer On = Open. The best thing to do here is replace the reed switch with:http://www.smarthome.com/7455B/SECO-LARM-Enforcer-SM-226L-3-Magnetic-Garage-Door-Contact-Switch/p.aspx and wire the black/red in place of your current switch. Trigger reverse will appear to do what you want until you query the IOLinc or the 3AM query runs. When queried the IOLinc returns the ACTUAL sensor status rather than the Trigger Reversed status. This will throw off your status in ML and any scenes/programs driven by the IOLinc sensor. Hope this helps. -Xathros

The $1 module is the firmware component required to use the $99 ISY ZWave radio hardware. Without the radio, the ISY does not do ZWave with or without the $1 module. So, short answer is: No, you cannot. If you do have the ZWave radio and firmware module, you still will not be able to do what you want (yet) since the ISY does not yet support multi-channel ZWave devices like remotes. I believe support for this is coming in the 5.X firmware series. -Xathros

Larry- Are you sure the triggers are being missed? Check the last run time of suspect programs to be sure. I feel it is more likely that the resulting activity from the triggered programs may be preventing or delaying the result of some of the triggers rather than the triggers being missed. Insteon activity will queue up and take priority over a number of other things. This may result in the appearance of some programs not being triggered. -Xathros

Excellent! Happy ZWaving... -Xathros