IndyMike

johne, As Brian indicated, I believe your transceivers are both manufactured by X10. That being the case, my theory of the "3 cycle gap" protocol doesn't hold water. It is possible that your "old" RR501 is in fact dying, as Brian has suggested. You mentioned that you had "both devices" installed and that things were functioning. Could you possibly plug your "old" unit into the "new" unit location? If your system works with this configuration, I'd suggest that you have a new signal absorber in your home. In my experience, the PLM does a pretty good job receiving X10 signals (sensitivity). The CM11a may, however, have better X10 sensitivity (or AGC) that allows it to receive when the PLM cannot. IM

Johne, I'm curious what model transceiver you replaced (TM751?) and what you replaced it with. It's possible that your "old" device was not allowing a 3-cycle gap between X10 transmissions. My Smarthome "Testerlinc" regularly flags X10 brand devices for not providing the correct gap between successive X10 commands while my Switchlinc devices (X10 mode) do not generate this error. I have read that certain Elk devices will completely ignore "X10 brand" communications for the same reason. IM

Joe, Welcome to the forum. You are correct that the ISY User Guide is a bit out of date. The fault lies with "WE" the forum members and Users of the system. We've kept the ISY people busy with our constant requests for additions. To our amazement, the ISY team has been fielding these requests and implementing them. Unfortunately, this has come at the cost of documentation updates. Fortunately, you've come to the correct place for answers. I, and many other forum members, share your X10 background. The ISY support for X10 has improved significantly since the release of the Users Guide. Have a look at the following categories: X10 : http://www.forum.universal-devices.com/viewforum.php?f=29 Beta Enhancements: http://forum.universal-devices.com/viewtopic.php?t=930. UD Wiki: http://www.universal-devices.com/mwiki/index.php?title=ISY-99i/ISY-26_INSTEON:Using_X-10_Motion_Sensors For specific questions, please let us know what current components you have in your system (modules, controllers, couplers, etc). If a forum member can't help, one of the ISY team probably can (they spend many hours on this forum). IndyMike

Chris, Thank you as well. I've been on the road a lot lately and missed the 2.6.6 folder condition update. Very nice! Can't wait to get home and give it a try.

aLf, Your posted code will enable the folder but your program lacks a trigger to start it (unless you are calling the program from another program). Each program requires an "Event" or a specific call from another program to start. The following will trigger if any of the "somethings" change state to ">0". You do not need the repeat loop here since the program will trigger if any of the monitored devices transitions from the off state. If status "something1" is > 0 or status "something2" is > 0 o o o or status "somethingx" is >0 Then Wait 15 minutes Set Scene 'All OFF' Off Else - No Actions - (To add one, press 'Action') Regarding your question about your "old" version - Yes this can make a difference. Firmware Version 2.6.4 corrected a problem related to status updates for disabled folders. Here's a thread on the subject - http://www.forum.universal-devices.com/viewtopic.php?p=8687#8687 Bottom line is, if you are running firmware older than 2.6.4, you may want to update. IM

