apostolakisl

Hi Lou, This is key because a loss of connection definitely explains the blinking problem, so I'm wondering if your Elk connection has been dropping off more often with the new build. In looking at the code, we weren't always do a query after reconnect, so we'll fix that. Is it possible for you to recreate the problem without the connection dropping? I just downgraded to 3.2.6 and it is doing it with that as well. So, now I don't know where this is coming from. It is also losing its connection with 3.2.6. I don't know if I have an xep that is going bad or some other network hickup.

When I am at my office, I can log onto ISY since I have my home and office networks linked via vpn routers. The connection at my office will frequently go offline when connected. The green ready flag at the bottom goes red, I get an exclamation point next to my lighting, and most of the menu bar items grey out. However, I can still load my programs and I can still arm my Elk using ISY. It doesn't update the Elk status bar, but the system does arm. If I close and re-open the console, the Elk shows armed (of course it blinks yellow saying the exit timer is running even though it finished, but we are dealing with that elsewhere). What gives? How can the connection be lost, but yet it still arms the elk and I can still open programs? I can also turn outputs on/off and query the outputs even when it supposedly isn't connected. It also does this from my computers at home, just not nearly so frequently.

Hi apostolakisl, Well this one has me stumped, I cannot recreate it at all. Can you please recreate it with the event viewer on max and post the results. I'm wondering if something unrelated is causing this problem somehow. Chris, I turned the system on using the ISY console. It armed and the exit timer ran to completion. But it still kept blinking. I did get a brief loss of connection to the Elk from ISY which hadn't been happening in the past. But it restored and continued to blink yellow. I walked over to the keypad and hit the f4 key and it corrected the yellow blinking light to armed fully with solid light. You can see where that happened at 7:17:00 when it switched from exit timer to fully armed simultaneous to the f4 action. I did do a reboot on the xep this morning prior to all of this. The "kitchen motion" is me getting up from my computer in the kitchen and walking over to hit the f4 key. I turned the f4 key on, then turned it off. Lou EDIT: Also, I just tried using the ISY java console to do a "press" of f4, and it also corrects the blinking yellow light.

Perhaps your PLM is getting flaky.

Ok, while it is flashing yellow, restart the admin console and see if it still flashes yellow. If its still flashing yellow then ISY thinks its still in exit timer mode (indicating a comm problem between ISY and Elk), if its not then its a problem with events being sent to the admin console. Yes, it blinks yellow no matter when I open the console or how many times I close it and reopen it. Even when I wiped the Java cache and re-open it still blinks yellow. Running the program to let the dog out fixes it. That program turns some outputs on/off. ISY also responds to the F key press by turning some lights on/off. It also bypasses/unbypasses the one zone. Something in there "wakes up" ISY to the armed status of the system. ISY and Elk clearly are communicating since many other things are working, it is just the exit delay being completed that isn't communicating. Also, that light updates correctly when disarmed. "ready to arm with zone violated", "ready to arm", "not ready to arm". It's only when armed that it fails to recognize the end of the delay.

Something is just odd here, I have been blasting my ISY with activity while arming night mode and haven't been able to reproduce this even once. If you restart the Admin Console, is it still blinking yellow? Did you make any changes to your Elk setup? It happened with my computer at the office logged in remotely as well as my home computer. I just wiped my Java cache and reloaded the ISY Java applet, armed the system to "stay" mode. It flashed yellow right through the delay and then kept on flashing even after the exit delay was over. It is flashing right now about 5 minutes after the exit delay finished. And no, I haven't changed anything in my Elk for a long time, like months. I can't say 100% that it wasn't doing this prior to 3.3.1, but I am pretty sure I would have noticed it. EDIT: Still Flashing Edit: OK, now it stopped blinking and says "armed fully". I am not sure what did it except I did just use an f key to temporarily bypass a zone to let the dog out. Edit: The above is reproducible. It keeps blinking yellow, but if I use the f-key it corrects it. Not sure what other actions may correct but this one does.

