Release 3.1.13 (Beta) Is Now Available

[LeeG]

It would be something like the DSCLink that is going through the REST interface. I assume the phone apps would do the same thing. Things running inside the ISY itself do not need to go through the REST interface to access ISY variables. The piece that I still cannot find is what turns those `170001 messages On and Off. Still looking.

[Michel Kohanim]

Hi Guys,

 

Lee is correct: if you run the Event Viewer on Device Communications level, you will see those informational messages in the log. They should go away if a) you change the level you close Event Viewer or c) you close the Admin Console.

 

With kind regards,

Michel

[elvisimprsntr]

Not sure if I am doing something wrong, but the security REST interface seem to be returning 404 errors.

 

Excerpt from my bash script. Same syntax works for other REST commands.

wget -O security.log --user $USER --password $PASS ${ISYRESTURL}${ISYCMD}

 

Output from command.

--2011-11-30 07:15:45-- http://192.168.69.90/rest/security

Connecting to 192.168.69.90:80... connected.

HTTP request sent, awaiting response... 401 OK

Reusing existing connection to 192.168.69.90:80.

HTTP request sent, awaiting response... 404 OK

2011-11-30 07:15:45 ERROR 404: OK.

 

The above command is listed in the WSDK http://www.universal-devices.com/develo ... Manual.pdf

[FRR]

Michel, Thanks for your reply.

 

Sorry for the confusion.

 

1) 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?

 

2) 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!

 

3) 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

4) I changed my ElkRP Access Code from 5 to 6 places and reconnected and still can't arm and the above behavior continues.

 

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

[IndyMike]

Hello Frank,

 

The proper Access Code is the "User Code(s)" as defined on page 14, section 2.3 of the Elk manual. If you use another code (ELKRP or Installer) or an incorrect code the ISY will still be able to "Monitor events" but will not be able to arm/disarm the system.

 

User Code 1 (normally the Master) should always work. Other User codes (that you have defined), may not have privileges to arm/disarm the system depending on how you set them up. An easy way to check this is to activate the "ELK Console" from the ISY admin screen. If the ELK Console allows you access with the user code, and you are able to arm/disarm the system, the ISY should work with the same access code.

[FRR]

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

[Tunaman]

Hey Michel.

 

I replaced my M1XEP, and now everything appears to be working.

 

Hopefully, I'll find some time to give it a more through run-through.

 

So far, everything looks good, thanks for your patience while I worked through what turned out to be a non ISY issue.

[Michel Kohanim]

Hello all,

 

Elvis

401 = Unauthorized so please make sure userid/password is OK.

 

Now, ELK has it's own WSDK and REST interface the documentation for which you will find here.

 

FRR, we'll get back to you shortly.

 

tunaman, thanks so very much for the update.

 

With kind regards,

Michel

[dss]

I seem to be having the same problem as FRR. I'm using 3.1.13. I can access the virtual keypad with the pass code through the web browser but cannot arm disarm go to ELK console from ISY. The ISY interface is very slow when I click on an ELK tab. Does nothing and seems like completely froze up for about 1 minute until it refreshes and changes the tab. I can see my alarm sensor zones but it only lists the area and zone status physical status. I don't see the Name nor Type and I cannot manually enter the name. I get these errors in the log:

 

Thu 12/01/2011 01:51:00 AM : [FileOpen ] Open failed for [/CONF/INTEGER.VAR] ®

 

Thu 12/01/2011 01:51:00 AM : [FileOpen ] Open failed for [/CONF/STATE.VAR] ®

 

Thu 12/01/2011 01:51:00 AM : [FileOpen ] Open failed for [/CONF/INTEGER.VAR] ®

 

Thu 12/01/2011 01:51:00 AM : [FileOpen ] Open failed for [/CONF/STATE.VAR] ®

 

Thu 12/01/2011 01:51:04 AM : [ELK-ERR ] Get Topology

 

Thu 12/01/2011 01:51:11 AM : [Elk ] ELK-WAIT Waiting for retry 1 of 2 [0Bsd18001005D\r\n]

 

Thu 12/01/2011 01:51:18 AM : [Elk ] ELK-WAIT Waiting for retry 2 of 2 [0Bsd18001005D\r\n]

 

Thu 12/01/2011 01:51:27 AM : [ELK-ERR ] Get Topology

[elvisimprsntr]

Hello all,

 

Elvis

401 = Unauthorized so please make sure userid/password is OK.

 

Now, ELK has it's own WSDK and REST interface the documentation for which you will find here.

 

 

With kind regards,

Michel

 

If the rest/security interface as been depreciated, should it still be in the WSDK document?

 

My ID and PW are correct and the syntax for the wget command I pulled off a forum and confirmed with the wget --help option. Here is the output for a successful command:

 

root@Siri:~/SiriProxy# sh isy_living_off.sh

--2011-12-01 07:32:54-- http://192.168.69.90/rest/nodes/19496/cmd/DOF

Connecting to 192.168.69.90:80... connected.

HTTP request sent, awaiting response... 401 OK

Reusing existing connection to 192.168.69.90:80.

HTTP request sent, awaiting response... 200 OK

Length: 104 [text/xml]

Saving to: `cmdresp.log'

 

