Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Is it possible to pass onto CQC what user code was used on the ELK?
#1
Is it possible to pass onto CQC what user code was used on the ELK? And at what keypad it was used on?

Thank you
Reply
#2
Well, poking around, it looks like it could be done, but unfortunately not in a form we can make use of currently. That's not something you'd put into a field. It would really require a new trigger type, which is not a trivial undertaking. What would probably be nicer would be an arm/disarm trigger, but even then, we couldn't do it because the Elk doesn't send the user code with an arm/disarm. It just sends it out any time a code is entered, apparently, via a separate message. So it wouldn't be practical to try to correlate it with some other activity. So all you'd know is that a user code was entered, but not why it was entered or what it caused to happen (if anything.)
Dean Roddey
Explorans limites defectum
Reply
#3
Too bad. It would be great if I were to use the Elk for access control. Then I can have CQC do something based off of who it was who entered.

I guess I may be able to have the Elk do run a html trigger to get the ball rolling on the CQC, does that make sense?

Thanks
Reply
#4
If you have access to the info within the Elk, I guss you could do that.
Dean Roddey
Explorans limites defectum
Reply
#5
Unfortunately, I am unable to do with Elk what I wanted to. Is there a way of integrating CQC to a Prox card reader? I was hopping on using the Elk for that. That way I can have certain triggers based off of who opens the door.

Thanks
Reply
#6
I've never looked at any card readers. I could of course expose the 'user entered a code' stuff from the Elk, though given how it works I don't know you'd really correlate it solidly with some particular event. For that matter, I'm not sure how you'd do that with a card reader either. How would you know what happened just because you get some info from the card reader?

If there's no better way to correlate using some entry mechanism to what happened than the Elk already provides, it would be easier to just support the Elk's 'user entered a code' notification.
Dean Roddey
Explorans limites defectum
Reply
#7
My idea would be to use the Elk as an access control and at the same time, do something based off of the user. For example, have CQC welcome whoever it is that swipped the card by name. Or User A, likes the lights on during the day in the entrance way but User B doesnt. So depending on who it was that swiped it would run that rule.

In the Elk itself there is no way to easily have it call out to a trigger on CQC, so I believe CQC would need to see the user number.
Reply
#8
Here is more on the solution I posted on your thread on CT. Output 200 would not be a real physical output on the system but a "phantom" output (i.e. one not tied to any hardware). A lot of people use Elk Outputs as variables.

You can write rules in the Elk:

Code:
WHENEVER System is Disarmed
   AND LAST USER WAS (User 2)
   THEN Turn Output 200 on for 5 Secs

Then in CQC:

Set a Trigger on the Output200 field
Write a Triggered event to do whatever you want when Output200 goes True.

It doesn't necessarily have to do something right away. You could just set a CQC Global Variable (i.e. LastUser) in your triggered event and use it later. That way GVar:LastUser should always have the last user that did something on the Elk. You would need one Elk Rule and "phantom" Output for each user you want to track.
Wuench
My Home Theater/Automation Website

[THREAD=5957]BlueGlass CQC Config[/THREAD]
[THREAD=10624]Wuench's CQC Drivers[/THREAD]
Reply
#9
Thank you. I was a bit confused by the post on CT, but this is much clearer. The only issue I still have is will that only run when the alarm was armed, and then got disarmed? What happens if you want the rule to run on the Elk even when the alarm was not armed to begin with?

Is it maybe possible to create an area in the Elk which is not going to be used, then set a in that same CQC trigger that you mentioned, that will arm that area again right after someone gained access?

Thank you
Reply
#10
Yeah that's what I was saying about storing the user in a variable. The elk is only going to log the user when you arm or disarm, in between it doesn't change. So you could add another rule for "When system is armed" in the elk to flip the output to capture that side if you want.

Then in CQC your triggered event would just write a last user variable and you can use that whenever you want for any other type of triggered or scheduled event. It would always contain the last user that did something.
Wuench
My Home Theater/Automation Website

[THREAD=5957]BlueGlass CQC Config[/THREAD]
[THREAD=10624]Wuench's CQC Drivers[/THREAD]
Reply


Possibly Related Threads…
Thread Author Replies Views Last Post
  Display of an Extended Wait for User Image kblagron 4 1,312 09-20-2019, 02:21 PM
Last Post: kblagron
  Omni arming mode user info dlmorgan999 2 929 05-02-2019, 04:42 PM
Last Post: dlmorgan999
  I've open sourced my general purpose code Dean Roddey 0 794 03-09-2019, 06:53 PM
Last Post: Dean Roddey
  Can't Login to IV with New User Account Jnetto 10 5,671 10-28-2017, 11:07 AM
Last Post: Dean Roddey
  \User\CQC\Blanker pinballmark 2 1,722 10-09-2017, 12:54 PM
Last Post: pinballmark
  Configure -> User error zra 4 3,204 12-07-2016, 02:19 PM
Last Post: Dean Roddey
  User Surveys potts.mike 5 2,906 10-26-2016, 06:33 PM
Last Post: Dean Roddey
  user action documentation? IVB 3 2,263 08-12-2016, 08:08 PM
Last Post: IVB
  Zwave Scene Controllers and User Actions potts.mike 19 5,232 08-28-2015, 09:17 AM
Last Post: Dean Roddey
  Who is using user actions? potts.mike 5 2,262 10-25-2012, 08:06 PM
Last Post: Dean Roddey

Forum Jump:


Users browsing this thread: 1 Guest(s)