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 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.
