FRR
Members-
Posts
44 -
Joined
-
Last visited
Profile Information
-
Location
Chicago area
-
Occupation
Engineering Director
FRR's Achievements
Newbie (1/6)
0
Reputation
-
Wayne, Michel, I have a similar issue and I wonder if the issues are related. When I create a new program to evaluate the ELK connection status, the new program always evaluates as false by "run if" even though the ELK connection status is indeed true. If I force the connection status to be false by changing the access code to an incorrect code or by disconnecting the ELK then set the access code back or reconnect the ELK, the program gets triggered and evaluates to true. The program then seems to run correctly, HOWEVER if I disable it, it STILL runs when the "if" condition become true. Frank
-
None of the ELK events are showing up in my ISY history log (not the error log). Don't know if there is a problem with my set up or this is not implemented yet. If it's not, would it be possible to write system changes, zone and output changes, etc to the ISY log? I would very much like to be able to access a history of these events. Especially zone and output changes. Next priority would be Arm status changes including the user ID. FYI: All ELK G29-42 Serial Port 0 Transmit Options are checked except for "Event log". Should this be checked as well? Thanks, Frank
-
Thanks IndyMike. I verified that User Code 1 is able to Arm/Disarm using the ELK Web Console. I set the ELK access code in the ISY config to User Code 1. Still CAN'T Arm/Disarm from the ISY Admin Console. I can control outputs. I moved my arm issue to this post http://forum.universal-devices.com/viewtopic.php?f=17&t=7454 since it seems that it's an issue with my system and not an issue with 3.1.13 I'll leave And are items #2 & #3 here because they are related to 3.1.13 issues and hopefully being worked on. UDI has not acknowledge this yet. Thanks, Frank
-
Could I get some help on my Arming issue (#1 & #4) And are items #2 & #3 know issues that may be worked on? Thanks Frank
-
Michel, Thanks for your reply. Sorry for the confusion. Which Access Code should be used in the ISY/ELK Conf Tab? The RP Access Code, a valid Users Access Code, the M1XEP User Web Access Code, The Installer/Programmers Access Code? There still seems to be an issue when the "If Elk System is Connected" is evaluated. It is not evaluated correctly when a new program is created until the Access Code is changed. Also, the "If Elk System is Connected" program runs when the Access Code is changed even if the program is marked as Disabled! If I connect with ELKRP while ISY is connected, the ISY ELK Connected Status is unaffected even though some functions are now not possible through ISY. I think we need a status that would indicate that ISY has full access to the ELK so we can be assured that communications will happen as expected. Can this be done? Regards, Frank EDIT I changed my ElkRP Access Code from 5 to 6 places and reconnected and still can't arm and the above behavior continues. Here's the log: Also what do the lines in RED mean? Why are these 3 zones showing up here when none of the others are? Sun 11/27/2011 11:54:21 PM : connect(ELK notSSL xxx.xxx.xxx.xxx 645A08F0 2101 200) Sun 11/27/2011 11:54:33 PM : [ELK 0 0 0] (157/1/0) Sun 11/27/2011 11:54:33 PM : [ELK 0 0 0] (156/1/0) Sun 11/27/2011 11:54:33 PM : [ELK 0 50 0] Zone : Garage Dr #1 Up : (53/134/0) Sun 11/27/2011 11:54:33 PM : [ELK 0 55 0] Zone : Driveway #1 : (53/135/0) Sun 11/27/2011 11:54:33 PM : [iNST-ACK ] 02 62 04.8E.CD 0F 11 FF 06 LTONRR (FF) Sun 11/27/2011 11:54:33 PM : [ELK 0 86 0] Zone : Analog Dr Test : (53/82/0) Sun 11/27/2011 11:54:33 PM : [iNST-SRX ] 02 50 04.8E.CD 0F.9E.D4 27 11 FF LTONRR (FF) Sun 11/27/2011 11:55:20 PM : [ELK 0 0 1] Keypad : Main Panel : Access Code Valid (101/1/0) Sun 11/27/2011 11:55:28 PM : [ELK 0 0 1] Keypad : Main Panel : Access Code Valid (101/1/0) Sun 11/27/2011 11:55:37 PM : [ELK 0 0 1] Keypad : Main Panel : Access Code Valid (101/1/0) Sun 11/27/2011 11:55:45 PM : [ELK-ERR ] Arm Stay : Area 1 Sun 11/27/2011 11:56:27 PM : [ELK 0 2 0] (113/130/0)
-
Michel, I have some additional info on the Elk connection status issue. If there is a current connection and I create a new program that checks the connections status and force a Run If, it always evaluates to false. Then, if I enter any 4 digit CORRECT or INCORRECT User Access Code in the Elk configuration, save it, the connection status in now true and the arm/disarm panel remains as displayed. If I then enter the ElkRP Access Code (5 digits in my case), the connect status is now false and the arm/disarm panel NOT displayed. If I now enter any 4 digit INCORRECT Access Code in the Elk configuration, save it, the connection status in now TRUE and the arm/disarm panel IS displayed. If I now enter any 5 digit INCORRECT Access Code in the Elk configuration, save it, the connection status in now FALSE and the arm/disarm panel is NOT displayed. If I now enter any 6 digit INCORRECT Access Code in the Elk configuration, save it, the connection status in now TRUE and the arm/disarm panel IS displayed. If I now enter any 5 digit INCORRECT Access Code in the Elk configuration, save it, the connection status in now FALSE and the arm/disarm panel is NOT displayed. If I now enter any 6 digit INCORRECT Access Code in the Elk configuration, save it, the connection status in now TRUE and the arm/disarm panel IS displayed. If I now enter any 7 digit INCORRECT Access Code in the Elk configuration, save it, the connection status in now FALSE and the arm/disarm panel is NOT displayed. Seems that any even number of digits entered in the Access Code >= 4 results in the Arm/Disarm panel being displayed and the Connection Status being evaluated to TRUE as long as the program was created before the Access Code was entered.(Similar results for Enabled Status. Both seem to only be evluated when the Access Code is changed.) The "If Elk System is Connected" runs when the Access Code is changed even if the program is marked as Disabled! Also, I can't seem to Arm the ELK regardless if the Access Code that I enter. I hope this helps. Regards Frank If Elk System is Connected Then Set '2nd Floor / Master BedRm_Floor Lamp Lt' On Else Set '2nd Floor / Master BedRm_Floor Lamp Lt' Off .
-
Michel Thanks for the reply. The Connected status always evaluates to FALSE even though I have a connection and can control ELK outputs and see zone changes in real time in the ISY app. Keeping the ISY/ELK connection up is now imperative since I'm relying on ISY for security events etc. I would like to know when there is a connection issue and also would like to know how to have ISY re-establish the connection. It would also be nice to periodically ping the ELK to verify that it is reachable. This could be set up in the configuration tab including ping enable, ping frequency, retires before error, etc. There could be a status and an event to indicate the ping results which would be used in ISY programs. Here's the program I used to test the functionality and it is always evaluates to false which I believe is incorrect. If Elk System is Connected Then Set '2nd Floor / Master BedRm_Floor Lamp Lt' On Else Set '2nd Floor / Master BedRm_Floor Lamp Lt' Off Regards, Frank
-
I need to know that ISY is connected and communicating to ELK at all times. I tried writing a test program to check the connection state "IF Elk System is Connected" or "IF Elk System is Enabled" and they are always false. I do have an active connection because I can change a output and also see a zone status change in real time in the ISY admin app. Seems that System is Connected or Enabled are not functional. What am I missing? Also what the difference between Connected & Enabled? If ELK-RP steals the connection, will ISY reconnect automatically when ELK-RP releases the connection? Thanks Frank (3.1.13 Installed) Here's the simple program I used to test the functionality: If Elk System is Connected Then Set '2nd Floor / Master BedRm_Floor Lamp Lt' On Else Set '2nd Floor / Master BedRm_Floor Lamp Lt' Off
-
Mike, et al, Elk was at the latest versions except for the XEP Firmware was at :1.3.26 so I upadted that now. Still no security tab. My free memory (see below) seems a lot lower that what I've seen in a previous users post. Don't know if that could be an issue. Suggestions? Thanks Frank Current ISY Config: Firmware:3.1.12 UI:3.1.12 Current ELK Config: M1G Firmware: 5.2.8 Bootware: 3.3.6 Hardware: 0.10 XEP Firmware:1.3.28 Bootware: 1.2.0 Hardware: 1.0
-
LeeG Thanks for the reply. Both the the firmware and UI levels indicate 3.1.12. I can't seem to be able to install the Elk module after the upgrade. Probably because I inadvertently installed it before the upgrade by clicking through the start up messages too fast. Now, if I select manage modules, I get a message that all modules are up to date but still no security tab. I power cycled the ISY - no change. Suggestions?
-
The Security tab does not show up after upgrading to 3.1.12. I purchased the ELK module however when starting the admin console to backup my 3.1.9 system before upgrading to 3.1.12, I may have mis-stepped. As always, I get several messages about Insteon modules that the ISY can not communicate with and I always just click OK. (some of them are motion sensors some are modules which are not connected at the moment) I may have clicked OK to another message without reading as I should have. After the upgrade, I cleared the cache and launched the admin console ( http://isy/admin, http://isy/admin.jnlp or http://www.universal-devices.com/99i/3.1.12/admin.jnlp ) and now I do get a message "Subscriber did not rply to event:1 [33]" OR "Request Failed". If I select manage modules, I get a message that all modules are up to date but still no security tab. Suggestions? Thank Frank.
-
Eric, Thanks for your reply! The ISY is new to me but at this point, unless it was explicitly instructed to stop, I would want a program that was in the process of running the THEN or ELSE code to continue to run to the end regardless how the IF would be re-evaluated. Otherwise its unpredictable, only some of the statements may have been executed, things could be left in a weird state and clean up code not run. With this said, it should not be whats causing my light not to urn off. The 'ISYPrg_Sunset Inside Lts Prg' is a program that runs at sunset and stays TRUE until sunrise. If From Sunset - 35 minutes To Sunrise + 30 minutes (next day) Then Set Scene 'Scene_Inside Lts Sunset' On Else Set Scene 'Scene_Inside Lts Sunset' Off So after sunset and before sunrise, the IF in the program in my previous post should only be re-evaluated each time the the '2nd Floor_MS Hall Sen' is switched ON (from Off to On). I this case (nighttime), it should always be TRUE and only run the THEN code. This would effectively restart the wait time if the program had already been "running" or turn the light on and start waiting if it was not running. Both are acceptable behaviors and is what happens most all of the time. However, occasionally the light never gets turned off and when I look the Program Summary the start and end times are the same. This makes it appear that the program was re-triggered and the IF evaluated as False therefore stopping the then code in it's tracks. At night the program should only be triggered to run when the motion sensor goes from OFF to ON and only run the Then code. I can't figure how the program would be re-triggered at night and not just run the Then code. There may be either a problem with my logic or the .13 ISY because I did not see this issue with .8. Any help is appreciated. Frank
-
In addition to the communication problems I'm having with .13, I have some program execution problems as well. My program below works most of the time how ever occasionally it does not turn the light off. The program summary also shows that the program finished in the same second that it started. Thats not possible if it really executes the Wait and Off statements. It does execute the Set 35% because the lights turns on to 35% however it never turns off. If Control '2nd Floor_MS Hall Sen' is switched On And Program 'ISYPrg_Sunset Inside Lts Prg' is True Then Set '2nd Floor_Hall Cans' 35% Wait 5 minute Set '2nd Floor_Hall Cans' Off Else - No Actions - (To add one, press 'Action') Here's the Program Summary: ISYPrg_Hall Motion Sensor ISYPrg_Hall Motion Sensor On - Idle False isyPrgGrp_Inside Light Scenes Fri Jan 08 22:36:45 CST 2009 Fri Jan 08 22:36:45 CST 2009 I have also noticed that if a program is "Running" and the RunIF is triggered again, the "Running" program stops in its tracks and basically a new instance of the program executes. I'm not sure if this behavior is intentional, but causing the "executing" code to stop in it's tracks due to a re-trigger is not desired IMO. Using the program above as an example; If it is "Running" and at the Wait 5 minute statement then re-triggered with RunIF, the program stops, instantly restarts from the top then one of 2 things happen. If the IF evaluates to False when re-triggered, the light never turns off. If the IF evaluates to True when re-triggered, the 5 min wait starts from the moment of the re-trigger. Any insight is appreciated. Regards Frank
-
I have noticed this too. All the same insteon hardware (> 1 yr old), no configuration changes and no new devices in the house. I just thought I'd wait for .14 to see if things improved.
-
Wayne, Run (If) Runs the code from the top of the program. The Then code will only be executed if the IF conditions are True. The Else code will be executed if the IF conditions are False. Run Then Runs the Then code regardless of the state of the IF conditions. Run Else Runs the Else code regardless of the state of the IF conditions. Hope this helps. Frank