Brad, Welcome to the forum. As of firmware version V2.6.5, there is a much easier way to monitor X10/Insteon communication (doesn't require telnet). Try opening the "Event Viewer". You can find this under the "Tools/Diagnostics" menu. The default level (0) will provide X10 communication monitoring. Increasing levels will provide increasing Insteon communication detail. I'm providing the above as an easier method for monitoring X10. Using this will not "fix" anything. If you did not see X10 indications in your logs there is a communication problem somewhere. Try your experiment again with the X10 device plugged into the PLM. Watch the PLM LED while sending commands with your controller. The LED should flash as it recognizes the X10 traffic. If the PLM LED does not flash in response to X10 traffic (I'm assuming it does for Insteon) you may want to check your X10 controller. If the PLM LED does flash, but you do not see traffic in the ISY event viewer, try cycling power to the PLM (10 seconds off). I've had instances where the PLM will become "deaf" after a power spike (storms/lightning). The device will send commands but not receive. IM

Dave, I'm assuming that the thread you are referring to was the one posted by Tracy. http://www.forum.universal-devices.com/viewtopic.php?t=1359&highlight=drapes From what I understand, the difference in your setups is that Tracy was using KPL's to manually activate his drapes, whereas you are using a Controlinc. Controlincs are, from my understanding, send only devices. They really can't be queried and should be used as "control" devices in your programs. I'm not quite sure how you are using your controlinc to activate your drapes (non-toggle= on/on or toggle on/off). It would really help if you could post your code. It sound as if you need a "status Program" to indicate whether your controlinc has opened/closed the drapes unbenownst to your timer program. Stealing from Tracy's post (shameless plagiarism), the following program would open/close your drapes in response to successive "ON" presses from the controlinc. Your timer routines can then "test" the status of this program to determine whether your drapes are open or closed (true = open, false = closed). Program "drapes open" If Control 'SWITLINC RELAY DRAPE' is switched On And Program 'Drapes Open' is False Then Turn Drape appliancelinc ON Wait 19 seconds Turn Drape appliancelinc off Else Turn Drape appliancelinc ON Wait 19 seconds Turn Drape appliancelinc off Morning Schedule If Time is [i][b]morning[/b][/i] and Program "Drapes open" is false then "open drapes" Night Schedule If Time is [i][b]night[/b][/i] and Program "Drapes open" is true then "close drapes" Note that the above will not prevent your "loved ones" from stopping the drapes in mid travel (half open). This state would be indeterminate (and very likely given my "loved ones"). Hope this helps, IM

Tracy, If your KPL's are linking you could change your condition to: If Status 'DRKL Drape Switch' is On AND Status 'MKL Drape Switch' is On Then Set 'Drape AL' On Wait 19 seconds Set 'Drape AL' Off If you've already changed to the "if Control DRKL Switched on, I'd leave things as is. Since Control functions can only be initiated at the switch (manual press) is would stop other scenes and programs from inadvertently activating your blinds. Thanks for the update. Please do post your code when you're satisfied with the operation. I'm sure you're not the only one automating drapes. IM

tcster, Nicely done. I don't see any problems with what you've posted (although testing is always in order). One additional comment - It appears that your KPL buttons are set to "toggle Mode". If that's the case you could synchronize the buttons so they both indicate the status of your drapes (my apologies if you have already done this). In order to accomplish this - 1) Change your "status" conditions to "control conditions". If 'DRKL Drape Switch' is Switched On Or 'MKL Drape Switch' Switched On This will prevent a scene of program from activating your program (it can only be activated from the KPL's). 2) Create a Scene "KPL drapes" with both of your KPL's as controllers Scene KPL Drapes DRKL as control MFL as control With the above, pressing one of your KPL buttons will activate the associated button on the "other" KPL and will trigger your program. Let us know how things progress, IM

tcster, From your description, its sounds like you are using the KPL's to directly control the appliancelinc. Could you instead use the KPL's to trigger a "Drape Controller" program in the ISY? The status of this program could then be used to indicate the position of your drapes. IM

Drew, I replied to your "other" post regarding the ISY being in safe mode. It sounds as if your PLM may have "locked up" and is not communicating with the ISY. Please try cycling power to the PLM (10 sec power interrupt) to see if it recovers. If you are using a ISY-26, remove power from the ISY first. IM

ResIpsa, I believe I'm talking "apples and apples". I have one (one) V1.65 KPL that I can program the backlight level with the ISY (no intervention required). I have 3 V1.6 KPL's that will accept the backlight programming "after a 10 Sec air gap". Please note that the V1.65's weren't plentiful when I purchased mine (SH is purging stock). The V1.65 that I received was one unit in an order of four (2 - 6 button, 2- button). I purchased the KPl's on 4/8/08. The V1.65 was a 6 button unit. I have no guess as to when "only V1.65's" are in stock. IM

Clark, The feature is implemented within the ISY. It may or may not be implemented on your KPL depending on the version. KPL Revision V1.0 to V1.4 : Not implemented. V1.55 to V1.6 : Implemented, but requires an "Air Gap" of the KPL to register. V1.65 : Fully implemented, backlight is completely controllable with the ISY. I do not have a V1.5 KPL, it may respond the same as the V1.55-V1.6 units. I suspect that it does, but don't have first hand experience. Hope that helps, IM

