Re: [Coworking] Re: How RFID reader writer works?

[Jacob Jay]

For the device MAC to user account association I wrote a simple ARP scan script 
which is thus vendor independent. The user does need to hit a local webserver 
(could just be a simple HTTP port handler with the ARP script) which then uses 
the ARP table to lookup their MAC address from their LAN IP, redirecting the 
request to the management app with the MAC as a param to record the initial 
association. If the user is already signed into the app, this process is (or 
could be) completely transparent to them. The script obviously also 
transparently checks-in newly connected MACs, and checks them out when they 
disappear.

Of course the initial HTTP redirection needs to be performed somehow, such as 
by a captive portal, which means updating its whitelist with the MAC once 
checked in…

I never however used a captive portal for this, preferring instead to chivvy 
users to the authoritative website (or 'set them up' when they first visit) -- 
not of course appropriate if complete checkin coverage is needed, but in 
combination with RFID almost all users are covered thus adequate for my 
purposes at least.

It's good to hear the RouterBoards can handle so many devices, although that's 
not really the metric that concerned me but is/was rather the latency they can 
add, especially without extensive knowledge of network tuning in bandwidth 
restricted scenarios. For the average setup, out of the box solutions like 
Ubiquiti have been a better choice even though the AP controller system is 
rather opaque (that API browser is neat though!).

Actually just had a look at the latest RouterBoards, the CloudCore line sound 
pretty good for busier spaces, is this what you've had experience with? I'd 
probably be happy running captive portal and QoS queues on it, and make up the 
difference in cost (against Ubiquiti) with simpler APs :) Seems like setting up 
for roaming and so on still isn't as easy as with UniFi APs though…



> On 18 Apr 2017, at 9:42 pm, Adrian Palacios  wrote:
> 
> @Alex, slight side-answer. Unify controllers have a great API that exposes 
> every imaginable piece of data about connected clients and your network. Docs 
> from Ubiquiti are pretty poor but this project and its source provides a 
> quick way to get started accessing that data 
> https://github.com/malle-pietje/Unifi-API-browser. A small service reading 
> event data or connected clients every a few minutes can easily be used to 
> check members in and out.
> 
> @Jacob Jay. We currently connect to a range of hotspot/captive portal 
> devices, some of them incredibly capable. My personal favourite? Mikrotik. 
> They are the underdog out of all of the ones we connect to but they have 
> nothing to envy to the big boys. We have seen plenty of success cases and 
> networks with over 2K devices, or more during events, running just fine + the 
> play nice with Uniquity APs, which I think are unbeatable. Members only need 
> to check in the first time they use a new device, we will remember them from 
> that moment on. Unlike  many of the ones we've worked with, their built-in 
> scripting engine and events system makes it really easy to build integrations 
> with other systems without having to rely on the infamous RADIUS!
> 
> @Steve Suard. If you plan to build your own RFID tool, this reader is pretty 
> reliable and comes with SDKs for a good number of programming languages. 
> Building a tool that reads a card and compares that to a local database 
> should not be too difficult, if you have access to a coder. That ugly thing 
> is the most reliable we've found out of the ones we have tested.
> 
> @Sarah. There are plenty of options to facilitate check-ins when using NX 
> (front-desk ipads, desktop readers, door readers/access control, wifi/network 
> tracking, ...). A bit depends on budget, feel free to reach out to discuss. 
> This will also give you the basic options without going into too much 
> technical detail: 
> http://www.nexudus.com/en/blog/read/292950659/the-art-of-checking-members-in-and-out
> 
> Adrian

-- 
Visit this forum on the web at http://discuss.coworking.com
--- 
You received this message because you are subscribed to the Google Groups 
"Coworking" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to coworking+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Coworking] Re: How RFID reader writer works?

[Alex Hillman]

Awesome. Great to know. Thanks Adrian!


--
*The #1 mistake in community building is doing it by yourself.*
Better Coworkers: http://indyhall.org
Weekly Coworking Tips: http://coworkingweekly.com
My Audiobook: https://theindyhallway.com/ten

On Tue, Apr 18, 2017 at 4:18 PM, Adrian Palacios  wrote:

