Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Arming ELK
Hey everyone!

I updated my ELK M1EZ8 and CQC today to the latest releases. Everything is working fine except I can't arm my ELK from CQC anymore (which has worked fine for the past 5+ years).

I sent Dean an email and all appears ok on the CQC side so it seems there is something with the ELK config and I was wondering if anyone had any ideas.

Arming it via ELK java applet works fine and I can disarm it with CQC. No errors are returned.

Here is the command syntax:

This is with the ELK on firmware 4.6.8 and the latest CQC beta.

Any advice is appreciated!

The log shows this command going out:


with the xxxx obviously being a real user code. That appears to be correct. The disarm is:


which is the same as above except a0 instead of a2 as the command, and it works fine. The checksums are not displayed, since this log output is pre-checkshum calculation. Those values are just put straight into the memory buffer to be sent.

No error appears to be returned from the Elk in response to either of them. So I'm not sure why it wouldn't be working. Is there a setting in the user account that indicates whether the account can arm or not, or something like that?
Dean Roddey
Software Geek Extraordinaire
I checked in ElkRP and the user account is set to be able to arm. I saw somewhere else that if an "access" option was checked it wouldn't work as it did something with the pin code. I didn't have that option checked so everything else seems normal on that front.

I'll keep browsing the net to see if I can unlock any other ideas.

Thanks for the help!
I got the issue resolved. Here is what I did in case anyone else stumbles across the same issue...

In ElkRP there is an option under the user accounts that says "User has an access credential...." which I thought was the "access" issue that I read about.

Under User Authorizations on the left column halfway down there is another option called "access" and that is the one that needs to be unchecked. I had overlooked it before.

So all is well now!
Access to elk means "unlock" the door. If you have a keypad outside your door and enter a code with access priveleges, it will disarm the alarm and open the door (assuming you have written a rule to do the actual open stuff). The rule is also keypad specific, so you can open only the door near that keypad. If a code without access priveleges is used, the alarm is disarmed, but the door won't open.

The downside to this method is that you can't use a code with access priveleges to arm the system. You have to use quick arm, or a different code. The rs-232 interface doesn't support quick arm, so you have to use another code. I created a CQC code to simulate quick arm which doesn't have disarm priveleges so it isn't a security risk.


Thanks for the explanation!
I like the idea of creating another user just for CQC to use.

Take care,
rbroders Wrote:I created a CQC code to simulate quick arm which doesn't have disarm priveleges so it isn't a security risk.


I tried this and it didn't work. I created a user in Elk for just the CQC that had Arm priviledges but not Disarm. Then I put this in the code for CQC in my template

Tried and when I run this it will arm the system and if I run it again it will disarm. I want it to only arm. Thought that was made clear in the rights for that User. Also on the Action I would think it would only Arm, as the code is ArmStay, and NOT disarm. How do I fix this so when I run this code it only Arms? I want the user to have to put in the code if he wants to disarm.
Ah yes, you have run in to an unfortunate Elk bug.

If the system is armed and you attempt to change the arm status with an invalid code or a code which does not have disarm priveleges, it will disarm the system.

Shocking isn't it? Try your same call with a completely invalid code and it will still disarm the system. If you are in Stay mode and want to change to Away mode, it will also disarm the system.

I sent a few e-mails to their support staff and they say it is not a bug. Programs accessing the RS-232 interface are supposed to know not to call the arm interface when the system is already armed. Ridiculous. I suppose I could add something to the driver to prevent it. Ugh. If you want to change arm modes use ArmStepToNextAway or ArmStepToNextStay instead.

Here is my response from Elk. Feel free to give Brad your opinion of their nasty security hole.

Quote:From brad.weeks at

Good morning Bob,

I forwarded your email to our Engineering Department and Product Manager for confirmation and the M1 is operating as expected. This is not a bug. Please let me try to explain what is happening:

This is correct operation but is something that all integration partners initially stumble with .

Each of the individual ASCII Protocol Arm commands Away, Stay, etc. presume the control to be disarmed to start with.

So if the Panel is already armed to Away and they wish to change the state to Vacation mode they have to send the ASCII command for Arm to next Away Mode. And if the panel is already armed to Stay and they wish to change to Stay Instant, etc. they must send the ASCII command for Arm to next Stay Mode. Naturally this requires them to first check to see what state the control is BEFORE sending any commands.

Thank you,

Brad Weeks
Technical Support
Toll Free: 800-797-9355 | Ph: (828) 397-4200 ext.10011 | Fax: (828) 397-4415

-----Original Message-----

From: Bob Brodersen [mailto:]
Sent: Wednesday, October 12, 2011 6:08 PM
To: Brad Weeks
Subject: RE: Serial Control of ELKM1G

Thanks Brad,

I do have the latest version of this document (it hasn't changed recently). I send 0Da1100085800 and the control starts arming AWAY. Then I send 0Da2100085800, and the system disarms itself. I think you have to admit this is a bug (firmware 5.2.2). Note the 0858 user does not have disarm priveleges.

I notice there is an "Arm, Step to Next Away mode (a7)" function which might do a better job of accomplishing what I want anyway. Still, I hope you will investigate this bug.

So I just put some logic in to see if the system is disarmed and if it is then arm. That works so it does not disarm now when I am trying to arm the system.

If System::Equals



Also tried if system was not Armed Stay then to arm it in the stay mode but it just disarmed it if it was armed already, in another mode. Was trying so say it was in Night mode and I wanted to switch to Stay mode. Could not get that logic to work and even tried with it disarming and then arming but did not work. So if I want to switch armed modes I guess I need to disarm it first and then select the armed state I want.
I think that is correct. The good news is that you can disarm it without entering a valid code first! Thus you don't need to have a hardcoded ElkCode in the system which has disarm priveleges.

So you don't have to worry about someone breaking into your house, starting up the CQC designer, finding the ElkCode buried in the screen somewhere and then later using that code to enter your house and steal your stuff.

Of course that would require taking advantage of the Elk bug which may be fixed at some point, I hope.


Forum Jump:

Users browsing this thread: 1 Guest(s)