I do not think it should still be blinking. The blinking means the timer is going, for example, you may have a 30 second exit timer that gives you 30 seconds to leave the area before the alarm is fully armed. I have been unable to reproduce this problem, is there a lot of activity (Insteon, Elk, etc.) around the time these were armed? When I arm to night mode I do so by pushing a kpl button in the bedroom. I also pushed another kpl button a few seconds before that sets a scene off containing most of the lights in the house. The arm away is done via a keyfob that also triggers a scene that shuts all the lights off. It appears to be doing this every time we arm the system. And here is a log of events surrounding the faulty execution of the "if status off and control switched off" 16.ie.26 is the light. Wed 09/12/2012 05:29:19 PM : [iNST-SRX ] 02 50 16.1E.26 00.00.01 C7 11 00 LTONRR (00) Wed 09/12/2012 05:29:19 PM : [standard-Group][16.1E.26-->Group=1] Max Hops=3, Hops Left=1 Wed 09/12/2012 05:29:19 PM : [ 16 1E 26 1] DON 0 Wed 09/12/2012 05:29:19 PM : [ 16 1E 26 1] ST 255 Wed 09/12/2012 05:29:19 PM : [iNST-SRX ] 02 50 16.1E.26 19.75.34 41 11 01 LTONRR (01) Wed 09/12/2012 05:29:19 PM : [standard-Cleanup][16.1E.26-->ISY/PLM Group=1] Max Hops=1, Hops Left=0 Wed 09/12/2012 05:29:19 PM : [iNST-DUP ] Previous message ignored. Wed 09/12/2012 05:29:19 PM : [iNST-SRX ] 02 50 16.1E.26 00.00.01 CB 13 00 LTOFFRR(00) Wed 09/12/2012 05:29:19 PM : [standard-Group][16.1E.26-->Group=1] Max Hops=3, Hops Left=2 Wed 09/12/2012 05:29:19 PM : [ 16 1E 26 1] DOF 0 Wed 09/12/2012 05:29:19 PM : [ 16 1E 26 1] ST 0 Wed 09/12/2012 05:29:19 PM : [iNST-SRX ] 02 50 16.1E.26 19.75.34 41 13 01 LTOFFRR(01) Wed 09/12/2012 05:29:19 PM : [standard-Cleanup][16.1E.26-->ISY/PLM Group=1] Max Hops=1, Hops Left=0 Wed 09/12/2012 05:29:19 PM : [iNST-DUP ] Previous message ignored. Wed 09/12/2012 05:29:19 PM : [iNST-SRX ] 02 50 16.1E.26 19.75.34 4B 13 01 LTOFFRR(01) Wed 09/12/2012 05:29:19 PM : [standard-Cleanup][16.1E.26-->ISY/PLM Group=1] Max Hops=3, Hops Left=2 Wed 09/12/2012 05:29:19 PM : [ 16 1E 26 1] DOF 0 Wed 09/12/2012 05:29:20 PM : [iNST-TX-I1 ] 02 62 16 1E 26 0F 11 3F Wed 09/12/2012 05:29:20 PM : [iNST-ACK ] 02 62 16.1E.26 0F 11 3F 06 LTONRR (3F) Wed 09/12/2012 05:29:20 PM : [iNST-ACK ] 02 62 16.1E.26 0F 11 3F 06 LTONRR (3F): Duplicate or ACK for a different device Wed 09/12/2012 05:29:20 PM : [iNST-SRX ] 02 50 16.1E.26 19.75.34 2B 11 3F LTONRR (3F) Wed 09/12/2012 05:29:20 PM : [standard-Direct Ack][16.1E.26-->ISY/PLM Group=0] Max Hops=3, Hops Left=2 Wed 09/12/2012 05:29:20 PM : [ 16 1E 26 1] ST 63 Wed 09/12/2012 05:29:21 PM : [iNST-SRX ] 02 50 16.1E.26 00.00.01 CB 13 00 LTOFFRR(00) Wed 09/12/2012 05:29:21 PM : [standard-Group][16.1E.26-->Group=1] Max Hops=3, Hops Left=2 Wed 09/12/2012 05:29:21 PM : [ 16 1E 26 1] DOF 0 Wed 09/12/2012 05:29:21 PM : [ 16 1E 26 1] ST 0 Wed 09/12/2012 05:29:21 PM : [iNST-SRX ] 02 50 16.1E.26 19.75.34 41 13 01 LTOFFRR(01) Wed 09/12/2012 05:29:21 PM : [standard-Cleanup][16.1E.26-->ISY/PLM Group=1] Max Hops=1, Hops Left=0