> Sure! that's easy too. When a known client connects to your network, UniFi
> will send that user to your custom portal with their mac address, as per my
> last message, nothing new here. When you receive that mac address, look the
> user up by mac address in your database, if you find it, before asking them
> to log in, just send them back to UniFi as if they logged in using a
> username/password to let UniFI know they are good to go.
>
> On Tuesday, April 18, 2017 at 9:12:54 PM UTC+1, Alex Hillman wrote:
>>
>> Neat, thanks Adrian!
>>
>> Curious - do you know if it's possible to only do that authentication
>> once? Essentially, once a device's mac is registered, can the hotspot
>> portal let people connect without additional logins in the future, so long
>> as the device is known?
>>
>>
>> --
>> *The #1 mistake in community building is doing it by yourself.*
>> Better Coworkers: http://indyhall.org
>> Weekly Coworking Tips: http://coworkingweekly.com
>> My Audiobook: https://theindyhallway.com/ten
>>
>> On Tue, Apr 18, 2017 at 4:09 PM, Adrian Palacios 
>> wrote:
>>
>>> Right! You somehow need to make that link between mac and member :).
>>> With UniFi, the simplest option is to enable the hotspot portal and
>>> redirect the authentication page to a server of your own. UniFi will send
>>> your server the MAC address of the member trying to authenticate and a few
>>> variables to let your server make sure the call is legit. You would then
>>> ask the user for their credentials (email, password,...?) and validate them
>>> against your member database. If valid, you would store the mac with the
>>> user in your database (that's the link between a user and the mac!) and
>>> send the user back to the UniFI controller letting it know the
>>> authentication was OK so they can connect to network, again with some magic
>>> to let Unifi your call is legit too.
>>>
>>> Attached an example of what your own sever would look like to get you
>>> going! Can't find right now where I got it from but it helped us crack this
>>> process.
>>>
>>> On Tuesday, April 18, 2017 at 8:45:07 PM UTC+1, Alex Hillman wrote:

 Adrian - yep, we've worked pretty extensively with the API, but that
 doesn't *really* help tie a specific device's MAC address to it's
 owners' account. Pretty sure that's where something like a captive portal
 is needed, right?


 --
 *The #1 mistake in community building is doing it by yourself.*
 Better Coworkers: http://indyhall.org
 Weekly Coworking Tips: http://coworkingweekly.com
 My Audiobook: https://theindyhallway.com/ten

 On Tue, Apr 18, 2017 at 3:42 PM, Adrian Palacios 
 wrote:

> @Alex, slight side-answer. Unify controllers have a great API that
> exposes every imaginable piece of data about connected clients and your
> network. Docs from Ubiquiti are pretty poor but this project
>  and its source
> provides a quick way to get started accessing that data
> https://github.com/malle-pietje/Unifi-API-browser. A small service
> reading event data or connected clients every a few minutes can easily be
> used to check members in and out.
>
> @Jacob Jay. We currently connect to a range of hotspot/captive portal
> devices, some of them incredibly capable. My personal favourite? Mikrotik.
> They are the underdog out of all of the ones we connect to but they have
> nothing to envy to the big boys. We have seen plenty of success cases and
> networks with over 2K devices, or more during events, running just fine +
> the play nice with Uniquity APs, which I think are unbeatable. Members 
> only
> need to check in the first time they use a new device, we will remember
> them from that moment on. Unlike  many of the ones we've worked with, 
> their
> built-in scripting engine and events system makes it really easy to build
> integrations with other systems without having to rely on the infamous
> RADIUS!
>
> @Steve Suard. If you plan to build your own RFID tool, this reader
>  is
> pretty reliable and comes with SDKs for a good number of programming
> languages. Building a tool that reads a card and compares that to a local
> database should not be too difficult, if you have access to a coder. That
> ugly thing is the most reliable we've found out of the ones we have 
> tested.
>
> @Sarah. There are plenty of 

Re: [Coworking] Re: How RFID reader writer works?

[Adrian Palacios]

Sure! that's easy too. When a known client connects to your network, UniFi 
will send that user to your custom portal with their mac address, as per my 
last message, nothing new here. When you receive that mac address, look the 
user up by mac address in your database, if you find it, before asking them 
to log in, just send them back to UniFi as if they logged in using a 
username/password to let UniFI know they are good to go.

On Tuesday, April 18, 2017 at 9:12:54 PM UTC+1, Alex Hillman wrote:
>
> Neat, thanks Adrian!
>
> Curious - do you know if it's possible to only do that authentication 
> once? Essentially, once a device's mac is registered, can the hotspot 
> portal let people connect without additional logins in the future, so long 
> as the device is known?
>
>
> --
> *The #1 mistake in community building is doing it by yourself.*
> Better Coworkers: http://indyhall.org
> Weekly Coworking Tips: http://coworkingweekly.com
> My Audiobook: https://theindyhallway.com/ten
>
> On Tue, Apr 18, 2017 at 4:09 PM, Adrian Palacios  > wrote:
>
>> Right! You somehow need to make that link between mac and member :). With 
>> UniFi, the simplest option is to enable the hotspot portal and redirect the 
>> authentication page to a server of your own. UniFi will send your server 
>> the MAC address of the member trying to authenticate and a few variables to 
>> let your server make sure the call is legit. You would then ask the user 
>> for their credentials (email, password,...?) and validate them against your 
>> member database. If valid, you would store the mac with the user in your 
>> database (that's the link between a user and the mac!) and send the user 
>> back to the UniFI controller letting it know the authentication was OK so 
>> they can connect to network, again with some magic to let Unifi your call 
>> is legit too.
>>
>> Attached an example of what your own sever would look like to get you 
>> going! Can't find right now where I got it from but it helped us crack this 
>> process. 
>>
>> On Tuesday, April 18, 2017 at 8:45:07 PM UTC+1, Alex Hillman wrote:
>>>
>>> Adrian - yep, we've worked pretty extensively with the API, but that 
>>> doesn't *really* help tie a specific device's MAC address to it's 
>>> owners' account. Pretty sure that's where something like a captive portal 
>>> is needed, right?
>>>
>>>
>>> --
>>> *The #1 mistake in community building is doing it by yourself.*
>>> Better Coworkers: http://indyhall.org
>>> Weekly Coworking Tips: http://coworkingweekly.com
>>> My Audiobook: https://theindyhallway.com/ten
>>>
>>> On Tue, Apr 18, 2017 at 3:42 PM, Adrian Palacios  
>>> wrote:
>>>
 @Alex, slight side-answer. Unify controllers have a great API that 
 exposes every imaginable piece of data about connected clients and your 
 network. Docs from Ubiquiti are pretty poor but this project 
  and its source 
 provides a quick way to get started accessing that data 
 https://github.com/malle-pietje/Unifi-API-browser. A small service 
 reading event data or connected clients every a few minutes can easily be 
 used to check members in and out.

 @Jacob Jay. We currently connect to a range of hotspot/captive portal 
 devices, some of them incredibly capable. My personal favourite? Mikrotik. 
 They are the underdog out of all of the ones we connect to but they have 
 nothing to envy to the big boys. We have seen plenty of success cases and 
 networks with over 2K devices, or more during events, running just fine + 
 the play nice with Uniquity APs, which I think are unbeatable. Members 
 only 
 need to check in the first time they use a new device, we will remember 
 them from that moment on. Unlike  many of the ones we've worked with, 
 their 
 built-in scripting engine and events system makes it really easy to build 
 integrations with other systems without having to rely on the infamous 
 RADIUS!

 @Steve Suard. If you plan to build your own RFID tool, this reader 
  is 
 pretty reliable and comes with SDKs for a good number of programming 
 languages. Building a tool that reads a card and compares that to a local 
 database should not be too difficult, if you have access to a coder. That 
 ugly thing is the most reliable we've found out of the ones we have tested.

 @Sarah. There are plenty of options to facilitate check-ins when using 
 NX (front-desk ipads, desktop readers, door readers/access control, 
 wifi/network tracking, ...). A bit depends on budget, feel free to reach 
 out to discuss. This will also give you the basic options without going 
 into too much technical detail: 
 

Re: [Coworking] Re: How RFID reader writer works?

[Alex Hillman]

Neat, thanks Adrian!

Curious - do you know if it's possible to only do that authentication once?
Essentially, once a device's mac is registered, can the hotspot portal let
people connect without additional logins in the future, so long as the
device is known?


--
*The #1 mistake in community building is doing it by yourself.*
Better Coworkers: http://indyhall.org
Weekly Coworking Tips: http://coworkingweekly.com
My Audiobook: https://theindyhallway.com/ten

On Tue, Apr 18, 2017 at 4:09 PM, Adrian Palacios  wrote:

> Right! You somehow need to make that link between mac and member :). With
> UniFi, the simplest option is to enable the hotspot portal and redirect the
> authentication page to a server of your own. UniFi will send your server
> the MAC address of the member trying to authenticate and a few variables to
> let your server make sure the call is legit. You would then ask the user
> for their credentials (email, password,...?) and validate them against your
> member database. If valid, you would store the mac with the user in your
> database (that's the link between a user and the mac!) and send the user
> back to the UniFI controller letting it know the authentication was OK so
> they can connect to network, again with some magic to let Unifi your call
> is legit too.
>
> Attached an example of what your own sever would look like to get you
> going! Can't find right now where I got it from but it helped us crack this
> process.
>
> On Tuesday, April 18, 2017 at 8:45:07 PM UTC+1, Alex Hillman wrote:
>>
>> Adrian - yep, we've worked pretty extensively with the API, but that
>> doesn't *really* help tie a specific device's MAC address to it's
>> owners' account. Pretty sure that's where something like a captive portal
>> is needed, right?
>>
>>
>> --
>> *The #1 mistake in community building is doing it by yourself.*
>> Better Coworkers: http://indyhall.org
>> Weekly Coworking Tips: http://coworkingweekly.com
>> My Audiobook: https://theindyhallway.com/ten
>>
>> On Tue, Apr 18, 2017 at 3:42 PM, Adrian Palacios 
>> wrote:
>>
>>> @Alex, slight side-answer. Unify controllers have a great API that
>>> exposes every imaginable piece of data about connected clients and your
>>> network. Docs from Ubiquiti are pretty poor but this project
>>>  and its source
>>> provides a quick way to get started accessing that data
>>> https://github.com/malle-pietje/Unifi-API-browser. A small service
>>> reading event data or connected clients every a few minutes can easily be
>>> used to check members in and out.
>>>
>>> @Jacob Jay. We currently connect to a range of hotspot/captive portal
>>> devices, some of them incredibly capable. My personal favourite? Mikrotik.
>>> They are the underdog out of all of the ones we connect to but they have
>>> nothing to envy to the big boys. We have seen plenty of success cases and
>>> networks with over 2K devices, or more during events, running just fine +
>>> the play nice with Uniquity APs, which I think are unbeatable. Members only
>>> need to check in the first time they use a new device, we will remember
>>> them from that moment on. Unlike  many of the ones we've worked with, their
>>> built-in scripting engine and events system makes it really easy to build
>>> integrations with other systems without having to rely on the infamous
>>> RADIUS!
>>>
>>> @Steve Suard. If you plan to build your own RFID tool, this reader
>>>  is
>>> pretty reliable and comes with SDKs for a good number of programming
>>> languages. Building a tool that reads a card and compares that to a local
>>> database should not be too difficult, if you have access to a coder. That
>>> ugly thing is the most reliable we've found out of the ones we have tested.
>>>
>>> @Sarah. There are plenty of options to facilitate check-ins when using
>>> NX (front-desk ipads, desktop readers, door readers/access control,
>>> wifi/network tracking, ...). A bit depends on budget, feel free to reach
>>> out to discuss. This will also give you the basic options without going
>>> into too much technical detail: http://www.nexudus.com
>>> /en/blog/read/292950659/the-art-of-checking-members-in-and-out
>>>
>>> Adrian
>>>
>>>
>>>
>>>
>>>
>>> On Tuesday, April 18, 2017 at 7:24:31 PM UTC+1, Alex Hillman wrote:

 Slight side-consideration, but I'd be curious of accounts from anybody
 using *network access* to assist with check-ins/attendance?

 We have are using Unifi for our network management and the latest
 versions have a rather robust captive portal (sign in to get online) setup,
 but I haven't had a chance to play with it yet. Has anyone else?

 -Alex


 --
 *The #1 mistake in community building is doing it by yourself.*
 Better Coworkers: http://indyhall.org
 

Re: [Coworking] Re: How RFID reader writer works?

[Alex Hillman]

Adrian - yep, we've worked pretty extensively with the API, but that
doesn't *really* help tie a specific device's MAC address to it's owners'
account. Pretty sure that's where something like a captive portal is
needed, right?


--
*The #1 mistake in community building is doing it by yourself.*
Better Coworkers: http://indyhall.org
Weekly Coworking Tips: http://coworkingweekly.com
My Audiobook: https://theindyhallway.com/ten

On Tue, Apr 18, 2017 at 3:42 PM, Adrian Palacios  wrote:

> @Alex, slight side-answer. Unify controllers have a great API that exposes
> every imaginable piece of data about connected clients and your network.
> Docs from Ubiquiti are pretty poor but this project
>  and its source
> provides a quick way to get started accessing that data
> https://github.com/malle-pietje/Unifi-API-browser. A small service
> reading event data or connected clients every a few minutes can easily be
> used to check members in and out.
>
> @Jacob Jay. We currently connect to a range of hotspot/captive portal
> devices, some of them incredibly capable. My personal favourite? Mikrotik.
> They are the underdog out of all of the ones we connect to but they have
> nothing to envy to the big boys. We have seen plenty of success cases and
> networks with over 2K devices, or more during events, running just fine +
> the play nice with Uniquity APs, which I think are unbeatable. Members only
> need to check in the first time they use a new device, we will remember
> them from that moment on. Unlike  many of the ones we've worked with, their
> built-in scripting engine and events system makes it really easy to build
> integrations with other systems without having to rely on the infamous
> RADIUS!
>
> @Steve Suard. If you plan to build your own RFID tool, this reader
>  is
> pretty reliable and comes with SDKs for a good number of programming
> languages. Building a tool that reads a card and compares that to a local
> database should not be too difficult, if you have access to a coder. That
> ugly thing is the most reliable we've found out of the ones we have tested.
>
> @Sarah. There are plenty of options to facilitate check-ins when using NX
> (front-desk ipads, desktop readers, door readers/access control,
> wifi/network tracking, ...). A bit depends on budget, feel free to reach
> out to discuss. This will also give you the basic options without going
> into too much technical detail: http://www.nexudus.
> com/en/blog/read/292950659/the-art-of-checking-members-in-and-out
>
> Adrian
>
>
>
>
>
> On Tuesday, April 18, 2017 at 7:24:31 PM UTC+1, Alex Hillman wrote:
>>
>> Slight side-consideration, but I'd be curious of accounts from anybody
>> using *network access* to assist with check-ins/attendance?
>>
>> We have are using Unifi for our network management and the latest
>> versions have a rather robust captive portal (sign in to get online) setup,
>> but I haven't had a chance to play with it yet. Has anyone else?
>>
>> -Alex
>>
>>
>> --
>> *The #1 mistake in community building is doing it by yourself.*
>> Better Coworkers: http://indyhall.org
>> Weekly Coworking Tips: http://coworkingweekly.com
>> My Audiobook: https://theindyhallway.com/ten
>>
>> On Tue, Apr 18, 2017 at 2:18 PM,  wrote:
>>
>>> Ha, well, @Jacob J thanks for the vote of confidence, but I still only
>>> followed half of what you wrote in your most recent reply.
>>>
>>> We are quite low tech at the moment - handling our check-ins manually
>>> (yup, that's me, sitting at reception). I do like the daily fac-to-face
>>> with the members.
>>>
>>> I think that for now, getting the access issues at our second location
>>> is the most critical.
>>>
>>> Glad to hear Nexudus is so flexible. Will speak to them about options
>>> for automating the check-ins.
>>>
>>> As I learn more about all of the possible ways to automate, I know I'll
>>> come back to your post as it's full of good info.
>>>
>>> Much appreciated!
>>>
>>>
>>> On Tuesday, April 18, 2017 at 11:09:29 AM UTC-4, Jacob Jay wrote:

 Pretty much bang on, you've enough technical chops to distill the
 jargon ;)

 1. Yes. If a standalone script, you would have to maintain a separate
 list of IDs/names/expiries. (Inadvisable and extra work alongside a
 management app, but if one only has DIY offline management processes not so
 much an issue.)

 2. Yes. You can use an input/trigger such as an RFID swipe to do
 anything you want -- the output/action, in your case unlock a door (and
 maybe checkin). If we got fancier still you could turn the lights on, start
 a coffee brewing etc ;)

 I like and do agree with what Sayles says on the human interaction
 element however not all spaces have a full-time manager, nor necessarily at
 the door, and thus 

