IndyMike

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

Michael, I think we're mixing terms here. Your program is set to trigger at 10:01 PM if the Icon status is true. The Icon status condition is not a query. It is either a current "logged status" of the device or it can be an event (a status change in the device). Since you are using the time condition with the status your Icon 2 is operating on the "logged status" of the device only. Chris's comment was that this program did not need to be within a conditional folder. That comment is still valid - the program is already time constrained, putting it in a (time) conditional folder doesn't add anything. On the flip side, having this in the conditional folder shouldn't hurt anything either. Unfortunately, due to the status bug, having this within the conditional folder makes it intermittent. When I referred to "querying" the status of the device within the folder I was using a separate program. This program ran immediately after the folder was enabled and specifically queried the status of the devices. Unfortunately this didn't work either. Conditional folders are a nice "feature" afforded by the ISY. It allows you to group programs that run according to a particular condition. If also speeds program execution since the folder condition need only be evaluated once. I do not know of a scenario where a folder "has" to be a conditional. All of the programs that you've posted should function if you place the conditions within the program itself.

Chuck, I'm at a loss to explain that activity. If everything was "factory reset" your 2476D should have ignored anything the ISY/PLM sent out. Insteon devices repeat transmissions. Each repeat is referred to as a "HOP". Every transmission includes "MAX HOP" and "HOPS Left" codes embedded within it ( 0 - 3 HOPS). When a receiver "sees a transmission it will repeat the transmission until the Max Hop or Hops Left limit is reached. I believe the ISY transmits with a constant "max hops" of 3. In your configuration with the PLC and the PLM on the same outlet, the PLC is generally a "stronger transmitter" (at least in the past). Depending on your system layout, it could be possible for your PLC to absorb enough of the PLM transmission so that it would not reach another Insteon module. The PLC would then "repeat" the transmission (burn a HOP) in order to reach other units. In actuality, the PLC will always repeat the transmission (up to max hops). The real problem is that none of your "other" devices will have heard the original PLM transmission (no repeating from other devices) and thus the "burned hop". If you're interested in the specifics of the protocol (rather than my ramblings) there's an Insteon White paper here: http://www.insteon.net/pdf/insteonwtpaper.pdf IM

Hi Chuck, Happy to hear that things appear to be working better. Assuming that your garage ISY/PLM weren't sharing links with your main install, your House Installed PLM should have ignored the traffic (not linked). The Insteon devices in your house would have acted as repeaters and your Accesspoints/Signalincs should have been connecting the phases. Is it possible that you exceeded the bandwidth of the network with heavy traffic from the garage? In the future, if you plan on performing more customer setups, you might want to consider a blocking filter in your garage. I use a couple of dedicated ACT filters to provide 220V filtered power to my "play room". It prevents undue aggravation for the rest of the family members. While I've never run 2 PLM's, I am currently using a ISY-26/PLM (dedicated circuit) with 2 X10 CM15a's and a PLC on another circuit (PLC is used for monitoring only). Whether or not you have communication problems with the PLM and PLC on the same outlet depends on your configuration. The PLC will act as a signal absorber (and vice-versa). If the devices near other Insteon repeaters this should not matter. If your repeaters (any Insteon device) are distant this could create a problem (or at least use a Insteon HOP). IM

Digger, Actually I think we're both missing something (I thought the same thing). The problem is, I tried issuing a status request once the folder became enabled and things still did not update properly. I am not sure why. We probably need Chris for this, but I'd prefer not to overload him with questions when he is already working the issue. IM

Chuck, An update on the problems that you observed - Chris Jahn has identified a problem with STATUS conditions used within a Conditional Folder. Chris has included this as an item to be addressed in the next update. The post regarding this problem is located here - http://forum.universal-devices.com/viewtopic.php?t=1189 The root of the problem deals with the fact that the device status is not updated (within) the folder when the folder is disabled. When your folder is first enabled, it's status reflects the status of the devices when the folder was last closed (which may be different than what the ISY is currently displaying). The workaround for the moment is to move the time conditional out of the folder and into your individual programs. I'm not sure what your folder time condition was - I've tried to show general code markup for eliminating the folder condition and moving it into your code below... IM

Michael, The specific problem with your program below (and in the other thread we were working on) is the following - 1) On the previous day, your Folder became disabled with your ICON 2 Status as ON. 2) On the current day, the Folder became re-enabled and the ICON 2 Status was not updated. Your folder considered this device to be ON (last observed condition) even though your ISY program tree understood the status was OFF. 3) At 10:01 the program enabled (time condition) and operated on the Old status - calling your pager program. I've tried a number of methods for updating the status within the folder (queries etc.) but have been unsuccessful to date. For the time being, I believe the workaround is to remove the folder condition when using Status conditions. This should not be a problem if you are using strictly Time Based, or Control conditions as these do not depend on the current status of the device. IM

Chuck, Had another thought in regard to the following. The only folder condition is the time of day and the status of the folder condition is True. Consider the following regarding your folder time condition - 1)Initially lets say that you are within the time window of your folder condition. 1a) One of your devices is ON and your program correctly reverts to a false condition. 2)At a later point in time the folder becomes disabled. 2a) Your devices transition to "all off" 2b) Your program status will not update because the folder is disabled. 3)Time passes again and the folder becomes enabled again. 3a) I don't believe your program will run at this point because it "needs" a status change (event) to trigger it. 3b) Your device tree will show all devices off, but your program will remain "false" until a status event triggers it within the time window of the folder. The above does not explain everything that you have observed. It could explain a disagreement between your program and the actual device status after the program is enabled. Cycling one of your devices should retrigger the program and get things synched up again. You may want to move this routine outside the "timed folder" and place the time constraint within the program itself. IM

Chuck, Glad to here that the "alloff" worked. Keep in mind that this was just a troubleshooting step, nothing has been fixed as of yet (unless removing your lamplinc fixes the problem). As I stated previously, all of the devices in your original program are observable from the device tree. If their status indicated "off" your program should have returned a "true". The fact that it showed a "false" indicates that something was "stuck". I'm trying to come up with a scenario where the ISY might declare a device as "faulted" due to a communication error. This might prevent programs from triggering properly. I'll keep you posted as well. This is a LampLinc. I have removed this in the past remembering something about them not always returning status properly. Do you know what the actual limitations are with LampLincs in this regards? Lamplincs are really just responders. They can't command scenes or announce their On/Off status to the PLM. Even so, if your ISY showed this device as off, your program should have responded correctly. All Off from the main console does work. I substituted the SwitchLinc linked to the LampLinc and it is working (for now). I will keep you posted. Unlike the Lamplinc, your Switchlinc will communicate it's status to the PLM. The ISY will "infer" that the Lamplinc has turned on since the scene has been activated (no direct confirmation here). I'd be very curious if this solves your problem. IM