Vortec, My apologies for not being clear earlier. To my understanding, there is not a problem with the Sunset to Sunrise condition after the first day. Referring to the time condition below - the program summary tab should show "True" for the entire time span from sunrise to sunset. Please let us know if this isn't the case (if you see a false for times after midnight). IF From Sunset to Sunrise (next day) Then Following up on Chris's post, the problem comes in on first execution if you modify and save the program after midnight. In that instance, the ISY will wait for the next "sunset" to enable the program. In other words, if you save your program after midnight it will not become "true" until after sunset the next day. After this 1st iteration it should "initialize" and behave as you would expect (Chris - I trust you will correct me if my understanding is wrong). If you are seeing something different please get back with us and, if at all possible, post your code. Thanks, IM

huddadudda, I'm going back over posts - we're you able to resolve your IR issue? I'm curious because I'm due to receive a RF remote at some time (possibly similar problems). Is it possible that you were receiving more than one trigger from your remote (re-entering the program). This was rather common in the X10 days. IM

Vortec, I believe your statement below is correct - As of Version 2.6.4: If program1 is disabled, program2 can still execute program1 with a "run program1 (then path)" call. This will force the "then" statement (similar for the else path). If program2 uses the "run program1 (IF Path)" all of the conditions in program1 must be met to execute the "Then" path. If they are not, the "Else" path will be executed. One caveat to the above - If Program1 resides in a conditional folder (and it's condition is false), you will not be able to execute it from program2. While there have been some complaints regarding the "Sunset to Sunrise" time condition, most of these were misinterpretations of how the conditional ran on first execution. I'm not sure if your description fits into that category. As you noted, there are workarounds for this condition, but that shouldn't be necessary. While there have been changes to the "Schedule catchup" in version 2.6.4 (it's now configurable), I'm not aware of any problems with the function. Could I impose upon you to post your program? You can copy a program by right-clicking on the program name in the left hand "program tree". Select "copy to clipboard" and then past into your forum post. Thanks, IM

Drew, The else loop is executed when your "IF" condition evaluates to a false. In the example below, if both the Time and the Away conditions are true the "then" loop is executed (executing the away scene). If either of the conditions are false, the "else" loop is executed (turning the scene off). If Time is from Sunset + 30 Minutes to Sunrise (next day) And Status "Away Mode" is ON Then Set Scene 'All Dim' On Set 'Deck KPL A Decklight' 65% Send Notification to All Set 'Barn' 70% Else Set Scene 'All Dim' off Set 'Deck KPL A Decklight' off Set 'Barn' off IM

Drew, A couple of potential problems with the below - 1) I don't see where you are turning your lights off (another program possibly). 2) In your "THEN" statement - you are activating the "ALL DIM" scene. If this changes the status of the devices in your "IF" statement (HALL KPL, Big Room, or Kitchen), your conditional will retrigger and revert to a "false". The statements following your "ALL DIM" scene may not be executed. Rather than "inferring" that you're not at home from the status of your lights, would it be easier to dedicate a KPL button to "AWAY MODE"? If Time is Sunset + 30 Minutes And Status "Away Mode" is ON Then . . . IM