Re: [Coworking] Re: How RFID reader writer works?

[Adrian Palacios]

@Alex, slight side-answer. Unify controllers have a great API that exposes 
every imaginable piece of data about connected clients and your network. 
Docs from Ubiquiti are pretty poor but this project 
 and its source 
provides a quick way to get started accessing that data 
https://github.com/malle-pietje/Unifi-API-browser. A small service reading 
event data or connected clients every a few minutes can easily be used to 
check members in and out.

@Jacob Jay. We currently connect to a range of hotspot/captive portal 
devices, some of them incredibly capable. My personal favourite? Mikrotik. 
They are the underdog out of all of the ones we connect to but they have 
nothing to envy to the big boys. We have seen plenty of success cases and 
networks with over 2K devices, or more during events, running just fine + 
the play nice with Uniquity APs, which I think are unbeatable. Members only 
need to check in the first time they use a new device, we will remember 
them from that moment on. Unlike  many of the ones we've worked with, their 
built-in scripting engine and events system makes it really easy to build 
integrations with other systems without having to rely on the infamous 
RADIUS!

@Steve Suard. If you plan to build your own RFID tool, this reader 
 is 
pretty reliable and comes with SDKs for a good number of programming 
languages. Building a tool that reads a card and compares that to a local 
database should not be too difficult, if you have access to a coder. That 
ugly thing is the most reliable we've found out of the ones we have tested.

