IndyMike

Steve, Welcome to the forum. You've picked a rather complicated task for automation. In my opinion, while your goals can be accomplished, I would not choose any automation technology to implement it. You situation is complex because you have an existing system. Your ductwork, vents, and cold air intakes have all been sized to provide the proper airflow across the heat exchanger in your furnace. If you begin to shut off sections of the ducting via zone controls, you will reach a point where the airflow is insufficient across the heat exchanger and it will overtemp and shut down. At best this is inefficient. At worst you will continually overtemp the exchanger and cause premature failure. This becomes more complex if you have A/C. A/C coils also require a minimum amount of airflow across them to prevent freezing the unit. The problem here is that the cool air is heavy and doesn't want to be pushed to your second floor. Normally a furnace will use a 2-speed blower to overcome the heaviness of the cold air. If you implement a zone system to for more air to the second floor, you risk reducing the airflow below the minimum level. If coil freeze up does occur you can feed liquid freon back to the compressor (outside) and destroy it. Retrofit zoned systems typically include a "barometric bypass" (dump zone). This is essentially a vent that opens when the system is constricted (zones closed) in order to provide enough airflow across the heat exchanger/A frame. Next come the "Zone Control Panel". This dedicated panel interfaces to the multiple thermostats, controls the zone dampers, and monitors the furnace temperatures to prevent over stress. This is the piece of the puzzle that I would not trust to automation. The next step is the thermostats themselves. Here you have the latitude to use HA. For your problem with the fireplace you could use an Insteon compatible thermostat and simply monitor the room temp. When the room rises above a certain temperature (heat mode) turn on the circulating fan to warm the rest of the house. No much, but it will help. Give us some more details on your heating distribution problems. Is the upstairs cold during winter and hot during summer? You may need more insulation in the attic or "tuning" of your existing vents. Sorry for the "downer", but this isn't a simple job. IM

Eddy, I don't believe there is currently a method for copying an entire scene at the scene level. You can, however, perform a copy of all the units within a scene. 1) Create your "new" scene. 2) Select the units (highlight) that you wish to copy from your "master" scene. You can use the "shift - left mouse click" method to select a list of units or use "Crtl - left mouse click" to select specific units. 3) Once highlighted, press "ctrl" and "left mouse click" on the units. Drag them to your new scene. In response to the above, the ISY will prompt you with your list of units and inquire whether you want to make them controllers/responders. The ISY will copy the unit attributes (level/ramp rate) from your master scene. It will not copy the "scene attributes".

Is "deleting the temporary files" from the Java Control Panel the same as "clearing the classloader cache" from within the Java Console?? Honest question, I really don't know. If the classloader cache is not being cleared, it would explain a number of jtara92101's problems. Have you tried clearing your Java cache after the update? Yes, I did. That is, assuming that "clearing your Java cache" means "go to the Java Control Panel and delete the temporary files". (Yet another documentation issue...) As well as power-cycled the device and rebooted from the telnet console. None of this worked.

Rich, As Mike B has indicated, I have not needed delays when using Insteon only Scenes. I have required delays when mixing Insteon and X10 protocols. It's possible that one or more of your devices have "stray" X10 codes left over from factory testing. This might interfere with your scene execution (your Family Room Light or outletlincs may be communicating X10 when your scene is activated). You can check for X10 activity within the ISY admin console. Go to "tools" and select the "event viewer". Activate your "Family Room Light" and watch for X10 communications. I am very curious whether this is the cause. I would expect that the PLM would "hold off" communication while X10 is present. I am sure, however, that there is a limit to this hold period. If you had two or more devices with X10 codes transmitting, you might exceed a timeout period. Please get back with us. Regards, IM

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