How RFID reader writer works?
104 views
Skip to first unread message
steve suard
Apr 10, 2017, 8:46:32 AM4/10/17
to Coworking
I want to add a tracking solution with RFID keyfob or card readers for members at the door entrance. I saw many affordable readers/writers using usb output for $20 on Ebay but there is no software to track member logs like how many time he logs in or set an expiration date so it bibs and staff will know that it's over for the membership.
Really lost!
I know that my gym club have a similar system and want that.
Something else I'm considaring is a PC keypad connected to a PC with a tracking software. Each member have a 4 digit code, when he types in before entering the coworking space, it BIPs a nice sound then track his log, if his membership expired it will bip another sound, Do you know where I can find this software that track members, manage and use a simple PC keypad? (saw this in another gym club)
Thank you
Really lost!
I know that my gym club have a similar system and want that.
Something else I'm considaring is a PC keypad connected to a PC with a tracking software. Each member have a 4 digit code, when he types in before entering the coworking space, it BIPs a nice sound then track his log, if his membership expired it will bip another sound, Do you know where I can find this software that track members, manage and use a simple PC keypad? (saw this in another gym club)
Thank you
Matt G
Apr 10, 2017, 9:36:42 AM4/10/17
to Coworking
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 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.
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
sarahatwo...@gmail.com
Apr 13, 2017, 10:42:01 AM4/13/17
to Coworking
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
Jacob Jay
Apr 17, 2017, 10:02:32 AM4/17/17
to Coworking
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.
Jacob Sayles
Apr 17, 2017, 1:27:08 PM4/17/17
to coworking
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.
--
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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
sarahatwo...@gmail.com
Apr 17, 2017, 8:51:52 PM4/17/17
to Coworking
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
To unsubscribe from this group and stop receiving emails from it, send an email to coworking+...@googlegroups.com.
Jacob Jay
Apr 18, 2017, 11:09:29 AM4/18/17
to cowo...@googlegroups.com
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.
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.
sarahatwo...@gmail.com
Apr 18, 2017, 2:19:41 PM4/18/17
to Coworking
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!
Alex Hillman
Apr 18, 2017, 2:24:31 PM4/18/17
to cowo...@googlegroups.com
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.
Weekly Coworking Tips: http://coworkingweekly.com
My Audiobook: https://theindyhallway.com/ten
--
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+unsubscribe@googlegroups.com.
Sarah McNamara
Apr 18, 2017, 2:42:56 PM4/18/17
to cowo...@googlegroups.com
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.
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+unsubscribe@googlegroups.com.
Adrian Palacios
Apr 18, 2017, 3:42:14 PM4/18/17
to Coworking
@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
To unsubscribe from this group and stop receiving emails from it, send an email to coworking+...@googlegroups.com.
Alex Hillman
Apr 18, 2017, 3:45:07 PM4/18/17
to cowo...@googlegroups.com
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.
Weekly Coworking Tips: http://coworkingweekly.com
My Audiobook: https://theindyhallway.com/ten
To unsubscribe from this group and stop receiving emails from it, send an email to coworking+unsubscribe@googlegroups.com.
Adrian Palacios
Apr 18, 2017, 4:09:32 PM4/18/17
to Coworking
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.
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.
Alex Hillman
Apr 18, 2017, 4:12:54 PM4/18/17
to cowo...@googlegroups.com
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.
Weekly Coworking Tips: http://coworkingweekly.com
My Audiobook: https://theindyhallway.com/ten
To unsubscribe from this group and stop receiving emails from it, send an email to coworking+unsubscribe@googlegroups.com.
Adrian Palacios
Apr 18, 2017, 4:18:04 PM4/18/17
to Coworking
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.
Alex Hillman
Apr 18, 2017, 4:19:34 PM4/18/17
to cowo...@googlegroups.com
Awesome. Great to know. Thanks Adrian!
------------------
The #1 mistake in community building is doing it by yourself.
Weekly Coworking Tips: http://coworkingweekly.com
My Audiobook: https://theindyhallway.com/ten
To unsubscribe from this group and stop receiving emails from it, send an email to coworking+unsubscribe@googlegroups.com.
Jacob Jay
Apr 20, 2017, 9:03:43 AM4/20/17
to cowo...@googlegroups.com
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…
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…
Reply all
Reply to author
Forward
0 new messages