Did this happen at ISY startup, or did it just randomly happen sometime after that? If you disable Elk then enable it again, does the status show up correctly? First off, I'm not exactly sure what yellow blinking means, so maybe it was supposed to be yellow blinking. The system has been armed/disarmed several times since the firmware upgrade. At this very moment it is blinking yellow. The info bar is as follows. . .red light "armed away" blinking yellow "armed with exit timer". The system has been armed away now for several hours.

Yes, confirmed. The ISY console read "on", I switched light off, it turned off, then the program ran and it came back up to 25%. No missed comms. It took 4 tries to get it to happen. I haven't had it happen a single time since you fixed it ages ago but since upgrading the firmware yesterday morning it has happened many times. If Status 'Master Bedroom / Master-Closet L' is Off And Control 'Master Bedroom / Master-Closet L' is switched Off Then Set 'Master Bedroom / Master-Closet L' 25% Else - No Actions - (To add one, press 'Action') Also I noticed the Elk "Armed with exit timer" is blinking yellow with the system armed in night mode even though it has been armed for 5 hours at this point. I do not recall it doing that before and am not sure it is supposed to be doing it.

Bug found. The old problem of the "if off and control switched off" thing is back. When I turn my lights off from an on position it triggers the "if off and control switched off" programs even though it was not off to start with.

Update went smoothly. The Elk outputs and zones were all populated with correct status after upgrade. I haven't tried a hard reboot yet.

If one light shut off, then the program ran and program settings should not be considered the problem (I base this on the fact that you say you put all the lights in one scene and that you have tested that scene as working). This really can only be a comm issue. You tested it during the day, then you went to use it at night. At night, you likely have a different set of lights and devices on in your house which may be creating noise. Try running the "scene test" on ISY for that scene and see what it says. Try figuring out everything that might have been on in the house when it failed and recreate that environment. Also, things like refrigerators and other automatically cycling appliances can be noise makers and it won't always be obvious when they are on/off. . . just to confuse things.

I tested putting the off program inside of a folder that goes false with the same trigger and it always worked on my system. It is true that putting it inside the folder serves no purpose aside from organization. But there is no need to guess. If the lights fail to shut off, check the program summary page. It will tell you the last time it executed and whether it went true or false. If the program executed and the lights didn't turn off, then you have a comm problem. I would be very curious to see if indeed this is a "race" issue as suggested by LeeG or a failure to communicate. Based on my experience and my general knowledge of ISY's event driven setup, my impression is that it should always run. And as to whether you use "control" or "status" for that program. .. it doesn't really make any difference. Because kpl buttons only have 2 states (on/off) the only difference would be that the program would run false when you turn the button "on" using "status" as well as running true when you turn it "off". Using "control" the program only runs when you turn the button "off".