Morgan, First - I'm assuming that your dimmer activates every time you activate this scene - correct? If that's the case we should be able to rule out noise "spontaneously" commanding the device on. If that is that case (you're not seeing device communication errors), please try the following sequence. 1) Please post your program. 2) Air gap both of your KPL's, and run your scene program (you'll get comm errors - don't worry about it for now). If your dimmer activates, you may have a stray link in the PLM (I've never seen this) or a second program triggering off of the KPL status change. Please post your results. 3) If #2 does not turn on the dimmer - enable one of your KPL's at a time and run your program. If the dimmer turns on with one of these devices "ON-line" it may have a stray link that was imported to the ISY (the reason the restore didn't work). Please post your results. 4) If enabling one of the KPL's causes the dimmer to activate, you will most likely need to delete the device, perform a factory reset, and totally rebuild your scenes and programs. Please post prior to doing this (it's a lot of effort). To be honest, I've never experienced the problem you are having. I have seen devices turn one due to stray X10 addresses (should have been eliminated by the factory reset). Your problem does sound similar to one encountered by UpstateMike back in Feb. That thread is located here: http://www.forum.universal-devices.com/viewtopic.php?t=900&highlight=ghost IM

bhlonewolf, As Michel and Michael stated, the ISY does not currently include a command to "extend" or multiply a wait time. As MikeB stated, there is an enhancement in the works to include "variables". This would presumably allow you to pass a multiplier to a subroutine to "extend" a variable wait time. You can achieve a variable delay with the current instruction set - but it's not exactly easy and it's rather cpu intensive. After killing way too many brain cells (Sunday, Nascar, Aluminum cans) I managed to come up with the following: http://www.forum.universal-devices.com/viewtopic.php?p=8531#8531 This probably won't make a lot of sense since you don't yet have a ISY. It makes use of the ISY ability to qualify a trigger based on programs that ware currently running. Not at all pretty, but it could be adapted to serve your purposes. I've been using this in my bathroom for a 5, 10 20 minute timer. I'm sure there are far better ways of doing this with the current command set, but I', the brute force type. When someone shows me a better method, I'll hapilly adopt it. Being a previous user of X10 and AHP, the above was extremely easy and straightforward. Just a sample of what you can do with the ISY, IM

Rowland, Good catch - thanks for cleaning up my mis-information. IM

Morgan, Thanks for the clarification - it's crystal clear now. You're correct that activating the "LED" scene should not affect your dimmer (but you already knew that). Please check your activity log. If it shows your dimmer activating at the same time as your LED scene you may have a program that is triggering and commanding the device on. If there is no log entry for your dimmer, my best guess is a link that existed in one of your KPL's before you created your scene. I'm not sure if a "device restore" will eliminate this link (my previous question for Michel and Chris). If you're interested, there is a "Scan Z" utility that will show links in a given device. Try a search on Scan Z and Telnet on the forum. IM

morgan, Allow me to recap to make sure that I have this correct - 1) You have 2-8 button KPL's with secondary buttons included in a scene. Both KPL's are responders in this scene. 2) You have a 3rd dimmer that is linked to the KPL's, but the KPL's are responders. 3) When you activate your KPL scene (no other devices in the scene) a linked dimmer (that the KPL's are responders to) turns on. If the above is correct (please verify) the following suggestions may/may not apply: 1) Check your log - If the ISY sees the dimmer turning on, you have a control link or program somewhere instructing it to do so. 2) If the ISY log does not show the dimmer activating, you may have a stray link in one of your KPL's. This can happen if you "imported manual links" when using the ISY linking rather than "replacing Links". Try factory resetting the KPL's and then restoring?? Question for Michel / Chris - does the restore function "restore" links that were imported? 3) If #2 does not work, you may need to delete one/both of the KPL's and rebuild. Obviously this is rather painful. To be honest, I'd wait for additional input from the "gurus" prior to taking this step. IM

huddadudda, The fade should function as Darrell had described. I use a very similar setup with timed triggers to notify my family that "bedtime" is approaching. If your routines function part of the time, there is something else going on (noise, comm errors, conflicting program). Would you be kind enough to post your code and elaborate on the "intermittent" behavior? IndyMike I tired this however fade stops dont work well for some reason on scenes for me. Can you think of any other way to do this? I had a similar scene in my Home Theater Room where when I hit the "HTR Off" button on my pronto remote then my ISY99ir would fade the lights down then wait 5 mins before turning off so I knew that the command was recieved - it worked a couple times but then became unrliable and finally stopped working all together.

Clarence, My apologies - I didn't read far enough back in the posts to discover that you were using the Mac OS. From your post previous to this - I'm assuming that the new update that you loaded was the Java 1.6 update that RatRanch was referring to? Past that, I'm pretty much useless when it comes to a Mac. Just trying to set things up for the experts (the ISY team). IM