Xathros

I think this line in the first program: And Control 'Kitchen Island Light' is not switched On needs to read: And Status Kitchen Island Light is Off For 2 reasons. 1) On at any brightness is NOT Off. 2) A control event only happens at the exact moment the paddle it operated on a device whereas Status is going to reflect the current status of a device whenever you check it. -Xathros

The reason for testing both is so that you can drive both the Then and Else sections following the if. If you test for Control is Switched On only, then the program is triggered only when the control is switched on, evaluated as true and the then runs. When the control is switched off, the program is NOT triggered because there is nothing looking for control Off in the if section. In short, the posted program has 2 triggers, Control On and Control Off. The evaluation of false for the control Off is handled by the NOT. When the Off control event is received, the program triggers and the Control is NOT switched Off evaluates to False since it WAS switched Off driving the Else section. Clear as mud ? -Xathros

Well that will always evaluate true. So the Icon will always be the same regardless of the door position. Here is my open/close program: .Dad-Open-Close If Then Set 'Garage / Garage Door IOLinks / GD- Dad Garage Door Relay' 100% Wait 10 seconds Set 'Garage / Garage Door IOLinks / GD- Dad Garage Door Relay' Off Wait 8 seconds Else - No Actions - (To add one, press 'Action') I "Run Then" from Mobilinc on the above program to Open/Close. True Status is "Open" False Status is "Closed" Running Then is "Door in motion..." The last wait is to allow time for the door to complete it's travel thus keeping the status of "Door In motion" for the duration of it's travel. And my status program: Dad Garage Door Status Lights If Status 'Garage / Garage Door IOLinks / GD- Dad Garage Door Sensor' is Off Then Set Scene 'Garage / Garage-Dad' Off $i.Dad_GD_Status = 0 $i.Dad_GD_Status Init To $i.Dad_GD_Status Run Program '.Dad-Open-Close' (Else Path) Else Set Scene 'Garage / Garage-Dad' 100% $i.Dad_GD_Status = 1 $i.Dad_GD_Status Init To $i.Dad_GD_Status Notice the Then section of the status program calls the Else of the Open/Close program when the door is closed. This is what fixes the door Icon on Mobilinc for the closed status. Hope this helps. -Xathros

Wow. All along I was thinking Insteon was much more secure than that. Still better than X10 I guess. At least with I2CS it would take a PLM address hack to gain control of another network. -Xathros

Assuming your neighbor was able to determine the address of your garage door IOLinc, your IOLinc would still not have a link to his/her PLM and should not respond to it. -Xathros

isyrocks- Sorry for the delay - was away on vacation. My door icon works as it should. What is in the If section of that program? -Xathros

The Smarthome "Insteon" camera is just a rebranded Foscam camera. If you have the UDI Network module installed in your ISY, you can create network resources to control the camera position, enable/disable record on motion and manage other aspects of the cams. -Xathros

You shouldn't care (or monitor) the relay status. It is meaningless. It is the Sensor status that defines the door condition. Try removing the scene with the relay and button. Now, create a program that says: If Control KPL button is switched On or Control KPL Button is switched Off Then Set IOLinc.Relay On wait 5 seconds Set IOLinc Relay Off You will want to set this as a Mobilinc Favorite (run then) along with the Sensor/KPL scene. The sensor scene is your door status, the program is the open/close button. -Xathros

In my setup, I only use scenes to control the KPL LED's. The Sensors and Relays are not in the scenes - everything is linked via programs. Keep in mind that the stratus of the relay is meaningless and only the sensor status should be looked at for door status. In your case, having the sensor be controller of a scene containing the KPL LED as responder should be fine and Mobilinc should correctly display the status. What mode is your KPL button in? Toggle, Non-Toggle On or Non-Toggle Off? -Xathros

NO! DO NOT DELETE THE PLM!!!! You will lose all of your links if you delete the PLM. Remove power from the ISY, unplug the old PLM, disconnect it from the ISY. Connect the New PLM to the ISY and plug the new PLM into power. Restore power to the ISY. Log into the ISY and issue a restore PLM. After the restore is complete, You will need to go around to each of your wireless devices, one at a time, place it in linking mode then write updates to the device from the console. That should do it. -Xathros

Correct. -Xathros

The fact that neither my programs or your previous ones work as they should leads me to think you are having either link record or comm problems between the IOLincs, KPL and PLM. With the KPL-Relay and Sensor-KPL scenes set up, run a cycle or two with the event log running at level 3 and post the result. -Xathros

I am doing exactly the same thing with my RL2. The trick is to not directly control the lights/scene(s) with the RL2 button but instead have a program react to the button presses. Here are some examples. The first two Toggles my ceiling light whenever I press the RL2-A button: If Control MBR_RL2-A is Switched On or Control MBR_RL2-A is Switched Off Then Run Program MBR_CeilingToggle (If Path) Else Program: MBR_CeilingToggle (Disabled) If Status MBR Ceiling Light is Off Then Set Scene MBR Ceiling Light On Else Set Scene MBR Ceiling Light Off This next one uses RL2-E to turn off all downstairs lighting: If Control MBR_RL2-E is Switched On or Control MBR_RL2-E is Switched Off Then Set Scene All_Downstairs Off Else -Xathros

