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

Some additional thoughts on Status Vs Control: Battery powered Controller Only Devices (TriggerLinc, MotionSensor, RemoteLinc etc) don't really have statuses as they are not queryable. Their status is assumed by the ISY based on the last Control event received from them. As a result, the ISY will show the status of these as blank until a control event is received from them. Responder only devices (IOLinc Relay Node, Appliancelinc, possibly the Outletlinc) CANNOT generate Control events as they are not controllers. -Xathros

The difference between Control and Status is that Status will trigger anytime the Status of a device changes (On, Off, Brighten, Dim, Main Mode Heat, Cool etc) by either changing it at the device or via scene or program or linked device. Control on the other hand will only trigger when the device itself is manually controlled (KPL Button presses, Switchlink Paddle presses, Trigerlinc triggered by door opening). If you turn o a device with a scene or linked device, the target device does NOT generate a control message. Status=100% is the same as Status=On. This was changed not too long ago to avoid confusion with dimmer type devices. Before a dimmer at 50% would not be "On" in a status test. Only 100% would = Status On. Removing the On from the status test forces us to specify the onlevel and avoids that confusion. -Xathros

Actually, I think only "Main: Basement Control" would be an issue there as the driveway trigger is watching for Control rather than Status and turning on/off a Scene does not generate a control event. Solution: break the program into 2 programs. Move the then section of the above program to a second program and call it from the then of the first. This way when the If in the first program reevaluates, the second program is unaffected. -Xathros

I think you still need the "FKPL B is Off" in the programs too. Having it in the folder only will enable the programs when the Buttons turns off but won't trigger them. What this means is the Setpoint wont change when you turn the button off until the next timeframe trigger. Including the KPL test i the programs will Enable the folder and trigger the programs when the button is turned off. In this case, it probably makes more sense to remove the folder condition unless you plan to have other Home only programs in there. -Xathros

Clarance- The integer (or State) variables do not maintain their values through a restart or power loss. You can fix this however by updating the Init value anytime you changes a variable's value. $i.myinegerMvar =+1 $i.myintegerMvar Init to $i.myintegerMvar The "Init To" sets the "Initial value" that the mvar will have on startup. Otherwise the mvar will be initialized to whatever you devined when you created the mvar (0 is the default). -Xathros