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 <[email protected]> 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 > <https://github.com/malle-pietje/Unifi-API-browser.> 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 > <https://www.d-logic.net/nfc-rfid-reader-sdk/products/ufr-classic> 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, <[email protected]> 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 [email protected]. >>> 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 [email protected]. > 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
