IndyMike

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

C Martin, I believe there was an issue with program sorting when using lower screen resolutions (my 1024 X 768 laptop would not sort). This seems to be resolved with 2.6.4. My laptop now sorts the Program Summary window with a resolution of 800 X 600. Could you provide some additional detail - resolution, OS? IM

Ed, Just to be clear, I believe that my issues were due to an excessive amount of X10 activity on the powerline while I was attempting to link. Once I disabled the X10 transceiver the linking went smoothly. If you believe your new switch location may have noise issues that are preventing linking, I have a little trick that may help. I typically run a pre-check on new units by wiring them to a 14/3 power cord. A replacement cord for a power saw will typically suffice (3-prong). Simply pigtail the Hot, Neutral, and ground and then cap the switched output (red). Plug the cord in next to your PLM and link away. If you are concerned about having the pigtail connections "in the open", you could also pick up a plastic outlet box and terminate in the box. If this works, it will serve to confirm that the actual device location has a problem (Noise or signal level). IM

Michael, I ran into a similar problem trying to "tap link" a KPL yesterday. In my case, I attribute the difficulty to the fact that I had not disabled my X10 transceiver. During the linking process I was walking past and triggering multiple X10 motion sensors. When I returned to the ISY GUI it was unable to locate the KPL. I disabled the transceiver and retried the link using the ISY manual link option (New Insteon Device - Insteon address entry). This correctly identified and installed the device. IM

Clark, My apologies for taking this sideways - I'll return things to the capable hands of Michel and Chris. IM

Clark, From your description, it sounds as if you may be dealing with a good old fashioned Windows Networking problem. This should not have caused your original missed schedule (power interrupt?), but could definitely contribute to the loss of the ISY link in "network neighborhood". There are a number of ways to work around the loss of the network neighborhood ICON. 1) The first is to visit the ISY site and select the "my ISY link" (not necessarily the most expedient). 2) The second would be to type the ISY IP address into internet or windows explorer (192.168.0.XX) - my preferred method. This is both quick and reliable. Option 2 assumes that the ISY is always assigned a given address. This is possible with most routers (mine is rather dated), even when operating under DHCP. This is also a good idea from the standpoint of your network security. If you would like more information on restricting IP addresses to particular MAC addresses, please post back with your operating system and router model. Your underlying network problem may be due to your "master browser" configuration. With 14 network devices on my home LAN (Windows, Linux, Printers, ISY, Playstation, Wii) I've fought this a number of times over the years. Try a google search on "home networking" and "Master browser" - there are a number of tutorials on the WEB that are far better than what I could provide. IM