IndyMike

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

Chuck, Sorry to here that you're still experiencing problems. In the above, you refer to "removing the filterlincs" - and things improved. Did you intend to say "signalincs"? You also mentioned restoring the KPL. What caused you to restore the KPL and what were the changes as a result? If Status 'Basement Playroom Lights (loa' is Off And Status 'Dining Room - LIGHT (load)' is Off And Status 'Dining Room Ceiling Fan (load' is Off And Status 'Kitchen Ceiling Lights (load)' is Off And Status 'Kitchen Sink Light (load)' is Off And Status 'Living Room Ceiling (load)' is Off And Status 'Office Ceiling Light (load)' is Off And Status 'Living Room Lamp (load)' is Off Then - No Actions - (To add one, press 'Action') Else - No Actions - (To add one, press 'Action') I can't see anything wrong with the above code. All of the devices are load bearing (no kpl secondaries) and therefor should be completely observable by the ISY (with the possible exception of your lamp). If the ISY indicates that all of the devices are "off" the program should indicate true. Is there a folder condition that might prevent the program from running (and recognizing a status change)? This really sounds like the ISY believes that one of the devices in your conditional is still on. Under those conditions the program would re-trigger and indicate false. The only device in your list that isn't "completely observable" is your Lamp (I assume this is a lamplinc). Could you try a "all off" from the main program tree to see if this rectifies the problem (not a solution mind you). If this works, could you try removing the lamplinc from the condition?

Illusion, The UDI guys have been foretelling of a new firmware version that they refer to as "triggers 2". This may also include variables. Using a variable you could conceivably count switch presses within a predefined period. That would be the ultimate solution to your problem. I did manage to come up with a brute force method (such is my way - if it ain't broke take it apart and see what makes it tick). I initially tried using a trigger "xx seconds after program yy last run". This didn't function at all the way that I expected. The following will count three consecutive presses (three timer values) and will flash the light to confirm which timer is active. You will need to be careful not to "double press" (fast on) as the routines aren't setup to register this. Program Press1 If Control 'Test Switch' is switched On And Program 'Timer1' is False And Program 'Timer2' is False And Program 'Timer3' is False Then Run Program 'Timer1' Else - No Actions - (To add one, press 'Action') Program Press2 - Will interrupt program Press1 and shut down timer1 If Control 'Test Switch' is switched On And Program 'Timer1' is True And Program 'Timer2' is False And Program 'Timer3' is False Then Run Program 'Timer2' Run Program 'Timer1' (Else Path) Else - No Actions - (To add one, press 'Action') Program Press3 - Will interrupt program Press2 and shut down timer2 If Control 'Test Switch' is switched On And Program 'Timer1' is False And Program 'Timer2' is True And Program 'Timer3' is False Then Run Program 'Timer3' Run Program 'Timer2' (Else Path) Else - No Actions - (To add one, press 'Action') Program Timer1 - Single press timer - Control trigger used to shut down program prior to normal timeout. 2 second delay included to allow timer3 program to interrupt execution and take control. If Control 'Test Switch' is not switched Off Then Wait 2 seconds Set 'Test Switch' Off Set 'Test Switch' On Wait 20 seconds Set 'Test Switch' Off Run Program 'Timer1' (Else Path) Else - No Actions - (To add one, press 'Action') Program Timer2 - Double press timer - Control trigger used to shut down program prior to normal timeout. 2 second delay included to allow timer3 program to interrupt execution and take control. If Control 'Test Switch' is not switched Off Then Wait 2 seconds Set 'Test Switch' Off Set 'Test Switch' On Set 'Test Switch' Off Set 'Test Switch' On Wait 40 seconds Set 'Test Switch' Off Run Program 'Timer2' (Else Path) Else - No Actions - (To add one, press 'Action') Program Timer3 - Triple press timer - Control trigger used to shut down program prior to normal timeout. Flashes the load 3 times to confirm activation If Control 'Test Switch' is not switched Off Then Set 'Test Switch' Off Set 'Test Switch' On Set 'Test Switch' Off Set 'Test Switch' On Set 'Test Switch' Off Set 'Test Switch' On Wait 1 minute and 20 seconds Set 'Test Switch' Off Run Program 'Timer3' (Else Path) Else - No Actions - (To add one, press 'Action') Not pretty, but it seems to work reasonably. I was using direct ON/Off commands to a relay module. Using scenes or ramp-rates (not fast on/fast off) may cause problems with the confirmation (flash) timing. IM

Digger, It's got to feel great to make some progress after all this time - congratulations. When you get a chance, could you update us on the version/date code of the switches that were giving you a problem? Thanks, IM

Michel, Message received on the replace option. I'll put some workarounds in place and wait for 2.6.4. I checked my NODESCNF.XML file. I do have some groups with elements less than 20 (not in my problem scene). I remember seeing something about this some time back, but have forgotten the implications. The PLM is ~ 2 months old (upgraded to a 2.75), but everything was imported from a PLM purchased in Aug. Thanks again, IM

Michel, I had thought about using the "Replace" but was surprised to find that it was no longer available with V2.6.3. I'm trying to figure out the thought process here. If I use a replace and the problem is duplicated on the new device, that would indicate a corrupted ISY configuration file - correct? If the problem isn't duplicated, I have a problematic Switchlinc? I'm thinking about rolling back to V2.6.1 to give this a try. Is that advisable, or is there a problem with the "replace" under 2.6.1? I'm a bit curious as to why it was pulled under 2.6.3. CORRECTION (4-7-08) - Replace is still available under V2.6.3. I may have "clicked" on a KPL secondary when looking for the option. Sorry for the confusion. Thank you, IM

RLIKWARTZ, Another possible solution would be to use X10 to trigger your program. When the outletlinc is triggered locally it will send an X10 On/Off at it's assigned housecode/Unit code. It's probably doing this now without your knowledge. I call this a "possible solution" because, if you're not set-up for x10, your PLM/ISY may not be able to hear the X10 transmission. Insteon devices can communicate in X10 but they do not repeat it (no amplification) and accesspoints/signalincs will not couple it to the opposite phase. If your PLM/ISY is one the same electrical phase as your outletlinc it might be worth a shot. Let us know, IM

Illusion, Thank you for pointing out a rather glaring omission in my post. I never stated what the actual problem was. I've edited the original post to include this information. I'd be interested in your opinion. The bottom line problem with my original program was the following - 1) I was using a status trigger on my "Master KPL 1st FL" to start the program. 2) The program modified the Scene '1st Floor Off'. The "Master KPL 1st FL" was a member of this scene, so it's status was changed. 3) The status change in the "Master KPL 1st FL" caused the program to re-trigger with some interesting results. This is what I was attempting to document. All of the above is prevented by using a "Control" trigger. A control trigger is not affected by scene induced changes. Sorry for the confusion, IM What does this mean? I do not understand why the second bit of code does not work but the first one did.

Hello Learned Members, After performing some rather nasty stress testing last night, I found that one of my Switchlincs had lost it's link table. I could control the device directly from the GUI, but it no longer responded to scenes and the PLM did not recognize a status change initiated at the switch. Oh well, Device Restore to the rescue - problem is, it didn't rescue me. I have successfully used the Device restore with KPL's on several occasions. It's a huge time saver that has really saved my derrière with the KPL's. For some reason, it isn't working with this particular Switchlinc and I'm curious why. Call it my need to know. To date I've performed every combination of "factory reset" and restore that I can think of (PLM and SL). I've also restored the ISY from a backup. I simply can't get the links back into this device using a restore. Here's the configuration (Entry Patio is my problem device): SC Ouside Night Master KPL Entry: Responder Mud KPL Entry Garage: Responder Entry Porch: Responder Fam KPL Entry: Responder Entry Patio: Responder Entry Deck: Responder SC Outside Status: Master KPL Entry: Responder Fam KPL Entry: Responder SC Outside Sunset: Master KPL Entry: Responder Mud KPL Entry Garage: Responder Entry Porch: Responder Fam KPL Entry: Responder Entry Patio: Responder Entry Deck: Responder Symptoms - 1) ISY cannot "hear" changes initiated at the Switchlinc. I interpret this as meaning that the SL has lost the link to the PLM. 2) I cannot control the Switchlinc through either of my two scenes. I interpret this as meaning the the SL has lost the scene (or group) link as well. 3) I can control the SL through the My Lighting tree. I believe this is a "direct" address command to the device. 4) I can query the device from the My Lighting tree (similar to 3 above). I realize that I can correct this situation by performing a manual remove/add device. This rather painful procedure was common before UDI perfected the "Device Restore". To prove this, I removed/added the SL to my "outside sunset" scene. It now functions normally within that scene. At present, I have not restored the link for my "night scene" or the link to the PLM itself. I'm looking for guidance on how to determine why the "restore" is not working for this particular device. I'm a bit concerned that others, when encountering the same problem, might interpret this as being signal related. I've seen numerous posts regarding scene problems with devices that were physically next to one another (one works the other doesn't). In troubleshooting issues like this, I had assumed that a device restore would rule out the possibility of link table corruption. Obviously I was wrong. Thanks in advance, IM ISY-26 V2.6.3 Rev 2.75 PLM

Thanks Mark. I'm due to loose those braincells around 6:00 PM tomorrow (final four tipoff). IM

Gents, The short Answer: Standard Bright/Dim commands require a series of concatenated commands to achieve a particular level. They don't obey normal X10 protocol, they're extremely hard on repeaters and receivers (easy to mis-interpret), and they take forever to transmit (over 5 seconds for a 100% bright command). Preset dim commands allow you to command a device directly to a particular level. The old X10 protocol allowed 32 different levels to be commanded through "Preset Dim1" and "Preset Dim2" commands (16 levels each). 1) Preset Dim(4) - The "4" specifies a "Preset Dim1" command (0 to 48% bright). This must be used with a "letter code" to specify the "dim level" (see table below). 2) Preset Dim(12) - The "12" specifies a "Preset Dim2" command (52 to 100% bright). Using this command with the ISY is a bit different from "standard" X10 commands. 1) You must first address your device with a House/Address code and NO Command. Use the ISY "NO Command" from the drop down command list. 2) You then send the preset command with a house code that corresponds to the Bright/Dim level that you desire. A) Specify the Housecode (M,N,O...) Specify no unit code ( use the "-" on the unit code drop down). C) Select Preset(4) (0 to48% bright) or Preset(12) (51 to 100% bright) If - No Conditions - (To add one, press 'Schedule' or 'Condition') Then Send X10 'B3' (Address device) Send X10 'M/Preset Dim (4)' (Send Preset Dim1 Level=0%) Wait 10 seconds Send X10 'B3' (Address device) Send X10 'J/Preset Dim (4)' (Send Preset Dim1 Level= 48%) Wait 10 seconds Send X10 'B3' Send X10 'M/Preset Dim (12)' (Send Preset Dim2 Level = 52%) Wait 10 seconds Send X10 'B3' Send X10 'J/Preset Dim (12)' (Send Preset Dim2 Level = 100%) Else Send X10 'B3/Preset Dim (12)' The above is an adaptation (for the ISY) from an article from fellow Hoosier, and X10 Guru, Uncle Phil Kingery. If anyone is interested in the "nuts and bolts" of the above, the long answer is located here: http://www.act-solutions.com/PCC/kingery18.htm Actual X10 protocol (command structure) is located here: http://www.act-solutions.com/PCC/kingery13.htm Hope this helps, IM Edit: Replaced links from the old Geocities site (offline - sorry)

Illusion, You'd be thinking correctly. Darn higher math tripped me up again. Thanks for the correction, IM