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 <dangerouslyawes...@gmail.com>
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, <sarahatworkandp...@gmail.com> 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 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 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 a topic in the
> Google Groups "Coworking" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/
> topic/coworking/UlJzWZ1FbJ8/unsubscribe.
> To unsubscribe from this group and all its topics, 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 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.

Reply via email to