@Sarah. There are plenty of options to facilitate check-ins when using NX 
(front-desk ipads, desktop readers, door readers/access control, 
wifi/network tracking, ...). A bit depends on budget, feel free to reach 
out to discuss. This will also give you the basic options without going 
into too much technical 
detail: 
http://www.nexudus.com/en/blog/read/292950659/the-art-of-checking-members-in-and-out

Adrian





On Tuesday, April 18, 2017 at 7:24:31 PM UTC+1, Alex Hillman wrote:
>
> Slight side-consideration, but I'd be curious of accounts from anybody 
> using *network access* to assist with check-ins/attendance? 
>
> We have are using Unifi for our network management and the latest versions 
> have a rather robust captive portal (sign in to get online) setup, but I 
> haven't had a chance to play with it yet. Has anyone else?
>
> -Alex
>
>
> --
> *The #1 mistake in community building is doing it by yourself.*
> Better Coworkers: http://indyhall.org
> Weekly Coworking Tips: http://coworkingweekly.com
> My Audiobook: https://theindyhallway.com/ten
>
> On Tue, Apr 18, 2017 at 2:18 PM,  
> wrote:
>
>> Ha, well, @Jacob J thanks for the vote of confidence, but I still only 
>> followed half of what you wrote in your most recent reply.
>>
>> We are quite low tech at the moment - handling our check-ins manually 
>> (yup, that's me, sitting at reception). I do like the daily fac-to-face 
>> with the members.
>>
>> I think that for now, getting the access issues at our second location is 
>> the most critical.
>>
>> Glad to hear Nexudus is so flexible. Will speak to them about options for 
>> automating the check-ins.
>>
>> As I learn more about all of the possible ways to automate, I know I'll 
>> come back to your post as it's full of good info.
>>
>> Much appreciated!
>>
>>
>> On Tuesday, April 18, 2017 at 11:09:29 AM UTC-4, Jacob Jay wrote:
>>>
>>> Pretty much bang on, you've enough technical chops to distill the jargon 
>>> ;) 
>>>
>>> 1. Yes. If a standalone script, you would have to maintain a separate 
>>> list of IDs/names/expiries. (Inadvisable and extra work alongside a 
>>> management app, but if one only has DIY offline management processes not so 
>>> much an issue.) 
>>>
>>> 2. Yes. You can use an input/trigger such as an RFID swipe to do 
>>> anything you want -- the output/action, in your case unlock a door (and 
>>> maybe checkin). If we got fancier still you could turn the lights on, start 
>>> a coffee brewing etc ;) 
>>>
>>> I like and do agree with what Sayles says on the human interaction 
>>> element however not all spaces have a full-time manager, nor necessarily at 
>>> the door, and thus tech-driven solutions are needed. 
>>>
>>> 3. Yep. Darned humans, they can be too polite and don't know how to keep 
>>> their variables within a system's process bounds. 路‍♂️ 
>>>
>>> I would always advise making allowances for this, whether technically or 
>>> with backup/primary manager-driven interactions. Anything that introduces 
>>> potential frustration to a user is obviously a bad thing. I think WiFi as a 
>>> primary checkin system is better than RFID, but with RFID for access 
>>> control. WiFi can actually check people in even as their phone approaches 
>>> the main door. 
>>>
>>> 

Re: [Coworking] Re: How RFID reader writer works?

[Sarah McNamara]

We don't use that now, but Nexudus does have a feature that checks members
in via the WiFi. When the member comes into the space and logs into the
Wifi, they are checked-in.

I'm just reading about it now. Nexudus checks every 15 minutes and when
they are no longer online, they are checked out.

There's more to it than this, but that's the basics.

On Tue, Apr 18, 2017 at 2:23 PM, Alex Hillman 
wrote:

> Slight side-consideration, but I'd be curious of accounts from anybody
> using *network access* to assist with check-ins/attendance?
>
> We have are using Unifi for our network management and the latest versions
> have a rather robust captive portal (sign in to get online) setup, but I
> haven't had a chance to play with it yet. Has anyone else?
>
> -Alex
>
>
> --
> *The #1 mistake in community building is doing it by yourself.*
> Better Coworkers: http://indyhall.org
> Weekly Coworking Tips: http://coworkingweekly.com
> My Audiobook: https://theindyhallway.com/ten
>
> On Tue, Apr 18, 2017 at 2:18 PM,  wrote:
>
>> Ha, well, @Jacob J thanks for the vote of confidence, but I still only
>> followed half of what you wrote in your most recent reply.
>>
>> We are quite low tech at the moment - handling our check-ins manually
>> (yup, that's me, sitting at reception). I do like the daily fac-to-face
>> with the members.
>>
>> I think that for now, getting the access issues at our second location is
>> the most critical.
>>
>> Glad to hear Nexudus is so flexible. Will speak to them about options for
>> automating the check-ins.
>>
>> As I learn more about all of the possible ways to automate, I know I'll
>> come back to your post as it's full of good info.
>>
>> Much appreciated!
>>
>>
>> On Tuesday, April 18, 2017 at 11:09:29 AM UTC-4, Jacob Jay wrote:
>>>
>>> Pretty much bang on, you've enough technical chops to distill the jargon
>>> ;)
>>>
>>> 1. Yes. If a standalone script, you would have to maintain a separate
>>> list of IDs/names/expiries. (Inadvisable and extra work alongside a
>>> management app, but if one only has DIY offline management processes not so
>>> much an issue.)
>>>
>>> 2. Yes. You can use an input/trigger such as an RFID swipe to do
>>> anything you want -- the output/action, in your case unlock a door (and
>>> maybe checkin). If we got fancier still you could turn the lights on, start
>>> a coffee brewing etc ;)
>>>
>>> I like and do agree with what Sayles says on the human interaction
>>> element however not all spaces have a full-time manager, nor necessarily at
>>> the door, and thus tech-driven solutions are needed.
>>>
>>> 3. Yep. Darned humans, they can be too polite and don't know how to keep
>>> their variables within a system's process bounds. 路‍♂️
>>>
>>> I would always advise making allowances for this, whether technically or
>>> with backup/primary manager-driven interactions. Anything that introduces
>>> potential frustration to a user is obviously a bad thing. I think WiFi as a
>>> primary checkin system is better than RFID, but with RFID for access
>>> control. WiFi can actually check people in even as their phone approaches
>>> the main door.
>>>
>>> If you need, and how you implement such tech approaches is also down to
>>> size, smaller spaces probably don't need either if they're staffed because
>>> you know who's-who and can address them directly about renewals/usage.
>>> Large spaces really need both especially if managers are not always
>>> present. If you're mid-sized both could be nice and I understand given the
>>> apparent complexity why spaces haven't used both, but it's not unduly hard
>>> if you've got someone who can help. However no management app has the
>>> complexities figured out to result in a simple user experience in all
>>> scenarios. This is where the best practices/advice for models and
>>> approaches from other's here can be help, such as Sayles' recommendation
>>> for direct interaction, assuming they align with one's own resources.
>>>
>>> If access control is a priority then you can forget the WiFi. Whereas if
>>> you have hourly billing or a usage-based plan then WiFi is really required
>>> for accurate billing if the access control is loose ('door holding').
>>>
>>> Nexudus' own WiFi checkin involves installing a special router, which
>>> for two reasons I don't like: 1. it's not a particularly powerful one
>>> (although I haven't checked the latest models but I doubt they're as good
>>> as dedicated WiFi/routers which is after all at the crux of a space's
>>> service), 2. I despair at any system that requires users to login using a
>>> webpage especially when carrying multiple devices, let alone keep a browser
>>> window open. For ease of use WiFi should simply be password-protected and
>>> that's that.
>>>
>>> I implemented for myself an essentially opt-in simple WiFi script as a
>>> primary checkin system that only requires a user to signin a single time
>>> for 

