I love the lengths it went to explain how to flash the microSD, connect the ribbon cable for the display driver board and then skipped over almost everything different and interesting about the project.
Only because of dead links to the case and RFID reader parts.
Otherwise, it's a fairly straightforward step-by-step setup guide. (Specifically for an IT person setting up the hardware terminal.)
The actual UI and backend are out of scope of the guide; the last step in the process is pointing the hardware at a web page that renders the UI and actually logs the punch-in and punch-out.
If I were deploying this, it makes sense - web devs and IT people can look at the main GH page to set up the backend and web app; and then they send this page to someone with only moderate technical skills to set up the hardware terminals.
Timetrack is a web application to handle an organization's employees' time keeping data. It is designed so that some employees will use their ID card to scan their clock-in and clock-out times. Others will be able to enter their time-in and time-out using the web interface directly. The system is designed to have two level approval process. The first is the group manager approval then the final approval is the director approval named 'Payroll Process Approval'. Currently the application handles two weeks pay period.
Edit: I started to wonder, isn't time keeping a solved problem with many commercial vendors and maybe even established open source? Why would a city roll their own? Does that make them more of a hack target (internally developed software weaknesses) or less (not being part of a monocoulture of zero-days)? What are their plans for long term (20+ years) maintenance?
City-of-Bloomington/timetrack is licensed under the GNU General Public License v2.0
The time tracking services and software I've worked with make their money by scaring employers re: regulatory compliance ("Subscribe to our service and we'll keep you legal w/ local HR laws...") or by making time tracking part of a larger suite of HR products.
> The time tracking services and software I've worked with make their money by scaring employers re: regulatory compliance ("Subscribe to our service and we'll keep you legal w/ local HR laws...")
This sounds interesting. Can you link to any of these services or software?
What do you mean by "scaring employers re: regulatory compliance"? "Scaring" reads like you're implying some kind of manipulation, but "regulatory compliance" is something a company should already be in; what is there to fear?
I can provide answers to the last two questions, based on my limited experence.
> What are "local HR laws"?
I think this refers to the fact that regulatory compliance is different depending on where your business is located. Which brings me to my anecdotal experience with:
> What do you mean by "scaring employers re: regulatory compliance"? "Scaring" reads like you're implying some kind of manipulation, but "regulatory compliance" is something a company should already be in; what is there to fear?
A company I worked for was located in a country where it was the legal duty of the employer to keep track of the people on the office premises. Most companies used a time tracking system for this, the punch-in, punch-out kind. The thing is, the purpose of the regulation was to make sure that when evacuated, there is always a list of people that were in the building - so it could be referred to after the evacuation to see if everyone is accounted for. This law did not require keeping track of the time someone entered the premises, or the time someone left - the requirement could be satisfied with a simple paper list with checkboxes - one for when you enter, one for when you leave. And that's exactly what was done in this office. Every month or two, the company got an offer from a business trying to sell a time tracking appliance or service, and many, if not all of those offers were using manipulatory tactics - "If you're not using a time tracking system, you might be violating the law" was a common phrase. The manipulation here was that it was true that a system like that would satisfy the legal requirement, but the offers strongly implied that a having a system like that was necessary to satisfy the legal requirement. Which was not the case.
> "If you're not using a time tracking system, you might be violating the law" was a common phrase.
This seems a reasonable thing to say. If anything it's helpful by perhaps providing the employer with information about requirements they were ignorant of.
> but the offers strongly implied that a having a system like that was necessary to satisfy the legal requirement. Which was not the case.
But coupling it with this is a sleazy sales tactic.
One can nullify the affect though by having at least one person on your staff tasked with being knowledgeable of all of your industry's employment requirements and your company's current state of compliance with them.
I don’t think it’s mentioned explicitly anywhere, but Bloomington Indiana is a college town and Indiana University has sought after computer science, informatics, business and public affairs programs.
I don’t know that this is the case, but I’d be surprised if this project didn’t have student involvement (aka cheap labor) that helped justify rolling their own.
Personally, I've had a few software engineering jobs in the past and the distribution of requirements for time tracking is basically bimodal:
* A company is legally required to do time tracking. They usually have a shitty excel sheet to fill out (and every fills in the defaults), or at best a single "check in"/"check out" button that someone coded 10 years ago and still works.
* A company does time tracking to bill 7 different customers for the 12 different tickets each engineer is assigned. The software used to track this was made by 30 full-time engineers and requires a 200-page manual to administer. New employees have to take a 2h course to understand how to fill in their time sheet.
Wow, I did not know this and am honestly a bit emotional finding this out. Those quarries were iconic and a magical way to spend an evening at a time in my life when I felt absolutely free, for better or worse.
On the bright side, Bloomington has other hidden gems (for now) that elicited similar feelings.
As someone who wrote an 2 attendance apps (in PHP and Rails) for my church, and a time-and-attendance app (with a checkin/checkout page) for a previous employer (which I've heard is still being used, many years later), let me say that I think there are 2 things at work here.
First, you can't underestimate the value of software that works EXACTLY like you need it to. At both my church and my job, the software I wrote did something very specific to those organizations, and NOTHING else. At the church, the key was making a great interface on a small device, and various people would use Palm Pilots to quickly and discreetly mark people as having attended. At the job, the key was in making the online form work exactly like the paper sheet that people had been filling out, and then making a single page for the person who did the billing, which had 2 pivot tables for time, one for employee hours, and one for customer project hours. Both systems were very fast, and you could do your thing in seconds.
Second, any T&A system you buy/rent is trying to be all things to all people, and violates the first point, which makes them hard(er) to use, and adds friction to your internal process. I think you'll see the problem if you rephrase your question like this: "I thought general ledger was a solved problem." It was. 40 years ago. And 90% of IT in the 90's was in customizing off-the-shelf systems to work like companies needed them to.
I work for one company, wholly-contracted to another. The first company uses Workday, which I guess is taking over the world now. It's perfectly awful in an expected way. The parent company has just written their own time tracking tool, and it's predictably terrible. It takes several seconds to click through each project number, and there's a lag on entering hours in each day. But, this is what you get when you're stuck in the outsourced, waterfall development mindset from 25 years ago. I expected nothing else. In my opinion, both of these decisions were the opposite of what needed to happen. My small consulting company should have used an internal resource or 2 to roll our own, and the mothership should have subscribed to Workday.
Yes, speaking with experience from a public K-12, timeclocks and timekeeping is an industry where $$ gets you something that claims to do everything but actually does nothing but fail or cause problems, $$$ gets you something that's stripped down total crap that can be made to work after modest concessions, and $$$$$$$$$ gets you something that does what you want reliably.
It's not hard, but everyone who can do it well has noticed what their competition is charging and followed suit.
I worked for a vendor that charged $$$$$$$$$. The software itself was often not the biggest cost component, it was what it cost to get it working in accordance with federal/state/local labor laws, any relevant union contracts, and company policy.
It was a complicated software package that did nothing out of the box and everything required significant configuration of the rule engine to account for the customer’s needs. It shipped with some building blocks for the rule engine but often/always required custom code to facilitate things the customer needed.
My job was to fly out to customer sites and perform the custom implementation tasks.
Worked in Higher Ed for years, we had a home grown time keeping system. Cost less for us to source and hack together physical time clocks and a web app than paying ADP, no question.
Time clocks are a terrible racket. The hardware is ridiculously overpriced, and most of of the units I've seen are tremendously low-tech (a microcontroller w/ a no-name serial-to-Ethernet or serial-to-Wi-Fi board strapped to it). They speak ugly undocumented binary protocols and, increasingly, are tied to ugly web-based hosted subscription services.
Often once it's established that X costs Y, it's very easy to just keep writing the check especially when it's probably not a huge expense relative to revenue and the risk of getting in trouble if the change goes wrong.
In this specific case, I worked with one of the large manufacturers (hi Khronos) and this is their customer: clocking-in is not your business, your business is selling something or running a hospital or whatever and clocking-in is a problem you that want to solve by writing a check. Not by hiring staff to set up or replace broken units (you generally pay a vendor for this) or adding any other overhead to your operation besides a check, and this is a service Khronos would love to charge you for.
Also on a human level, Khronos and orgs like them tend to have a good sales staff that are talented at knocking on the door. Lower-margin sellers can't afford to compete with the (expensive) talents of a good salesperson. Cisco is the gold standard of this behavior, there are almost always cheaper options that will work as well, but as they say, nobody got fired for buying IBM/Cisco and their sales reps skillfully deploy steak dinners and golf trips to IT execs with great success.
There's usually an underpaid employee who has to deal with the devise.
I dread the day where employees are required to wear "productivity" wrist bands, like the one Amazon patented.
I see it coming. The employers will know exactly where (gps), and what every employee is doing.
(The Fairmont Hotel wanted my father to carry around a pager. It was a directive from the Swiglets. (inside joke).
He kept droping it down the elevator shaft. They finally got the hint. They couldn't fire him because he was the only one who could reset the switch gear breakers after a hard rain. The breaker hot bars would bubble (thousands of volt amps) when flooded. My father would walk in the bubbling water to reset the flooded breakers. The only reason he wasen't electrocuted is because it was rain water, and luck. I belive the old hotel fixed the switch gear by now.)
I remember a doc/5 minutes segment 3-5 years ago showing employees with RFID chip under the skin to reduce friction when opening doors leading to restricted access and give access to printers.
And now that I think about it there's a comment of mine somewhere with a link to a line of connected motion sensors mounted in office chairs to "optimize lightning costs".
Identified needs – why to focus on office chair monitoring?
Data-driven managers love to monitor home officing, track work hours, save space and costs incurred by unoccupied desks when employees work away from an office or on flexible schedules
Companies are willing to avoid wasting money on lighting, heating, and cooling
Facility companies want to optimize cleaning services
There is a shift to working hubs, hot seats and a need for shared space utilization
I'm curious how an RFID reader works in a "not clunky" way since the application is delivered via a web browser. I'm assuming the RFID reader is just showing up as a virtual keyboard in this kind of setup.
Do the employees have to click on a form field before swiping their badge, etc?
Or maybe there's something like the RFID reader sending an unusual keycode that an event handler in the browser can wait for?
Focus can be set automatically in the desired field using Javascript, and tricks can be done to hide that field too - ie. set opacity so it's transparent, etc. You can make it work pretty smoothly for the end user.
Some of the original Yubikeys worked this way, and there are some barcode scanners out there that emulate keyboards too. I've seen some web based implementations go to great lengths to hide this fact.
Still sounds a bit clunky, as you would have people in line, and the page would need to smoothly be ready for the next person, deal with double-scans of the card, etc.
I'd certainly prefer something like un-typeable keycodes to listen for as start/end markers.
Presumably you know the length of the string generated by the barcode reader, so you just set the max length of the text field to that length, and/or ignore anything longer via JS.
> I'm assuming the RFID reader is just showing up as a virtual keyboard in this kind of setup.
I'm not affiliated with this project but built a few variations of the same thing several years ago.
Essentially, yes, you can configure these scanners in a keyboard mode such that they type the student id with a return. Just set up a simple form with focus on a text field, and reset after each submission.
One iteration I worked on used some other groups web form that wasn't design with this case. I just set up my Pis to automatically launch Firefox on boot, and wrote user script to browse the site and launch the form.
This was all built into the image so if anything ever went wrong, just write the image to a new SD card and reboot.
You can set up the scanners as to scan cards passively as well, but (the way I did it anyways) they won't decode the id when configured this way. Or maybe it was just more fun to reverse engineer it.
So, most barcode scanners operate in ‘wedge’ mode.
This may be true for RFID scanners, as well.
They emulate a keyboard and some have pass-through ports, for PS/2 keyboard interfaces.
For more ‘custom’ solutions, some also have serial interfaces, so they can be programmatically controlled to scan and read based on the logic you implement.
If there's an unusual keycode you need to start the process, maybe you could encode it into the start of the RFID string on the tag. Or maybe RFID readers are configurable like the barcode scanners I've worked with and you can program them to emit the keycode as a prefix.
Excellent. I think rasps could do a lot more if knowledge of them and basic programming was more common. Plus a ton of my *nix learning was rasp based since wiping an SD card is easier than having hardware & understanding for VMs.
I do wonder at use of SD card in any sort of production environment. I've got half a dozen rasps and a dozen+ sd cards...and well it's been patchy. Sometimes it lasts sometimes not with no obvious pattern.
I don't mind that SD card are slow AF, but really feel the rasp could have been taken to the next level with a better (reliability) storage solution.
Use it in read-only mode and have durable writes go to the cloud. Better, have all your software already packaged to the image you'll flash on the SD card.
I recently spent a little time at a company that used an embedded Pi in their product. It had to have a lot of data on hand that needed refreshing daily, with an unreliable network, so everything had to be local. Their biggest problem was SD corruption.
I worked at a retail company that had video screens up for each department saying who was working in that department now. Because of reasons, all the systems were the same - all the hardware across every machine in every store was the same make and model. Honestly... it was kind of an old machine. Hardware support was buying old hardware off of eBay for spare parts to keep things running.
We (some coworkers and I) back when RPis were becoming more mainstream (6... 7 years ago or so) of converting these systems to RPis. This would free up a dozen systems per store (about 3500 machines) and reduce power consumption per store from 70w/machine (estimate) to 5w/machine. So, lets go with round numbers.
Take that to 24h/day and you've got 17 kWh/day. $0.11/ kWh and we're at about $2/day/store... $600/day across all stores for the old systems and $40/day for RPis.
And that's not taking into consideration the hardware and the "ok, we keep a stock of a dozen RPis at each store with SD cards for the different departments and their configuration..."
Anyways... the company didn't go for it at the time. It was rather disappointing for us. It would have been a rather neat project that I still believe could have saved a good bit of money in just electrical costs (and more in hardware costs and longevity). I'm not sure if they've modernized that part of the stores since or if they're still scrounging eBay.
Big/old companies tend to get entrenched in their ways, I see this everywhere as a MSP, spouting idioms like "If it ain't broke don't fix it!" and "There's no need to reinvent the wheel".
Ten years ago I worked at a place that used single board DOS machines for clocking in and out. And this wasn't just at the beginning and end of a shift, this was every time they worked on a new batch of parts. It became very hard to keep these machines operating, you couldn't get spare parts for them anymore without scrounging other machines.
It was a medical device manufacturer, so it wasn't just company inertia holding them back - any change had to go through regulatory compliance. The company was in the midst of replacing their planning and tracking system when I left, and they've changed ownership twice, so I presume they've managed to replace those old systems too. I shudder to think of the problems they're having if they haven't.
I don't completely blame them... just disappointed. They had supply chain problems for their current computers (granted, their own making by not upgrading as time went on) and they were thinking "can we get 10k of these devices? They're all sold out currently... at best, we could get a few hundred, not enough to redo all the current stores if we were to go down this path."
This post couldn't have been more timely. I just bought my first RPI4 to test the feasibility of creating a dual monitor dumb terminal. Last year my small office went 100% remote. Now we want to bring a few people back on a part in-office/part remote rotation. The 'sever' machines are just people's ol desktops and laptops sitting on a wire shelf. Colleagues have used Win RDP to remote from their personal PCs into their Office PCs ('severs'). What do you do when people are in the office part-time? Move the PC to a desk and then put it back on the shelf when they go home so they can work remote tomorrow? YUCK.
That said, I hear PRI4 can boot off USB and it's faster than the SD card. At least that's my hope.
The Rasp hosting the creaky RFID Access system I hacked together for the local hackerspace (one of the first things hacked in the space) has been running on the same SD Card for I think 8 years now. Issues I've had with SD Cards ended up being due to me using subpar power sources for the Rasp, a mistake I have avoided making since.
I'm surprised there's no onboard storage option yet. I just got the Rasp Zero for a small build with a sensor and I've been super happy with the tiniest computer but I can't imagine they couldn't put storage on the board with a faster connection than the SD-card.
The Raspberry Pi Compute Module[1] has in-built storage. The downside of using the compute module is you need to plug it into a carrier card to breakout all the ports etc.
RAMdisks also help significantly with maximizing the write endurance of the SD card.
Specifically for log files, I use Log2RAM which has a RAMdisk that mounts /var/log, and then periodically (based on schedule, defaulting to daily) flushes it to /var/hdd.log/
I made similar units for my org to replace the old iPod Touch units, most of which were suffering from swollen batteries. The cheap touchscreens I used tend to only last a year or two but they're only ~$30 on Amazon. So far no SD cards have failed.
I finally looked at the article and that is bit over-engineered in my opinion.
My favorite timeclock had a two-row character lcd character display, membrane keypad for digits and maybe 5 additional function buttons: clock in, clock out, lunch in, lunch out, and admin-mode.
We used the last 6 digits of our SS# to clock in and out with.
It had a serial interface.
Use an Arduino, and you can add the serial display, keypad if needed, serial rfid or barcode scanner, and ethernet or wifi.
Added ISO 14443 to it via an unused internal USB port I found once I cracked it open. Got Dropbear SSH running on the embedded Linux it was using. I think I originally rooted it by removing its internal SD card and fooling with the file system.
I have a similar project I need to decide how to do, basically have the Pi host a website whose data is updated by tapping an NFC card.
I can’t tell what part of this code interacts with RFID, maybe it will give me some ideas of how to do it, is it all happening through writing events to a CSV that the web interface reads from?
The RFID readers I've dealt with show up as a tty (either an actual UART or something emulated over USB). Writing a small script to accept well formed input from the tty and then update your database, make an http request, or whatever is straightforward.
Just a little tip for the writer of the Article, give your employees their own touch-pen. Otherwise every employee will touch the exact same spot on the display...a big potential victory for Corona..or every other germ (had the same problem)
You can directly boot a Pi from USB now with the Pi 4. Switch to a SSD and you won't worry about SD card corruption as much. The bigger issue is that you need to cleanly shutdown any embedded system instead of just yanking or hard cutting power--flash memory and filesystems need time to sync. The Pi is no more or no less susceptible to this problem.
Also you're comparing to a tablet, a device with a _built in battery_ that prevents hard power loss in 99% of circumstances. Just because you press the power button on your tablet does not mean it is immediately cutting power to the device. If you add a battery backup and soft power switch to the Pi you would be just as reliable as a tablet. If you remove the battery from a tablet and hard cut the power, you can just as easily corrupt its flash memory filesystem.
Any serious embedded system should designed with minimal writable data: ro os and minimal writable data partitions. And at a minimum do manual syncs. Hopefully using a data storage system that in the worst case you lose a few records
Exactly this. It's why most companies QA departments specifically test pulling the power completely at critical times over and over to reduce the chance of it not booting.
Cell phones (at least androids), make lots of partitions to isolate user data and software upgrades, falling back to known good ones if the new software update doesn't run.
When swapping out the part requires having a technician drive out to a remote location, you bet it's a problem. Having a process stopped while this happens is a problem. The price of the part is almost irrelevant at that point.
Replace a ~$20 part with a ~$150 part, and you can avoid spending up to $1000 sending a repair crew, paying for the vehicle, gas, employee pay, time spent by them, etc. to a single unit.
You'd be lying through your teeth if you think a fleet of off the shelf raspis will last more than 5 years without most failing.
Anyone well versed in cost management within technology will know this.
As opposed to the existing systems that definitely don't fail more often than 5 years and definitely don't require tens of thousands in support contracts.
You're not "well versed in cost management", you're a sucker with buyers remorse for vendor bullshit.
Funny, do you have anything to back that up? Anecdotally, I have a 7 year old pi running my watering system and it hasn't skipped a beat in 7 years of being on 24/7. (current uptime is 1029 days).
I was going to post a similar response. From my direct experience all my Pi setups became corrupted within weeks or months. Admittedly it probably was caused by user turning off power mid-write or other preventable actions, but this is real life.
I'm excited to see the replies to your response that have some practical suggestions to prevent this.
What happens when one of these devices is admitted as trial evidence? Is there a hardware root of trust that can be used for cryptographic verification? Has anyone succeeded in doing trusted boot on a Raspberry Pi?