100%[================================================================>] 104 --.-K/s in 0s

 

2011-12-01 07:32:54 (2.34 MB/s) - `cmdresp.log' saved [104/104]

 

 

UPDATE

 

I have tried a number of the Elk REST commands defined in the Elk WSDK document an I get mixed results on the responses. Some result in 404 errors, other result in 200 status with empty contents, a few result in 200 status will what appears to be appropriate contents. All REST commands I get the initial 401 message when I have confirmed I am using the correct ID/PW. Some of the Elk REST 404 errors appear to be documentation errors. I have also seen random slow response as another forum member has reported.

[Brian H]

In the Add a New Device area.

In the drop down list.

[01.07] (2456D2) Icon LampLinc 2 pin.

Shouldn't that be (2856D2)?

[Michel Kohanim]

Hi dss,

 

The problem is that your ISY is not communicating with ELK. Please do ensure you review configuration documentation here:

http://www.universal-devices.com/mwiki/ ... ity_Module

 

Hi Elvis,

 

There were some documentation issues with keypads and text which have already been fixed in the next release. 401 might be OK because when you start wget, it has to first send a request with no credentials and then fill in the credentials and send it again.

 

/rest/security is NOT deprecated. It's still used when you do not have the ELK module.

 

As far as other anomalies, I would sincerely appreciate it if you could be more specific with respect to the commands and the outcome.

 

Hi Brian,

 

Yes indeed! Thanks so very much .. it's fixed.

 

With kind regards,

Michel

[polexian]

Is it possible for us to get comments in variables? This would help us remember what they are used for in our programs.

[polexian]

Something is wrong with this variable. It is not being properly updated and constantly sending out emails with the wrong status. ${elk.area.#.armedState}

 

Right now it is disarmed, and it is saying the last state it was armed to.

 

Joe

[elvisimprsntr]

 

Hi Elvis,

 

There were some documentation issues with keypads and text which have already been fixed in the next release. 401 might be OK because when you start wget, it has to first send a request with no credentials and then fill in the credentials and send it again.

 

/rest/security is NOT deprecated. It's still used when you do not have the ELK module.

 

As far as other anomalies, I would sincerely appreciate it if you could be more specific with respect to the commands and the outcome.

 

With kind regards,

Michel

 

Attached are some shell scripts, resulting XML responses, and logs of the wget communication. I added comments in the elk/isy_interrogate.log files where I noted discrepancies.

 

 

UPDATE

 

I fixed a bash script bug for the elk rest command to disarm the system. the resulting output indicated the command was successful, but the ISY did not disarm the Elk. I also changed the bash scripts to prompt the user for unique settings so you can run them at your facility.

 

I also have a question what "ae type" is in the area status output.

 

<?xml version="1.0" encoding="UTF-8"?>

 

And where do I find the elkArmType definition or enumeration?

rest.zip

Archive.zip

[FRR]

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

[dss]

Hi dss,

 

The problem is that your ISY is not communicating with ELK. Please do ensure you review configuration documentation here:

http://www.universal-devices.com/mwiki/ ... ity_Module

 

 

I found the problem, in the Elk RP in the M1XEP Setup I had checked "Enable Non-Secure Port" but hadn't "Send" it to the ELK.

[Michel Kohanim]

polexian,

 

Comments in variables we'll take into consideration.

 

elk-arm-state variable changes based on area/zone status. What are you trying to accomplish?

 

Elvis,

 

Thank you. Most of the errors are documentation errors which have been fixed. If you wish, you can send an email to me to tech@universal-devices.com and I can send you the latest doc (which will be including in 3.1.14).

 

All events and objects are defined in /web/elkobjs.xsd (Schema file).

 

With kind regards,

Michel

[polexian]

This is the program I am trying to run.

 

If
       (
            Elk Area 'Williams' 'Armed State' is Armed Stay Instant
        And Elk Area 'Williams' 'Arm Up State' is Armed with Bypass
       )
    Or (
            Elk Area 'Williams' 'Armed State' is Armed Away
        And Elk Area 'Williams' 'Arm Up State' is Armed Fully
       )
    Or (
            Elk Area 'Williams' 'Armed State' is Armed Vacation
        And Elk Area 'Williams' 'Arm Up State' is Armed Fully
       )
    Or (
            Elk Area 'Williams' 'Armed State' is Armed Stay
        And Elk Area 'Williams' 'Arm Up State' is Armed with Bypass
       )

Then
       Wait  10 seconds
       Send Notification to 'BothPhones' content 'Elk Armed/Disarmed'
       $ArmedAway  = 1

Else
  - No Actions - (To add one, press 'Action')

 

The notification sends an email with the subject line ${elk.area.#.armedState}.

 

Currently the armed status of the alarm is disarmed, but when I send this email it say's it's armed away.

 

Am I calling the wrong variable?

[rsknappmd]

With the addition of variables, it is now possible to actually obtain the functionality I had with the X-10 "time commander" winevm scripts.

Thanks. Great job!!

[Chris Jahn]

The notification sends an email with the subject line ${elk.area.#.armedState}.

 

Currently the armed status of the alarm is disarmed, but when I send this email it say's it's armed away.

 

Am I calling the wrong variable?

 

The problem is that it will use the event that caused the program to run, and in this case, that last event will be an armed up event. You may be able to accomplish what you want by splitting it into two programs, but its going to be tricky. I think you would need the first program to have only armed conditions and a 10 second wait (similiar to what you have), and have a second program stop the first program within 10 seconds if it doesn't actually arm.

 

Aha, of course you could change it to use the actual area, since you know it is 'Williams', assuming 'Williams' is area 1, the variable would be ${elk.area.1.armedState}

[Chris Jahn]

With the addition of variables, it is now possible to actually obtain the functionality I had with the X-10 "time commander" winevm scripts.

Thanks. Great job!!

 

Thank you so much!

[polexian]

The notification sends an email with the subject line ${elk.area.#.armedState}.

 

Currently the armed status of the alarm is disarmed, but when I send this email it say's it's armed away.

 

Am I calling the wrong variable?

 

The problem is that it will use the event that caused the program to run, and in this case, that last event will be an armed up event. You may be able to accomplish what you want by splitting it into two programs, but its going to be tricky. I think you would need the first program to have only armed conditions and a 10 second wait (similiar to what you have), and have a second program stop the first program within 10 seconds if it doesn't actually arm.

 

Aha, of course you could change it to use the actual area, since you know it is 'Williams', assuming 'Williams' is area 1, the variable would be ${elk.area.1.armedState}

 

Worked great Chris, thank you!

[Mike Ippolito]

does the new firmware allow two logins? I seem to be having lockup issues when I have the admin console open and my mobilinc Pro (iphone app) tries to access the server.

 

Mike

[Michel Kohanim]

Hi Mike,

 

Yes, you can have as many as 32 simultaneous connections and 10 subscriptions.

 

When the Admin Console locks up, does your ISY programs still function?

 

With kind regards,

Michel