Keyfob Setup

[ltyndall]

Continuing to make good progress with my M1G assembly/testing. I hit a snag on the keyfobs and was hoping for some advice.

How are they supposed to be set up? I have:
-Definition=15 = Keyfob
-Type = 0 = EOL Supervised/RF (the only option)
-Wireless Setup
-Enabled is checked
-Supervised = 0=Not Supervised
-Option 1,2, and PIR are NOT checked
-Keyfob User ID set to a User ID – but something is wrong with that USerID (will not save to system without a code)

Problems:
-I can trigger buttons 1, 2, 3, 4, and 7 (1/2 together). Button 8 (3/4 together) do nothing
-I set up parallel users for the Keyfobs. E.g User 1 is Bob, User 101 is Bob’s keyfob. I have the keyfob user set as:
-All areas checked
-Arm and Disarm are checked
-Checked User has an access credential (like keyfob) – this sets the User Code to blank, but it will not save to the system as blank
- What I am trying to acheive with the keyfob setup and associated User is to know which user's keyfob triggered an action.



So in Summary:
1. Is there any thoughts on why button 7 works but not button 8?
2. How do i configure the keyfob/User to know the source of the keyfob button?

Thanks for any advice!

Regards,
Vector

 

[signal15]

No idea on Button 7 not working. But I think the checkbox under the user for keyfob means a proximity card, not a keyfob. Maybe I'm wrong, but I set up user codes for my keyfob users. They are just random and never used in practice.

If you want to figure out the source of the keyfob, then do a rule like this:

Whenever keyfob button 1 is pressed
AND last user was Bob (101)
Then do something

 

[blmxm]

Continuing to make good progress with my M1G assembly/testing. I hit a snag on the keyfobs and was hoping for some advice.

How are they supposed to be set up? I have:
-Definition=15 = Keyfob
-Type = 0 = EOL Supervised/RF (the only option)
-Wireless Setup
-Enabled is checked
-Supervised = 0=Not Supervised
-Option 1,2, and PIR are NOT checked
-Keyfob User ID set to a User ID – but something is wrong with that USerID (will not save to system without a code)

Problems:
-I can trigger buttons 1, 2, 3, 4, and 7 (1/2 together). Button 8 (3/4 together) do nothing
-I set up parallel users for the Keyfobs. E.g User 1 is Bob, User 101 is Bob’s keyfob. I have the keyfob user set as:
-All areas checked
-Arm and Disarm are checked
-Checked User has an access credential (like keyfob) – this sets the User Code to blank, but it will not save to the system as blank
- What I am trying to acheive with the keyfob setup and associated User is to know which user's keyfob triggered an action.



So in Summary:
1. Is there any thoughts on why button 7 works but not button 8?
2. How do i configure the keyfob/User to know the source of the keyfob button?

Thanks for any advice!

Regards,
Vector

I noted the issue with keyfob user not properly saving in this thread awhile back:
http://www.cocoontech.com/forums/index.php...c=15158&hl=
Item #3.
I will have to disagree with signal as the checkbox in RP specifies card, fob, ibutton in lieu of code. Additionally I found that if you create a user using the checkbox, and send to the control prior to leaving the screen, the control will indeed report the name associated with that created user in the logs. However upon the next connection RP will report a conflict. The fact that leaving the user page is when the setting is lost, clearly makes it an RP software issue in my mind.
I have for now decided that I prefer to avoid the conflicts on connection, and not turn that off. But maybe the user info is more important to you, so you could send it to the control and it will work as you want, and then you can either ignore or disable the conflict reporting.
So far as your problem with button 8 I am not using mine. Maybe if you have it firing a task, it would be a good idea to confirm that task functions as you expect by assigning a keypad F button and testing it that way. Perhaps it could be a rule issue instead of the FOB. I will say however that although I specified a "crystal" FOB from my distributor, when they came in they were SAW. I know some have these working, but I brought mine back and exchanged for the crystal to be safe. You may want to confirm that as well.
Good Luck!
Edited to add: If you go under wireless setup/transmitters and double click on the zone you setup for the FOB, you can set supervision to none, which you will want to do to avoid the FOB being reported as a missing transmitter when it is out of range.

 

[signal15]

I assumed "fob" in the user creation screen meant an RFID fob, not a wireless remote. All of the other examples they give in that screen are items that would be used with a Weigand reader. And, I have some some of these weigand compatible tokens that are considered fobs.

It doesn't matter, seems to work either way. Checking that box just seems to allow you to create a user without a code.

 

[ltyndall]

Thanks to both of you for your information!

Button 8 started working at some point - not sure where I had gone wrong!

On the association with a user, I was able to get it to work by assigning a User that had an actual code ans Signal suggested. It appears that that fob checkmark must in fact refer to an RFID fob.

So yes you can create a User in RP without a code, but it will not transfer to the M1G. Once I put the code in for the "Keyfob User", it transferred to the M1G properly and left no conflicts.

SO now it does fully associate the keyfob "sensor" with the keyfob user. This works in rules as Signal stated, and also the proper user shows up in the Log for Arm/Disarm events. I don't know why you need to have a code for a keyfob, but at least it works. The only downside is that it is that many more codes that someone could guess at.

Thanks againfor the help!
Vector

 

[blmxm]

Checking that box just seems to allow you to create a user without a code.

Signal,
Lets disregard whether one is using a prox card FOB etc., and consider that we are just in the RP software. When I check the box it does appear that one has created a user without a code. If there was a code for the user it is erased. However if you leave the just created user and navigate to any other page in RP, then return to the just created user, the checkbox is unticked. I have duplicated this behavior on a fresh install of RP on more than one computer. This occurs regardless of whether I save before leaving the page, am connected to the control etc. Also if I do as Vector has, I still find that the box is unchecked in the same fashion. I guess the first question is can you duplicate this behavior or am I just "lucky"....lol
As you state above it seems to me to be useful to create a user without a code and only some type of electronic key.

And Vector, when you check your user now, does the box remain checked? If not on the next upload to the control I would expect the fob to not be recognized.

Maybe I am just completely misunderstanding what the checkbox's purpose is, or was hit with the dumb stick one time too many.

Edited to add: OK, after watching the RP video on ELKs site, their software shows the checkbox to be solely for a Wiegand key which when creating the user has it's code read. It also states that this is a 12 digit code, so I tossed 12 digits in the code box and the checkbox indeed now stays ticked. So Signal I would say you are correct in your assessment that the use of the "codeless" checkbox was never intended for a wireless FOB. Perhaps it was not the dumb stick, just the ignorant stick...lol I don't know why they changed the wording on it as once I viewed the video, that version was clear.

 

[ltyndall]

Just to confirm, I was able to duplicate the results BLMXM got by doing the following steps for the Keyfob User:

1. Putting a Checkmark in the "User has an access credential..." field
2. Input a 12 digit code on the Keyfob User - the actual code is irrelevant - just needs 12 digits to save



So now the keyfob works AND is associated with a Keyfob User. I can see in the log the correct user and I can use that User information to perform automation.

Thanks for the help on this!

Regards,
Vector