Anytime the Test button in network resources is gray on mine it means that I have an unsaved resource. Hit the Save button and try again. -Xathros

Start reading here: http://forum.universal-devices.com/viewtopic.php?p=88540#p88540 It's not much more than you have already seen. io_guy has written code that allows the RPi to gather the sensor data and relay it to the ISY. I believe arw01 is working on an implementation of that now. I am watching their progress and may move my sensors off of my CAI Webcontrol and onto my RPi down the road. -Xathros

Run at startup is exactly that. Anything that it checked Run At Startup will trigger and evaluate when the ISY boots. The reason for this is so that the flag will get reset if the power fails and the sensor goes dry while the ISY is down. This is used in conjunction with your 2nd question. i.LeakNotifySent = 1 - This line sets the current value of the variable to 1 i.LeakNotifySent InitTo 1 - This one sets the Initial value of the variable to 1. I do this so that this logic can survive a power failure. When the ISY starts back up, the Init value is what the variable gets set to. By default this is 0 when you create a variable but you can set it to anything you like. In many of my programs I have similar lines: s.HomeAway = 1 s.HomeAway InitTo s.HomeAway That accomplishes the same as above but means I only need to edit one line if I need to change the value. When we get the variable enhancements that UDI is working on, this method will become much more common. -Xathros

Assuming the leak sensor is fluttering as LeeG suspects, you will need to use a variable and a delay to overcome the multiple notifications. 1. Define an integer variable: i.LeakNotifySent and set it's value to 0. 2. Build a program to monitor and notify: If Control LeakSensor.Wet is Switched On And i.LeakNotifySent = 0 Then Send Leak Notification i.LeakNotifySent = 1 i.LeakNotifySent InitTo 1 Else 3. Build a program to delay and reset the notify flag and set this one to run at startup. If Status LeakSensor.Dry is Switched On Then Wait 1 Hour (Adjust this based on your notification frequency requirements) i.LeakNotifySent = 0 i.LeakNotifySent InitTo 0 Else The above will limit the possible notifications to once an hour assuming the sensor continues to fluctuate between wet/dry. As for the ISY Log, you select Tools / ISY Log from the admin console menu. It will pop up and ask if you want to open the log in Excel. Choose yes if you have Excel or No if you don't. If you chose no, it will allow you to save the log as a text file wherever you point it to. Either way, one you have the log data visible, simply copy/paste the pertinent section into a post Hope this helps. -Xathros

Access points by nature are dualband - both old and new. I don't believe much has changed in them over the years as long as they are true access points and not the old Signalinc's with the black external antennas one the bottom. As for the PLM, if yours is working, no need to replace but since the PLM is the heart of your insteon system, it might be a good idea to have a spare on hand. If you poke around these forums much, you will see lots of occurrences of failed PLM's. I personally had to replace my PLM earlier this spring after maybe 4 years of use. -Xathros

It would be helpful if you could post the program that monitors the sensor and sends the notification as well as the section of the ISY Log showing the time frame when the sensor was wet. -Xathros

If Status is 100% or for dimmers: If Status is not Off -Xathros

That is by far the best description of how that works that I have seen so far. Nice job! -Xathros

That was actually mountainman3520 but I can post some examples as well if needed. Variables add a layer of complexity but add so much flexibility that it is well worth it. And as mountainman said above, The ISY makes it pretty easy to deal with. -Xathros

Maybe it is set with a REALLLLLLY long ramp rate? -Xathros

Hello mountainman3520- Many of us us the same approach as you have. It does make things more flexible. -Xathros

In the above program, the if contains " Status 'Main: Basement Control' is not Off". The first step in the Then says "Set Scene 'Scene: Basement 3Way' On" . Since this scene contains "Main: Basement Control" and that device now has a Status of On, the If is re-evaluated during the 2 second wait and the program runs false (Else). Nothing after the first On command is executed. Breaking it up as follows: Original Program If Status 'Main: Basement Control' is not Off And Control 'Main: Trigger Drive-Opened' is switched On Then Run Program BasementFlashLeaveOn Then Path Else - No Actions - (To add one, press 'Action') New Program: BasementFlashLeaveOn If Then Set Scene 'Scene: Basement 3Way' On Wait 2 seconds Set Scene 'Scene: Basement 3Way' Off Wait 2 seconds Set Scene 'Scene: Basement 3Way' On Wait 2 seconds Set Scene 'Scene: Basement 3Way' Off Wait 2 seconds Set Scene 'Scene: Basement 3Way' On Else - No Actions - (To add one, press 'Action') Now the first program triggers if the basement is on and someone trips the driveway sensor. It calls the second program that has nothing in the If section. The second program runs the flash and is is not interrupted by the if re-evaluating because it has no If section to re-evaluate and nothing to re-trigger it. Make sense? -Xathros