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 board, plugged it in, had an
electrician connect a wire between it and your door lock and another to the
RFID reader, then that I said all you have to do is go to a webpage to enable
the app/script on it. Obviously said app needs to be written though…
*But* I haven't investigated the security implications of this cloud system and
indeed I wouldn't want such a board directly exposed to the net anyway. Your
insurers might'nt be too happy, although I'd be quite surprised if they'd have
clauses about such things yet…? Otherwise you'd need a local hacker who can
write/install the script/program directly on any controller board (e.g.
RaspberryPi, BeagleBone, Arduino, …).
HTH.
--
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 [email protected].
For more options, visit https://groups.google.com/d/optout.