Re: [Coworking] Re: How RFID reader writer works?

[Alex Hillman]

Slight side-consideration, but I'd be curious of accounts from anybody
using *network access* to assist with check-ins/attendance?

We have are using Unifi for our network management and the latest versions
have a rather robust captive portal (sign in to get online) setup, but I
haven't had a chance to play with it yet. Has anyone else?

-Alex


--
*The #1 mistake in community building is doing it by yourself.*
Better Coworkers: http://indyhall.org
Weekly Coworking Tips: http://coworkingweekly.com
My Audiobook: https://theindyhallway.com/ten

On Tue, Apr 18, 2017 at 2:18 PM,  wrote:

> Ha, well, @Jacob J thanks for the vote of confidence, but I still only
> followed half of what you wrote in your most recent reply.
>
> We are quite low tech at the moment - handling our check-ins manually
> (yup, that's me, sitting at reception). I do like the daily fac-to-face
> with the members.
>
> I think that for now, getting the access issues at our second location is
> the most critical.
>
> Glad to hear Nexudus is so flexible. Will speak to them about options for
> automating the check-ins.
>
> As I learn more about all of the possible ways to automate, I know I'll
> come back to your post as it's full of good info.
>
> Much appreciated!
>
>
> On Tuesday, April 18, 2017 at 11:09:29 AM UTC-4, Jacob Jay wrote:
>>
>> Pretty much bang on, you've enough technical chops to distill the jargon
>> ;)
>>
>> 1. Yes. If a standalone script, you would have to maintain a separate
>> list of IDs/names/expiries. (Inadvisable and extra work alongside a
>> management app, but if one only has DIY offline management processes not so
>> much an issue.)
>>
>> 2. Yes. You can use an input/trigger such as an RFID swipe to do anything
>> you want -- the output/action, in your case unlock a door (and maybe
>> checkin). If we got fancier still you could turn the lights on, start a
>> coffee brewing etc ;)
>>
>> I like and do agree with what Sayles says on the human interaction
>> element however not all spaces have a full-time manager, nor necessarily at
>> the door, and thus tech-driven solutions are needed.
>>
>> 3. Yep. Darned humans, they can be too polite and don't know how to keep
>> their variables within a system's process bounds. 路‍♂️
>>
>> I would always advise making allowances for this, whether technically or
>> with backup/primary manager-driven interactions. Anything that introduces
>> potential frustration to a user is obviously a bad thing. I think WiFi as a
>> primary checkin system is better than RFID, but with RFID for access
>> control. WiFi can actually check people in even as their phone approaches
>> the main door.
>>
>> If you need, and how you implement such tech approaches is also down to
>> size, smaller spaces probably don't need either if they're staffed because
>> you know who's-who and can address them directly about renewals/usage.
>> Large spaces really need both especially if managers are not always
>> present. If you're mid-sized both could be nice and I understand given the
>> apparent complexity why spaces haven't used both, but it's not unduly hard
>> if you've got someone who can help. However no management app has the
>> complexities figured out to result in a simple user experience in all
>> scenarios. This is where the best practices/advice for models and
>> approaches from other's here can be help, such as Sayles' recommendation
>> for direct interaction, assuming they align with one's own resources.
>>
>> If access control is a priority then you can forget the WiFi. Whereas if
>> you have hourly billing or a usage-based plan then WiFi is really required
>> for accurate billing if the access control is loose ('door holding').
>>
>> Nexudus' own WiFi checkin involves installing a special router, which for
>> two reasons I don't like: 1. it's not a particularly powerful one (although
>> I haven't checked the latest models but I doubt they're as good as
>> dedicated WiFi/routers which is after all at the crux of a space's
>> service), 2. I despair at any system that requires users to login using a
>> webpage especially when carrying multiple devices, let alone keep a browser
>> window open. For ease of use WiFi should simply be password-protected and
>> that's that.
>>
>> I implemented for myself an essentially opt-in simple WiFi script as a
>> primary checkin system that only requires a user to signin a single time
>> for at least their primary device. This approach could however be made to
>> require users to signin every new device. Maybe the management app devs
>> will improve their systems in time… otherwise we have to hack together our
>> own solutions using their APIs if we want better WiFi checkin.
>>
>> 4. This is down to the specific implementation of a RFID script/program,
>> personally I'd make it part-and-parcel to sync with a hosted app so that if
>> the net is temporarily down it keeps the last valid membership state for
>> each user to 

Re: [Coworking] Re: How RFID reader writer works?

[sarahatworkandplay]

Ha, well, @Jacob J thanks for the vote of confidence, but I still only 
followed half of what you wrote in your most recent reply.

