apostolakisl

This firmware appears to be bug free in my applications. The issue with improper "true" execution of the "if status off and control off" programs has not happened since the upgrade. The Elk module is working well and is populating the values at start up. Thanks.

Correct me if I'm wrong, but that x10 rf device is not rolling code. Assuming I am right, I would avoid using that to control your alarm system. I found this on amazon. http://www.amazon.com/635LM-Craftsman-L ... B000F5IL7Y It is rolling code and only $25 with shipping. It will connect to the IO link you already have so $25 should be your only cost. I think I might get one myself.

Your car almost certainly has a homelink system. You need a homelink receiver. They make kits designed to convert non-homelink garage doors into homelink garage doors. This same kit could instead be used with an IO link. These kits start at about $70. Maybe you can find one cheaper. If you can figure out how to tear apart an old homelink compatible garage door opener and use the receiver, then go for it. But the time involved may not justify the $70 savings. EDIT: I just googled it and found a "lear car2u" device that seems to be what you want for about $25. I didn't really scour the instructions but at first glance it appears to accept the rolling codes from homelink to close a momentary contact (which you could connect to an iolink) EDIT: Also this one looks like it should work http://www.northshorecommercialdoor.com ... nplre.html

I don't know how to directly turn a device off with a REST command. But you can quite easily program the ISY to respond to the change in the variable (executed by REST) by programmatically creating an "off" command. If $sTest is "x" Then Set Scene 'Test Light' Off Else - No Actions - (To add one, press 'Action')

Upgrade went smoothly.

So you are saying that the Java console is expecting something from the ISY and not getting it. Thus it shows the red flag and greys out. But the Java console is still sending commands that are reaching their destination. So, assuming I understand correctly, what would block it the comm in just the one direction? And why would it not block all the time?

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? WOOOOHOOOO I FIGURED IT OUT. OK, so here is the deal. I switched to U-verse last week. U-verse appears to either be blocking port 25 or the old dns server address I had it set to may not have worked since it was a road runner server and I was no longer on road runner. Either way, the would hang when it tried to send an email. Since I have it set to send me an email every time the system arms, it was hanging every time I armed it. Eventually it recovers, but not until after the exit timer finished. . .and thus the exit timer completion message never gets through. Sorry to trouble you. But, hopefully you will find this sort of info helpful. Frankly, I find the xep to be a pretty temperamental item. I have never had something crash so often when the settings don't work. It took me close to 2 hours to get it working since I had to reboot the thing like 20 times at like 2 or 3 minutes per boot. ERRRRRR. If you hit "test" on it, and it doesn't like the settings, it just crashes and reboots.

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.