Elk 6010 two-way RF keyfob used with an external HA system

etc6849

Senior Member
Anyone using this with an Elk M1G, along with a PC based home automation system?
http://www.elkproduc...wo-way-wireless

I'd like to use all four buttons along with the button combinations to toggle various events in my PC based HA system. Since the RS232 M1G protocol probably does not yet support the keyfobs directly (as it does for the keypad's function keys), I'm thinking about assigning a task to each button.

I've never used keyfobs with an Elk M1G, but I'm assuming the buttons would just show up in ElkRP as they do for the keypads; allowing you to program an event that is activated upon a button press (but with no button illumination events). For my scenario, I would set the event to 00, but would use ElkRP rules to assign a task number to the button/button combination. The PC then receives notification of when the task is activated and would perform the required actions.

I think the answer to my question is yes as ElkRP has an option under WHENEVER for "Keyfob Button Press." However, I wanted to make sure I could do this with all four buttons and four button combinations before dropping money on several keyfobs and the M1XRFTW transceiver. The two-way feedback of the 6010 sounds like a great improvement over other options.

I'm not sure if I like the idea of a sealed unit, but everything else looks useful such as button combos etc... The keyfobs also have a nice look to them.

The manual states:

Overview
The 6010 two-way Keychain Remote displays confirmation of transmitted commands as well as M1 system status utilizing a two-color LED (Green/Red) Indicator. The 4 buttons (keys) on the 6010 can actually be used to trigger up to 6 defined events, programmable from the M1 Keypad [Wireless Setup > Keyfob Defintions] menu or ElkRP Software. NOTE: All buttons require at least a 1/2 second press duration to avoid accidental event activations. Some buttons require even longer durations (see below). By factory default buttons 1 thru 4 will trigger keyfob definitions 1 thru 4, pressing buttons 1 & 2 simultaneously will trigger definition 7, and pressing buttons 3 & 4 simultaneously will trigger definition 8. There is also an option, programmable by wireless zone, that allows buttons 1 thru 4 to be converted to respond as buttons 5 thru 8. This will allows 2 different users to have their own 4 triggerable events.

The key (buttons) and their markings, along with the default functionality is as follows:
Key (Button) #1 Yellow [ LOCK ] - Default definition=0027 [Key Momentary Arm-Away]. Shortly after this button is pressed the status LED will illuminate RED if the Control has armed. Note: If the Control had a recent Alarm that was not cleared or acknowledged it will take 2 presses to Armlng. The first press will acknowledge the previous Alarm and illuminate GREEN.

Key (Button) #2 Green [ UNLOCK ] - Default definition=0029 [Key Momentary Disarm]. Shortly after this button is pressed the status LED will illuminate GREEN if the Control has disarmed. Note: If an Alarm is active this button will initially silence the Alarm, after which a second press will be needed to acknowledge the alarm and prepare the control for the next Arming.

Key (Button) #3 Blue [ i ] - This key has a dual role. A short 1/2 sec. press will trigger a status inquiry to the M1. The expected response will be: GREEN=System Disarmed, RED=System Armed, Flashing RED=System in Alarm (Memory), or Blank=Out of Range. OPTIONAL: Pressing and holding this button for 4 seconds will activate programmable definition 3. The default definition of button 3=0000 [blank]. It is up to the Installer to program the optional definition.

Key (Button) #4 Red [ Triangle ] - OPTIONAL: Pressing and holdiing this button for 2 seconds will activate programmable definition 4. Because of the 2 second press time this button is best suited for activating a Panic type of alarm. But the default definition of button 4=0000 [blank]. It is up to the Installer to program the definition for this optional feature.
 
Keyfobs can drive rules and events, done this multiple times with multi-partitioned systems to enable arming entire "system" but only allow a single partition disarm.

As far as being able to spit serial data or similar, I can't see a reason why not, it's still just a rule and triggered event.
 
I think you're right as that's how keyfobs show up in ElkRP now. However, due to the alarm status indication of the LED on the keyfob, I'm not sure if the top two buttons can be re-purposed.

I guess I'll find out since I've ordered them! The three zone sensor looks very neat too so I figured I'd play with that for my garage.
 
The Elk 6010 keyfobs work well! Great range and the confirmation packet is reassuring. They feel nice in your hand too.

A FEW SUGGESTIONS FOR ELK:
The RS232 protocol doesn't have keyfob User ID support (according to my actual test and reading the ascii protocol document). It would be great if there was an addition to the protocol that would send the keyfob user id along with which button was pressed.

Currently, I had to assign tasks to each keyfob button. In this manner, the task id is received by my home automation system like this:

0ATC003000D5

Then the system performs some action based on receipt of the task (task 3 in this case). However, the system does not know which keyfob was used :eek:

Normal keypad buttons on the keypads use the "KC - Keypad KeyChange Update" packet type. The KC packet not only includes which button was pressed, but also the keypad (in additional to illumination status and chime mode).

What would be great is to have the same capability with the keyfobs. Since ElkRP allows assignment of a "Keyfob User ID", I don't see why a new packet type could not be made that would include the Keyfob User ID and what key was pressed.
 
Elk was kind enough to get back to me and offered this suggestion that differentiates which keyfob was used:

"If you go to installer programming [using a keypad, not Elk RP] on the M1, Globals – 07, G44, right arrow, enter 55555 at a: this will turn on RF diagnostic data coming out of the M1 like this:
A2-Z094-F00004-L0-B0-R0-p0-b0,M5-112-21A [output on the RS232 port along with the other usual data]

In the 112 field, the center character is the button number if the Transmitter ID starts with an F."

This works great with Premise , although the code for the Elk M1G Premise module will need some updates. This will alleviate the need to use tasks in Elk RP for button presses to be picked up, but will require each keyfob be programmed into Premise by hitting a button on the keyfob after first setting a boolean property called learn keyfob to true.
 
How is the 2-way function working out for this?

I'm just curious - I went with a different type of remote and a weigand interface so every button is a "user" and every remote and every button are different and I can do whatever I want with them and know which button on who's remote was pressed.
 
The two way function is pretty neat. I like having the confirmation that a button press was received by the Elk. The status button also gives a quick indication of system status, another plus.

Which weigand keyfobs did you go with?
 
Back
Top