We are quite low tech at the moment - handling our check-ins manually (yup, 
that's me, sitting at reception). I do like the daily fac-to-face with the 
members.

I think that for now, getting the access issues at our second location is 
the most critical.

Glad to hear Nexudus is so flexible. Will speak to them about options for 
automating the check-ins.

As I learn more about all of the possible ways to automate, I know I'll 
come back to your post as it's full of good info.

Much appreciated!


On Tuesday, April 18, 2017 at 11:09:29 AM UTC-4, Jacob Jay wrote:
>
> Pretty much bang on, you've enough technical chops to distill the jargon 
> ;) 
>
> 1. Yes. If a standalone script, you would have to maintain a separate list 
> of IDs/names/expiries. (Inadvisable and extra work alongside a management 
> app, but if one only has DIY offline management processes not so much an 
> issue.) 
>
> 2. Yes. You can use an input/trigger such as an RFID swipe to do anything 
> you want -- the output/action, in your case unlock a door (and maybe 
> checkin). If we got fancier still you could turn the lights on, start a 
> coffee brewing etc ;) 
>
> I like and do agree with what Sayles says on the human interaction element 
> however not all spaces have a full-time manager, nor necessarily at the 
> door, and thus tech-driven solutions are needed. 
>
> 3. Yep. Darned humans, they can be too polite and don't know how to keep 
> their variables within a system's process bounds. 路‍♂️ 
>
> I would always advise making allowances for this, whether technically or 
> with backup/primary manager-driven interactions. Anything that introduces 
> potential frustration to a user is obviously a bad thing. I think WiFi as a 
> primary checkin system is better than RFID, but with RFID for access 
> control. WiFi can actually check people in even as their phone approaches 
> the main door. 
>
> If you need, and how you implement such tech approaches is also down to 
> size, smaller spaces probably don't need either if they're staffed because 
> you know who's-who and can address them directly about renewals/usage. 
> Large spaces really need both especially if managers are not always 
> present. If you're mid-sized both could be nice and I understand given the 
> apparent complexity why spaces haven't used both, but it's not unduly hard 
> if you've got someone who can help. However no management app has the 
> complexities figured out to result in a simple user experience in all 
> scenarios. This is where the best practices/advice for models and 
> approaches from other's here can be help, such as Sayles' recommendation 
> for direct interaction, assuming they align with one's own resources. 
>
> If access control is a priority then you can forget the WiFi. Whereas if 
> you have hourly billing or a usage-based plan then WiFi is really required 
> for accurate billing if the access control is loose ('door holding'). 
>
> Nexudus' own WiFi checkin involves installing a special router, which for 
> two reasons I don't like: 1. it's not a particularly powerful one (although 
> I haven't checked the latest models but I doubt they're as good as 
> dedicated WiFi/routers which is after all at the crux of a space's 
> service), 2. I despair at any system that requires users to login using a 
> webpage especially when carrying multiple devices, let alone keep a browser 
> window open. For ease of use WiFi should simply be password-protected and 
> that's that. 
>
> I implemented for myself an essentially opt-in simple WiFi script as a 
> primary checkin system that only requires a user to signin a single time 
> for at least their primary device. This approach could however be made to 
> require users to signin every new device. Maybe the management app devs 
> will improve their systems in time… otherwise we have to hack together our 
> own solutions using their APIs if we want better WiFi checkin. 
>
> 4. This is down to the specific implementation of a RFID script/program, 
> personally I'd make it part-and-parcel to sync with a hosted app so that if 
> the net is temporarily down it keeps the last valid membership state for 
> each user to always let them in, and also the last swipe times to sync as 
> checkins with the app. 
>
> An "API" (Application Programming Interface) is a set of functions that 
> one application can use to talk to another, e.g. a local script/program to 
> a hosted management app. If the management app has a suitable function you 
> can invoke that function to get/set stuff. The Nexudus API is quite 
> comprehensive, and allows you to manage RFIDs, users, checkins and 
> apparently WiFi devices too so strictly speaking anything you want to do 
> could be integrated, and thus it appears one doesn't in fact have to use 
> the Nexudus WiFi checkin system but use one's own. 
>
> Such a 

Re: [Coworking] Re: How RFID reader writer works?

[Jacob Jay]

Pretty much bang on, you've enough technical chops to distill the jargon ;)

1. Yes. If a standalone script, you would have to maintain a separate list of 
IDs/names/expiries. (Inadvisable and extra work alongside a management app, but 
if one only has DIY offline management processes not so much an issue.)

2. Yes. You can use an input/trigger such as an RFID swipe to do anything you 
want -- the output/action, in your case unlock a door (and maybe checkin). If 
we got fancier still you could turn the lights on, start a coffee brewing etc ;)

I like and do agree with what Sayles says on the human interaction element 
however not all spaces have a full-time manager, nor necessarily at the door, 
and thus tech-driven solutions are needed.

3. Yep. Darned humans, they can be too polite and don't know how to keep their 
variables within a system's process bounds. 路‍♂️

I would always advise making allowances for this, whether technically or with 
backup/primary manager-driven interactions. Anything that introduces potential 
frustration to a user is obviously a bad thing. I think WiFi as a primary 
checkin system is better than RFID, but with RFID for access control. WiFi can 
actually check people in even as their phone approaches the main door.

If you need, and how you implement such tech approaches is also down to size, 
smaller spaces probably don't need either if they're staffed because you know 
who's-who and can address them directly about renewals/usage. Large spaces 
really need both especially if managers are not always present. If you're 
mid-sized both could be nice and I understand given the apparent complexity why 
spaces haven't used both, but it's not unduly hard if you've got someone who 
can help. However no management app has the complexities figured out to result 
in a simple user experience in all scenarios. This is where the best 
practices/advice for models and approaches from other's here can be help, such 
as Sayles' recommendation for direct interaction, assuming they align with 
one's own resources.

If access control is a priority then you can forget the WiFi. Whereas if you 
have hourly billing or a usage-based plan then WiFi is really required for 
accurate billing if the access control is loose ('door holding').

Nexudus' own WiFi checkin involves installing a special router, which for two 
reasons I don't like: 1. it's not a particularly powerful one (although I 
haven't checked the latest models but I doubt they're as good as dedicated 
WiFi/routers which is after all at the crux of a space's service), 2. I despair 
at any system that requires users to login using a webpage especially when 
carrying multiple devices, let alone keep a browser window open. For ease of 
use WiFi should simply be password-protected and that's that.

I implemented for myself an essentially opt-in simple WiFi script as a primary 
checkin system that only requires a user to signin a single time for at least 
their primary device. This approach could however be made to require users to 
signin every new device. Maybe the management app devs will improve their 
systems in time… otherwise we have to hack together our own solutions using 
their APIs if we want better WiFi checkin.

4. This is down to the specific implementation of a RFID script/program, 
personally I'd make it part-and-parcel to sync with a hosted app so that if the 
net is temporarily down it keeps the last valid membership state for each user 
to always let them in, and also the last swipe times to sync as checkins with 
the app.

An "API" (Application Programming Interface) is a set of functions that one 
application can use to talk to another, e.g. a local script/program to a hosted 
management app. If the management app has a suitable function you can invoke 
that function to get/set stuff. The Nexudus API is quite comprehensive, and 
allows you to manage RFIDs, users, checkins and apparently WiFi devices too so 
strictly speaking anything you want to do could be integrated, and thus it 
appears one doesn't in fact have to use the Nexudus WiFi checkin system but use 
one's own.

Such a script/program has to be always running watching for swipes, and 
whenever one occurs, attempt to connect to the management app API to 
validate/checkin the corresponding user. I've used these separate terms to 
differentiate between the locally-running script/program (on a controller 
board/PC) and remote hosted management app (on the cloud) but technically they 
can all be considered as 'apps'.

@Sayles offline sync is what you've already done for your own system? What was 
the issue with the Pi?

Sarah, there's a pile of such controller boards and they're not all compatible 
so when having a program written to do this, one has to make sure the hardware 
device ('board') is appropriate. There are however some that make it super 
simple and you can download apps from the 'cloud' to it with a click. So 
imagine if you simply ordered this controller 

Re: [Coworking] Re: How RFID reader writer works?

[sarahatworkandplay]

Jacob and Jacob,

Thank you both for your thoughts. 

First, you give me credit for being way more technically savvy than I 
actually am, so I only followed some of what you wrote :-).