The difference is basically triggering. The "if" section of the program typically is used as a place to put conditions (I say typically because there are reasons to have it blank). These conditions will be tested when the program's "if" section is evaluated. The question is, what causes an evaluation to occur? What is the "trigger". Clauses placed within the "if" section may or may not be triggers. For example, an integer variable is never a trigger. It does evaluate when the program is triggered, but it doesn't cause the trigger. Status and Control are both triggers, but for different reasons. Status: triggers when the referenced device CHANGES status. So if a light is "on" and you push "on", nothing happens. If the light is "off" and it is turned to anything else (like on), by any means (a scene/program/direct action on the switch), it is a trigger. Control: triggers when the referenced device IS DIRECTLY ACTED UPON (YOU PHYSICALLY PUSHED THE BUTTON ON THE SWITCH) and YOU DID WHAT IS LISTED. In other words, "control switched fast on" is a trigger only when someone walks up to that switch and double clicks the on. Otherwise it is not a trigger. Both status and control will be evaluated whenever the program is triggered by any means. "Control is switched whatever you choose" will only evaluate to true if whatever you choosewas the trigger. Any other trigger will always force a program to be false. "Control is not switched whatever you choose" will always evaluate to true except when whatever you choose is the trigger. For example, "control is not switched on" will trigger the program to run when the light is switched "on" but will run the else clause. Switching the light "on" is still the trigger, the is/is not just determines the true/false execution. It is a bit confusing. But you need to keep 2 separate concepts in your head. Triggering . . .what causes the program to run, and Evaluating. . . whether it runs true or false after it is triggered.

I have the weatherbug temp coming through to the keypads fine. It's the internal temp via Elk and RCS thermostat that is returning blank via the variable In:${elk.tstat.1.ST} Out:${mod.weather.temp.current} And yep, I'm constantly saving before testing my programs. Steve I don't have the Elk thermometer or any type of thermostat connected, but I was able to successfully text and email the keypad temp. Not sure if this info is of any use to you.

I have several notifications that are very similar to yours that are working. For example I am sending the outside temp (weatherbug) to Elk keypads for display. I don't want to insult you by suggesting something so obvious, but you did hit the "save" key in your setup... right?

Hmmm. Something sounds wrong. Hopefully someone is following this thread who knows more about that device.

I would rather let someone else who owns remotelincs comment more definitely on this. I don't have any and they are a bit of a different beast being battery operated and 100% wireless. I assume that they link like the other devices and if so a factory reset/restore would be in order. But the fact that it is timing out makes me wonder exactly what is going on. I know that Insteon battery devices have to be put into linking mode prior to certain actions. . . this may be one of them.

I am pleased to hear that things are working. However, you should still check your link records. You might have differences between ISY and your actual devices since it sounds as though you made changes to your devices and then did an ISY restore to prior to the changes. Under Tools/diagnostics/show device links table. After it pulls all the records from the device, hit the compare to ISY button and see if it all checks out. If not, you need to fix it.

I don't know really what's going on here. It's kind of hard to tell without being there. You may have some bad links. The fact that you restored an ISY backup after having made changes to links on your devices is a definite no-no. Your link records on your devices will not match what ISY thinks is there. Restoring an ISY backup does not change the links on the devices. You can always factory reset your devices and then use ISY to restore the devices. This will ensure that ISY links tables and your devices are the same. You could also use ISY to check the link records and compare to its expected links and only restore devices that are wrong. I don't know how many devices you have. If you only have a few, it might just be easiest to factory reset all of them and then have ISY restore each device.

What type of bulbs do you have? Sounds like noisy load issue (cfl bulbs?)

Replace with is exactly what you need. Remove the old switch, install the new one. Add it to ISY (no need to name it), then use the "replace with" function. Done. Everything transfers over to the new switch including it's name, all programs it might be listed in, and all scenes that it is a part of. Oh, and one important point. Both the new switch and old switch need to be in the root folder. In other words, under "my lighting" in the tree. . . not in a subfolder.

You shouldn't delete the 4 stop program commands. Those don't produce any insteon traffic and will still be necessary.

There is a section of the wiki with a bunch of sample programs as well as explanations.

There is a good chance it is a comm failure. As I mentioned earlier, when you have a program send a bunch of individual light commands all at once there gets to be a bunch of traffic and failures are more likely. I suggest creating a scene and entering those 4 lights into it, all as responders only. Then set your program to set the scene off. A scene "off" command is a single piece of Insteon traffic regardless of how many lights are in it.