Jump to content

apostolakisl

Members
  • Posts

    6943
  • Joined

  • Last visited

Everything posted by apostolakisl

  1. The error log has no errors since August 3. There was a stretch on Aug 3 lasting several hours where there were a ton of errors including lots of ntp errors. Probably my internet was down or something. I opened the console this morning. The clock on the console seems to be the problem. I opened it at 6:51:50. Over the course of the next 6 minutes, the clock only ticked forward by 11 seconds to 6:52:01. Mostly it is just sitting there doing nothing, but every once in a while it ticks forward a tick or two. For example, in the time it took to write the last couple sentences, the clock still says 6:52:02. Otherwise the console is working like normal. EDIT: It is now 7:36 and the console clock says 7:01:48. It is ticking now roughly 1/sec. Since it appears to be the console clock only, it isn't that big of a deal. But during program debugging it is pretty inconvenient to not know what time the system clock thinks it is. EIDT:Now at 7:56, the ISY clock is showing 7:54. So somewhere in there it must have updated to the system clock, but still has fallen behind again. EDIT: The console clock has stopped ticking again. But if I open the "configuration" tab it syncs to the ISY. But it still doesn't tick. If I go to a different tab, then back to the configuration tab, it updates again, but again still doesn't keep ticking. EDIT: I opened the java console on my office computer and logged in. It is displaying the same behavior.
  2. The error log has no errors since August 3. There was a stretch on Aug 3 lasting several hours where there were a ton of errors including lots of ntp errors. Probably my internet was down or something.
  3. I don't recall how long the console was open. Perhaps a day, perhaps a few minutes. I just did a test. I opened the console a couple hours ago and hit the NTP update. The clock was off, but I didn't notice by how much. I closed the console and then just reopened it (about 2 hours later) hit the sync button again. The clock corrected by about 15 seconds. So either ISY clock is running quite a bit off or the NTP server isn't giving good numbers. I'll try again in another hour and see what it does.
  4. I am pretty sure the 315mhz does not use rolling codes. I did buy two of the ones with rolling codes off amazon for a total of $46. So you only save about $10 going with the non-rolling model. Also, don't forget, that you will need to be able to train your car. The only way to do that is to have an RF transmitter that works on the 315mhz system.
  5. I believe that is the same thing that caused my programs to misfire. But another possible issue. I just noticed that the clock was off by over 10 minutes. I have it set to sync with ntp every 24 hours. I clicked the "synchronize now" button and it successfully updated and corrected the time. But that begs the question. .. how was it 10 minutes off if it is syncing every 24 hours. It should have at least one sync since I updated the firmware.
  6. 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.
  7. 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.
  8. 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
  9. 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')
  10. Upgrade went smoothly.
  11. 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?
  12. 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.
  13. 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.
  14. 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.
  15. 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.
  16. Perhaps your PLM is getting flaky.
  17. 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.
  18. 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.
  19. 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
  20. 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.
  21. 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.
  22. 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.
  23. Update went smoothly. The Elk outputs and zones were all populated with correct status after upgrade. I haven't tried a hard reboot yet.
  24. 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.
  25. 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".
×
×
  • Create New...