What I took away was:

1) One can use an RFID card as the trigger to control the electric strike 
for the front (commercial) door, and each of those swipes can then be 
written to (at a minimum) a simple spreadsheet to log in who is coming in 
to our space. 

2) If we want to get fancy, we can have that swipe also connect to our 
check-in/check-out system, via some kind of hacked together, but not 
complicated program (well, not to someone who knows how to do these 
things). This is not possible with a code system that triggers the electric 
strike (Jacob J - do I have that correct?)

3) We can use that as our check-in-check-out mechanism, but it won't 
completely work if someone holds the door for someone else as they enter.

(I appreciate the pros and cons of a slowed down check in for the 
face-to-face time. Thanks, Jacob S.)

4) Even if we don't connect the swipes to the check-in/check-out process, 
we can use the log for back-up after hours if the simple spreadsheet log 
created by the swipes does not match the check-in/out system, as Jacob S 
described (or I think that's what you were saying). 

What I didn't quite follow is Jacob Jay's statement: " if your management 
app has an API (e.g. Nexudus), you can hack together a quick script to poll 
your own RFID reader and query/update that app."

We do use Nexudus, but what do you mean about polling the RFID reader and 
updating the app?

Also, if the coded system I'm looking at has an audit train and each user 
has a unique code, couldn't I still figure out who was in the space after 
hours when they forget to check-in/out (assuming the check-in/out is not 
hooked to the entry)?

Thanks so much! I'm a real newbie at all this, having just started working 
in a coworking space less than 2 months ago.

Sarah

On Monday, April 17, 2017 at 1:27:08 PM UTC-4, Jacob Sayles wrote:
>
> At Office Nomads we fully integrated our access control system with our 
> member management system (Nadine) although we chose not to use RFID for 
> checking in.  We've made it very simple to walk up to the iPad at the 
> front, find your name by first letter, and sign in.  Slowing down the 
> process has many advantages.  It gives us a second to say good morning and 
> chat a little bit, and we can display important information on the screen 
> like an expired credit card, or an upcoming event.  
>
> Where it is integrated is in alerting the team if someone came in on the 
> weekend, when we don't have staff, and forgot to sign in.  We then talk 
> with the member the next time we are all in the space and let them know 
> they need to sign in on the weekends as well.  Sure we could just sign them 
> in, but the human interaction is invaluable and there are many cases when 
> just using the door shouldn't result in a charge.
>
> As for the Pi, we did something similar to bridge the cloud gap although I 
> used a BeagleBone.  Same concept, but I've found the BeagleBone to more 
> stable in the long run.  I used a Pi to build a custom door controller for 
> a hotel down in San Francisco and it's not as robust as I'd like it to be.  
> Then again the Pi that runs our twitter alarm has been up for a few years.  
> Your milage may vary. 
>
> Jacob
>
> ---
> Office Nomads - Individuality without Isolation
> http://www.officenomads.com -  (206) 323-6500
>
> On Mon, Apr 17, 2017 at 6:56 AM, Jacob Jay  
> wrote:
>
>> Whilst PINs are easy, RFID is much more suitable, and a little plus is 
>> that you can let users scan an existing card instead of carrying an extra 
>> one (or remembering a PIN).
>>
>> Unfortunately I'm frankly surprised that nobody has apparently developed 
>> a solution that covers all the RFID use cases. Several of the hosted apps 
>> do have their own options for using RFID cards, Cobot for example 
>> integrates with PC-connected USB RFID readers for logging/checkin (
>> https://www.cobot.me/guides/rfid-swipe-card-check-in), and if your 
>> management app has an API (e.g. Nexudus), you can hack together a quick 
>> script to poll your own RFID reader and query/update that app.
>>
>> The most flexible system is to connect an RFID reader to a $20 
>> RaspberryPi board computer or similar which can even be embedded in the 
>> wall near a lock to control it too. This runs a small program ('script') 
>> that receives the card number, checks it (e.g. against a provided list of 
>> IDs, or by querying your hosted management app) and then (optionally) uses 
>> a relay also connected to the RaspberryPi to provide current to the lock. 
>> (It gets quite complicated if you have multiple doors.) At the same time as 
>> querying the validity of the ID it can of course also check the user in or 
>> at least log that they used the card at that time. Here's a (technical) 
>> example 

Re: [Coworking] Re: How RFID reader writer works?

[Jacob Sayles]

At Office Nomads we fully integrated our access control system with our
member management system (Nadine) although we chose not to use RFID for
checking in.  We've made it very simple to walk up to the iPad at the
front, find your name by first letter, and sign in.  Slowing down the
process has many advantages.  It gives us a second to say good morning and
chat a little bit, and we can display important information on the screen
like an expired credit card, or an upcoming event.

Where it is integrated is in alerting the team if someone came in on the
weekend, when we don't have staff, and forgot to sign in.  We then talk
with the member the next time we are all in the space and let them know
they need to sign in on the weekends as well.  Sure we could just sign them
in, but the human interaction is invaluable and there are many cases when
just using the door shouldn't result in a charge.

As for the Pi, we did something similar to bridge the cloud gap although I
used a BeagleBone.  Same concept, but I've found the BeagleBone to more
stable in the long run.  I used a Pi to build a custom door controller for
a hotel down in San Francisco and it's not as robust as I'd like it to be.
Then again the Pi that runs our twitter alarm has been up for a few years.
Your milage may vary.

Jacob

---
Office Nomads - Individuality without Isolation
http://www.officenomads.com -  (206) 323-6500

On Mon, Apr 17, 2017 at 6:56 AM, Jacob Jay  wrote:

> Whilst PINs are easy, RFID is much more suitable, and a little plus is
> that you can let users scan an existing card instead of carrying an extra
> one (or remembering a PIN).
>
> Unfortunately I'm frankly surprised that nobody has apparently developed a
> solution that covers all the RFID use cases. Several of the hosted apps do
> have their own options for using RFID cards, Cobot for example integrates
> with PC-connected USB RFID readers for logging/checkin (
> https://www.cobot.me/guides/rfid-swipe-card-check-in), and if your
> management app has an API (e.g. Nexudus), you can hack together a quick
> script to poll your own RFID reader and query/update that app.
>
> The most flexible system is to connect an RFID reader to a $20 RaspberryPi
> board computer or similar which can even be embedded in the wall near a
> lock to control it too. This runs a small program ('script') that receives
> the card number, checks it (e.g. against a provided list of IDs, or by
> querying your hosted management app) and then (optionally) uses a relay
> also connected to the RaspberryPi to provide current to the lock. (It gets
> quite complicated if you have multiple doors.) At the same time as querying
> the validity of the ID it can of course also check the user in or at least
> log that they used the card at that time. Here's a (technical) example of a
> slightly better setup like this with feedback LCD.
> https://www.hackster.io/nile-mittow/rfid-front-door-access-control-88d7cd
>
> The complexity of the script that acts as the controller for the RFID
> reader depends entirely on what it is being integrated with, how IDs are
> provided, and how you set feedback such as when expired. Pretty darned easy
> just to read and write to text/spreadhseet files though.
>
> The disadvantage of validating against a hosted application is that it is
> both slower to provide feedback/unlock which leads to a common scenario of
> multiple checkins or a checkin in followed by a checkout, and requires
> internet as mentioned by Matt. Both issues can however be avoided.
>
> For access control, most commercial door locks are fail-secure electric
> strikes which open/release when a current is applied to them (the buzz
> sound). Any system that grants access is simply arbitrating between an
> input (RFID/PIN) and the current to the bolt. Often such doors only have
> the access restriction on the outside with a simple release push button on
> the inside which gives current to the lock directly. Adding an additional
> controller or replacing one, is thus as simple as wiring the lock's current
> input cable to the controllers current output. Same principle is used with
> residential interphone systems.
>
> Unless not having 100% accuracy is fine, I think that an RFID checkin
> system when not also linked to access control is unhelpful, but even still
> if multiple people arrive at the same time one slips the door behind the
> other without swiping, you'd still need device/WiFi checkin to achieve 100%
> coverage.
>
> --
> Visit this forum on the web at http://discuss.coworking.com
> ---
> You received this message because you are subscribed to the Google Groups
> "Coworking" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to coworking+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
Visit this forum on the web at http://discuss.coworking.com
--- 
You received this message because you are subscribed to the 

[Coworking] Re: How RFID reader writer works?

[Jacob Jay]

Whilst PINs are easy, RFID is much more suitable, and a little plus is that 
you can let users scan an existing card instead of carrying an extra one 
(or remembering a PIN).

Unfortunately I'm frankly surprised that nobody has apparently developed a 
solution that covers all the RFID use cases. Several of the hosted apps do 
have their own options for using RFID cards, Cobot for example integrates 
with PC-connected USB RFID readers for logging/checkin 
(https://www.cobot.me/guides/rfid-swipe-card-check-in), and if your 
management app has an API (e.g. Nexudus), you can hack together a quick 
script to poll your own RFID reader and query/update that app.

The most flexible system is to connect an RFID reader to a $20 RaspberryPi 
board computer or similar which can even be embedded in the wall near a 
lock to control it too. This runs a small program ('script') that receives 
the card number, checks it (e.g. against a provided list of IDs, or by 
querying your hosted management app) and then (optionally) uses a relay 
also connected to the RaspberryPi to provide current to the lock. (It gets 
quite complicated if you have multiple doors.) At the same time as querying 
the validity of the ID it can of course also check the user in or at least 
log that they used the card at that time. Here's a (technical) example of a 
slightly better setup like this with feedback LCD. 
https://www.hackster.io/nile-mittow/rfid-front-door-access-control-88d7cd

The complexity of the script that acts as the controller for the RFID 
reader depends entirely on what it is being integrated with, how IDs are 
provided, and how you set feedback such as when expired. Pretty darned easy 
just to read and write to text/spreadhseet files though.

The disadvantage of validating against a hosted application is that it is 
both slower to provide feedback/unlock which leads to a common scenario of 
multiple checkins or a checkin in followed by a checkout, and requires 
internet as mentioned by Matt. Both issues can however be avoided.

For access control, most commercial door locks are fail-secure electric 
strikes which open/release when a current is applied to them (the buzz 
sound). Any system that grants access is simply arbitrating between an 
input (RFID/PIN) and the current to the bolt. Often such doors only have 
the access restriction on the outside with a simple release push button on 
the inside which gives current to the lock directly. Adding an additional 
controller or replacing one, is thus as simple as wiring the lock's current 
input cable to the controllers current output. Same principle is used with 
residential interphone systems.

Unless not having 100% accuracy is fine, I think that an RFID checkin 
system when not also linked to access control is unhelpful, but even still 
if multiple people arrive at the same time one slips the door behind the 
other without swiping, you'd still need device/WiFi checkin to achieve 100% 
coverage.

-- 
Visit this forum on the web at http://discuss.coworking.com
--- 
You received this message because you are subscribed to the Google Groups 
"Coworking" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to coworking+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Coworking] Re: How RFID reader writer works?

[sarahatworkandplay]

Matt,

We also use Nexedus, and are trying to work out access and check-in issues 
at one of our locations, so your answer caught my eye. 

To clarify, you are no longer using the RFID cards at all for check-in, 
correct, just the Nexudus app on the iPAD?

Also, this is only for checking-in, not for security in and out of your 
space?  (We have a glass, commercial door that probably needs a hard-wired 
key pad system, as the locks we use in our other location are too big for 
the glass door. I did some digging in old threads and saw that some people 
use the RFID cards for this purpose.) We need to solve both problems, and 
if we can solve them both with one solution, great, but two is okay as well.

Thanks!

Sarah


On Monday, April 10, 2017 at 9:36:42 AM UTC-4, Matt G wrote:
>
> Hey Steve,
>
> We use Nexudus as our member management system and it works wonders.
>
> Originally we used a cheap RFID scanner and cards to check in members. 
> Long story short you match enter the card details on the members profile, 
> and then when the RFID scanner is swiped, it types in the unique ID for 
> that member. We grabbed an old laptop donated to us, hid this behind a 
> panel on the wall, then  put the RFID scanner below a monitor with the 
> Check in screen on it so people could see the checkins of that day. 
>
> We had to hack a little to get rid of admin info on that page so that 
> sensitive data wasn't shown.
>
> The issue we had was that whenever our internet would drop (we did have 
> some connectivity issues at the time) as it is browser based, the browser 
> would then go to a disconnected screen which meant that the check in system 
> would be down until someone would boot up the laptop and get refresh the 
> page. This was a pain in the ass. 
>
> We now just use Nexudus's app on an iPad, and assign a 4 digit pin of the 
> members choice! Handy thing is that we don't have that drop out issue with 
> an ipad app.
>
> Hope that helps a little.
>
> Best,
>
>
> Matt
>

-- 
Visit this forum on the web at http://discuss.coworking.com
--- 
You received this message because you are subscribed to the Google Groups 
"Coworking" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to coworking+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Coworking] Re: How RFID reader writer works?

[Matt G]

Hey Steve,

We use Nexudus as our member management system and it works wonders.

Originally we used a cheap RFID scanner and cards to check in members. Long 
story short you match enter the card details on the members profile, and 
then when the RFID scanner is swiped, it types in the unique ID for that 
member. We grabbed an old laptop donated to us, hid this behind a panel on 
the wall, then  put the RFID scanner below a monitor with the Check in 
screen on it so people could see the checkins of that day. 

We had to hack a little to get rid of admin info on that page so that 
sensitive data wasn't shown.

The issue we had was that whenever our internet would drop (we did have 
some connectivity issues at the time) as it is browser based, the browser 
would then go to a disconnected screen which meant that the check in system 
would be down until someone would boot up the laptop and get refresh the 
page. This was a pain in the ass. 

We now just use Nexudus's app on an iPad, and assign a 4 digit pin of the 
members choice! Handy thing is that we don't have that drop out issue with 
an ipad app.

Hope that helps a little.

Best,


Matt

-- 
Visit this forum on the web at http://discuss.coworking.com
--- 
You received this message because you are subscribed to the Google Groups 
"Coworking" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to coworking+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.