Chuck Posted March 8, 2008 Share Posted March 8, 2008 If ( Status 'Basement Playroom Lights (loa' is not Off Or Status 'Dining Room - LIGHT (load)' is not Off Or Status 'Dining Room Ceiling Fan (load' is not Off Or Status 'Kitchen Ceiling Lights (load)' is not Off Or Status 'Kitchen Sink Light (load)' is not Off Or Status 'Living Room Ceiling (load)' is not Off Or Status 'Living Room Lamp (load)' is not Off Or Status 'Office Ceiling Light (load)' is not Off ) And Status 'Living Room - ALL OFF' is not Off Then Wait 2 seconds Set Scene 'ALL OFF LED' Off Wait 10 seconds Set Scene 'ALL OFF LED' Query Run Program 'ALL OFF LED - Off (Daytime)' Else - No Actions - (To add one, press 'Action') The All Off LED referred to in this program is now ON as I write this even though 5 of the loads are ON. The program status is False. Any ideas why the LED status intermittently (like once every other day) does not reflect the correct status? I have tried many versions and alterations to the "LED Status" programs including the one above, which does an additional Query of the LED and runs the program again just in case there was a communication issue in turning the LED On or Off. Thanks. Chuck Link to comment
IndyMike Posted March 8, 2008 Share Posted March 8, 2008 Hello again Chuck, Your code below is changing the status of your condition 'Living Room - ALL OFF' is not Off. When this is executed the program status be changed to "false" and the statements that follow will not be executed. The fact that you require the status check may indicate that you're having communication problems with your device. Executing the scene "All off LED" off should work by itself. You may want to focus your efforts on improving the device communication rather than "re-querying" the device. If you feel you need to check the status of the lamp, you should divide things up into two programs to prevent changing the state of your conditions within the program: If ( Status 'Basement Playroom Lights (loa' is not Off Or Status 'Dining Room - LIGHT (load)' is not Off Or Status 'Dining Room Ceiling Fan (load' is not Off Or Status 'Kitchen Ceiling Lights (load)' is not Off Or Status 'Kitchen Sink Light (load)' is not Off Or Status 'Living Room Ceiling (load)' is not Off Or Status 'Living Room Lamp (load)' is not Off Or Status 'Office Ceiling Light (load)' is not Off ) And Status 'Living Room - ALL OFF' is not Off Then Wait 2 seconds Run Program 'ALL OFF LED - Off (Daytime)' Else - No Actions - (To add one, press 'Action') Program 2 sets the scene OFF and tests the status. If the status comes back "ON" I would assume that the ISY would treat this as an "event" and Program 1 would again become true (triggered by the event "Status 'Living Room - ALL OFF' is not Off"). I haven't tried triggering programs with status calls. Hopefully someone else can confirm if they function in this manner. If No conditions Then Set Scene 'ALL OFF LED' Off Wait 10 seconds Set Scene 'ALL OFF LED' Query (if the light is on, the ISY will hopefully see this as an event and call the original program) Else No actions Be careful with this code - If you cannot turn the indicator lamp off for some reason, you may wind up stuck in a loop (querying and re-triggering the original program). IM If ( Status 'Basement Playroom Lights (loa' is not Off Or Status 'Dining Room - LIGHT (load)' is not Off Or Status 'Dining Room Ceiling Fan (load' is not Off Or Status 'Kitchen Ceiling Lights (load)' is not Off Or Status 'Kitchen Sink Light (load)' is not Off Or Status 'Living Room Ceiling (load)' is not Off Or Status 'Living Room Lamp (load)' is not Off Or Status 'Office Ceiling Light (load)' is not Off ) And Status 'Living Room - ALL OFF' is not Off Then Wait 2 seconds Set Scene 'ALL OFF LED' Off (Program status changes to false when this is executed) Wait 10 seconds Set Scene 'ALL OFF LED' Query Run Program 'ALL OFF LED - Off (Daytime)' Else - No Actions - (To add one, press 'Action') The All Off LED referred to in this program is now ON as I write this even though 5 of the loads are ON. The program status is False. Any ideas why the LED status intermittently (like once every other day) does not reflect the correct status? I have tried many versions and alterations to the "LED Status" programs including the one above, which does an additional Query of the LED and runs the program again just in case there was a communication issue in turning the LED On or Off. Thanks. Chuck Link to comment
Chuck Posted March 8, 2008 Author Share Posted March 8, 2008 Thanks Mike. I did end up removing: Wait 10 seconds Set Scene 'ALL OFF LED' Query Run Program 'ALL OFF LED - Off (Daytime)' (This is the program itself) This takes me back to where I started. I agree, this should work. And it does - most of the time. I'm not sure what else to do to ensure it works all of the time. (It's working right now) Chuck Link to comment
IndyMike Posted March 8, 2008 Share Posted March 8, 2008 Chuck, Intermittent problems are often the worst kind. Unfortunately, I don't believe the ISY can ascertain that a command sent to a KPL secondary button has been properly received. It assumes that the Insteon communications are intact and uses a predictive status (I sent the command, therefore the device is on/off). If your communications are less than "stellar" you get the results that you are seeing now. As an example, I have a very similar "status monitor" setup on a KPL. I can air gap my KPL and execute the program and the KPL secondary status registers "ON". That's obviously not possible since I've removed power from the device. I understand that you're trying to work around this problem with software in the ISY. Just my opinion, but I believe your time would be better served if you improve the communication to the device itself. Unfortunately, the nature of Insteon communication makes it very difficult to troubleshoot. I've used a ELK-ESM1 and a PLC to listen to communications with limited success. In the end, the old X10 methods of mapping, isolating, and filtering problem devices do appear to work with Insteon. FWIW, the following has worked well for me (both X10 and Insteon). 1) PLM on dedicated circuit next to the breaker panel (basement). 2) Passive coupler at the breaker panel. 3) Signalincs located on second floor. Other possibilities - 1) Check your signalincs/accesspoints to make sure they haven't locked up (they're still communicating). 2) Consider moving a signalinc/accesspoint to the same circuit as your problem KPL. 3) If you have a BoosterLinc installed (or devices with Boosterlinc capability) - pull it. Once my Insteon installed devices grew beyond 25, Boosterlincs became a problem. Let us know where you stand, IM Link to comment
Chuck Posted April 9, 2008 Author Share Posted April 9, 2008 I tried the SignaLincs - one on the same circuit as the KPL and placed near the circuit panel and one on an opposite leg, also near the circuit panel. This seamed to have caused more problems. Sometimes the All Off command would not even turn off the same KPL's LEDs even though they are in the same "All Off Scene" as the rest of the devices. I removed the FilterLincs and things improved. I restored the KPL in question. This is my current program configuration: 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') If Program 'All Off Status (Daytime)' is True And Status 'Living Room - ALL OFF' is not On Then Wait 2 seconds Set Scene 'ALL OFF LED' On Else - No Actions - (To add one, press 'Action') If Program 'All Off Status (Daytime)' is False And Status 'Living Room - ALL OFF' is not Off Then Wait 2 seconds Set Scene 'ALL OFF LED' Off Else - No Actions - (To add one, press 'Action') The first section is the "All Off Status (Daytime)" program. I tried this version after reading Darrell Peters' "'All Off' button/status -- one more twist" - good post Darrell. Right now all devices are Off and display as such in the Admin Console. Under the Program Summary tab, "All Off Status (Daytime)" status is False (when it should register as True). All other commands from the KPL work. All devices linked to the KPL work and the KPL refects their status properly. Another observation: When I turn one of the devices in the "All Off Scene (Daytime)" on or off the "Activity" column for "All Off Status (Daytime)" stays as "Idle". The "Last Run Time" does update. The "Status" remains as "False". Any suggestions??? Thanks. Chuck Link to comment
Chuck Posted April 9, 2008 Author Share Posted April 9, 2008 One more observation: If I manually select "Run" for the "All Off Status (Daytime)" program, the status changes to "True" and the KPL's "All Off" LED turns ON (as it should)! Link to comment
IndyMike Posted April 9, 2008 Share Posted April 9, 2008 I tried the SignaLincs - one on the same circuit as the KPL and placed near the circuit panel and one on an opposite leg, also near the circuit panel. This seamed to have caused more problems. Sometimes the All Off command would not even turn off the same KPL's LEDs even though they are in the same "All Off Scene" as the rest of the devices. I removed the FilterLincs and things improved. I restored the KPL in question. 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? Right now all devices are Off and display as such in the Admin Console.Under the Program Summary tab, "All Off Status (Daytime)" status is False (when it should register as True). 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)? Another observation: When I turn one of the devices in the "All Off Scene (Daytime)" on or off the "Activity" column for "All Off Status (Daytime)" stays as "Idle". The "Last Run Time" does update. The "Status" remains as "False". 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? Link to comment
Chuck Posted April 9, 2008 Author Share Posted April 9, 2008 In the above, you refer to "removing the filterlincs" - and things improved. Did you intend to say "signalincs"? Yes, I meant SignaLincs. You also mentioned restoring the KPL. What caused you to restore the KPL and what were the changes as a result? I thought maybe this would help with the issues. Is there a folder condition that might prevent the program from running (and recognizing a status change)? The only folder condition is the time of day and the status of the folder condition is True. 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). 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? 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? 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. Thanks! Link to comment
IndyMike Posted April 10, 2008 Share Posted April 10, 2008 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 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). 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. 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? 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 Link to comment
IndyMike Posted April 10, 2008 Share Posted April 10, 2008 Chuck, Had another thought in regard to the following. Is there a folder condition that might prevent the program from running (and recognizing a status change)? 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 Link to comment
IndyMike Posted April 12, 2008 Share Posted April 12, 2008 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 I tried the SignaLincs - one on the same circuit as the KPL and placed near the circuit panel and one on an opposite leg, also near the circuit panel. This seamed to have caused more problems. Sometimes the All Off command would not even turn off the same KPL's LEDs even though they are in the same "All Off Scene" as the rest of the devices. I removed the FilterLincs and things improved. I restored the KPL in question. This is my current program configuration: If Time is from XX to XX AND 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') If Time is from XX to XX And Program 'All Off Status (Daytime)' is True And Status 'Living Room - ALL OFF' is not On Then Wait 2 seconds Set Scene 'ALL OFF LED' On Else - No Actions - (To add one, press 'Action') If Time is from XX to XX And Program 'All Off Status (Daytime)' is False And Status 'Living Room - ALL OFF' is not Off Then Wait 2 seconds Set Scene 'ALL OFF LED' Off Else - No Actions - (To add one, press 'Action') Link to comment
Chuck Posted April 12, 2008 Author Share Posted April 12, 2008 Thanks for your input and work Mike. The conditional folders were for Sunset to Sunrise (next day) and another for Sunrise to Sunset (same day). This appeared to work most of the time. I did remove the programs from these folders and things seem to be working better. Backing up...I think the source of most of my problems was a 2nd PLM and ISY-26 I've been configuring in my garage (for a customer). Although I had issues before (Hopefully because of this conditional folder bug), they became much worse after I started this second ISY project. I unplugged the 2nd PLM and ISY and the LED status programs run without a problem (so far). Which brings me to my next question: I am planning on configuring the ISY-26 to work in conjunction with mControl. This means I'll need a PLC plugged into the same outlet as the PLM. Is this going to cause similar communication problems? Thanks, Chuck Link to comment
IndyMike Posted April 12, 2008 Share Posted April 12, 2008 Hi Chuck, Happy to hear that things appear to be working better. Backing up...I think the source of most of my problems was a 2nd PLM and ISY-26 I've been configuring in my garage (for a customer). Although I had issues before (Hopefully because of this conditional folder bug), they became much worse after I started this second ISY project. I unplugged the 2nd PLM and ISY and the LED status programs run without a problem (so far). 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. Which brings me to my next question: I am planning on configuring the ISY-26 to work in conjunction with mControl. This means I'll need a PLC plugged into the same outlet as the PLM. Is this going to cause similar communication problems? 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 Link to comment
Chuck Posted April 12, 2008 Author Share Posted April 12, 2008 I did observe when I pressed All On or All Off from the Admin Console for the system in the garage it turned on and off a nearby 2476D, which was never linked to this PLM. I tried adding then removing the 2476D, but it still is controlled by these All On and All Off buttons. Is this normal? The PLM was new and I restored it before adding any devices (to "clean" it). The ISY-26 was previously used with this 2476D and other devices, but I did a Factory Reset before starting. Is it possible that you exceeded the bandwidth of the network with heavy traffic from the garage? There shouldn't be any traffic from the garage - nobody's in there. Any programs and scenes are only for those devices connected to the test strip in the garage. If your repeaters (any Insteon device) are distant this could create a problem (or at least use a Insteon HOP). What is an Insteon HOP? Thanks, Chuck Link to comment
IndyMike Posted April 13, 2008 Share Posted April 13, 2008 I did observe when I pressed All On or All Off from the Admin Console for the system in the garage it turned on and off a nearby 2476D, which was never linked to this PLM. I tried adding then removing the 2476D, but it still is controlled by these All On and All Off buttons. Is this normal?The PLM was new and I restored it before adding any devices (to "clean" it). The ISY-26 was previously used with this 2476D and other devices, but I did a Factory Reset before starting. 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. What is an Insteon HOP? 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 Link to comment
Recommended Posts
Archived
This topic is now archived and is closed to further replies.