QRstuv.info – SMB Visitor Kiosk

OVERVIEW

QRstuv.info is a SMB visitor kiosk, designed out of my desire to take advantage of QR codes, the efficiency of e-ink screens, and existing networked technology to create a practical solution for offices that may be short-handed or not set-up for regular visitors.

The kiosk design has a screen displaying a scannable QR code (as well as a physical button for those without mobile devices) to facilitate visitor check-in. The button is connected to a screen visible to office staff that would display a large, clear message that a visitor has pushed the button. This button would also be suggested for walk-in visitors who need to speak to someone immediately. The staff could turn off this light from a synced button on the screen.

When someone scans the QR code on the kiosk, it would take them to an online form that would have them fill out the reason for their visit as well as other information including as name, company, and comments. This information would be entered into a Google Sheet and a high-alert email would be sent to the appropriate department via a specific visitor email account—which could also serve as a visitor log. In the background, a script would be regularly checking the information in the sheet and push any changed info to be displayed on the screen at the appropriate employee’s desk.

Why QRstuv.info?

QRstuv.info is a product that stems from personal experience; having worked at an independent B2B organization with a window office near the front door, I know what it’s like to have people wander in with no clear receptionist. This solution would allow users to walk in and, through either scanning or the press of a button, be helped promptly by the appropriate person. This sounds like a little thing, but when you’re the one having to stop pricing a 10,000-item catalog to track down the warehouse manager, help like this would feel a godsend!

Process

Time-wise, though I had been planning and ordering parts for this project for weeks, I spent more than 24 hours over the course of 5 days working on the many aspects of this project–there’s a lot to it!

If you’ve never worked with e-ink screens, they’re very cool; however, when you start dipping your toe into anything deeper than the smaller, more popular displays, study up and brace yourself. (Props to Tom Igoe at NYU helping me with this; he, a certified pro, actually bought the same display so he could help… and even he ended up with a slight headache!) In the end, I spent a little over 7 hours getting the 4.2” e-paper screen to read from the data source spreadsheet and check for updates; the drivers can be the trickiest part. I also spent a good 10 hours getting the forms set-up and working (go ahead, zoom in and scan the QR code on the kiosk image below!…or just visit QRstuv.info) and another 5 hours connecting the breadboard to the screen and troubleshooting [mostly, troubleshooting.] Finally, I spent another 5 hours chasing rabbits on how to connect my HTML form to my Google Sheet… (and, ultimately, getting myself blocked from Scripts.) I also spent hours keeping and organizing notes of what worked and what didn’t… even knocking myself off-course a few times, accidentally confusing the keyboards for my Mac & Raspberry Pi and typing into parts of code I shouldn’t have.

I had a lot of fun. Don’t get me wrong, there was a lot of head scratching and sighing… and maybe a bit of French… but I really enjoyed getting the parts of this to interact and work. This project took me on a journey through multiple parts of the coding world—I revisited parts of PHP that I hadn’t touched in probably a decade and learned about a handy way to schedule processes called ‘crontab’. This project’s path also includes some: C++, Python, as well as HTML, JS, CSS and even a XBM file. (Not to mention a breadboard, a push button, couple of e-ink displays, an Arduino, a Raspberry Pi, a slew of jumper cables, and exponentially more web browser reloads.)

A Walk-Through

Let me take you on a walk-through with images to help explain. Again, the concept: A device that acts as a welcome kiosk for visitors to small businesses/offices that aren’t always able to keep an eye on the front door, or who might commonly find themselves with several visitors at once.

Here’s how it works. A visitor arrives to your office and no one is attending the front entry area. A visitor sees this:

The text of the Visitor Kiosk reads:

WELCOME!
We’re glad you came!

We’re multitasking at the moment, but if you’ll scan this QR code and fill out the linked form, one of our staff will be notified of your presence.(Just open your camera on your smartphone & point it at the code below.)

If you don’t have a smartphone with a camera,just press the green button on top of the kiosk and someone will be right with you!

Here’s a video I made of the button interaction:

If you have a device capable of scanning the QR code, you’ll be directed to a page like this:

From there, there are custom forms for the different types of Reason for Visit as well as thank you screens:

On the staff side, they would receive an email when the form is submitted… each type of submission going to a VIP email address that alerts the appropriate staff member of the visitor’s arrival.

The information from the form could also be added to a spreadsheet that, when updated, would refresh a screen with the relevant information. For example:

Here’s how I approached it:

Cool, huh?

Putting It Together

In terms of functionality, here’s what I got to work: I got the 4.2” e-paper screen to display information from a Google Sheet. I followed the tutorial from here and had to make some modifications. (Thanks for the great tutorial, btw!) It also involved setting up a Google Docs API account, which was fairly simple, and linking my key. The Python code works by getting the info from specific cells on the spreadsheet, storing them, then—the next time the code is run—checking the last cell info to the current cell info. If there’s a change, it updates the 4.2” e-paper display; otherwise, the screen doesn’t refresh.

I also got my html forms to work in terms of sending an email and collecting the info. I hadn’t used PHP in a long time, so there were several issues with getting the code to work. Unfortunately, local server testing doesn’t always equate to hosted web server functionality. Fortunately, I was able to make a few tweaks to the layout to get the results I wanted. I ended up moving the reason for visit to the first screen in hopes that I could use different fields on the next screens.

Ultimately, I made the fields the same because I was hoping to have the screen update from different visitor types. I left the Reason for Visit on the first page because having different pages not only makes the request for info feel more specific to the visitor, but it declutters the form page on the mobile device and—most importantly—allowed me to send visitors to pages with information specific to their type of visit.

I got the breadboard–which is where the physical push button comes in–to work with the screen, connecting the visitor information screen (visible to the staff) to the kiosk via p5 Serial Control. I had a hard time with the breadboard. I tried to get three buttons to light up three different lights. I trouble shot my code against the StateChangeButton example from the Arduino IDE, but couldn’t get multiple buttons with multiple lights to work—it could have just been due to over-used/faulty component parts, as I did a lot of tinkering in lockdown. I ended up rearranging my code but was only able to get one light/one button to work; of course, I made that one button the designated physical help button. (In reality, having a directly connected physical button is a good idea should servers—or other parts of the system—go down.)

Obstacles and Sticking Points

In terms of sticking points and such, my biggest obstacles were time and being able to connect the form (to the spreadsheet) to the 4.2” e-paper screen. With the spreadsheet, here’s what was going on: My code connected to the 4.2” screen reads from the same cells over and over again. I could probably fix that with (a lot) more time, but what it means is that using Google Forms to connect to the spreadsheet won’t work because I need the information in the cells to be overwritten instead of added to the new line below. (The advantage of the current code is that it checks to see if there are changes in the spreadsheet by checking it against what it recorded on the last check… and it only refreshes if there is different info.)

I searched for ways to connect my custom html pages to the form, but 1) there weren’t that many solutions, 2) the solutions that seemed to work added a new line—just like the form, and 3) I had to stop trying when I got locked out of scripts. *another sigh* Honestly, I assumed it would be WAY easier to connect my HTML forms to the Google Sheets. Part of the issue is that there are so many things to consider that I didn’t even think about the mechanics of Forms adding info to the next line of my Sheets document.

I also wanted to have the Arduino load different QR code image files depending on the time of day, but then realized that, if it’s doable, it’s not well documented. (That’s where the XBM file comes in… it was suggested as a way to be able to load images onto the Arduino, but I never got it to work. One of many rabbits I chased on this project.)

CODE

Regarding code, below are links to the different codes used in this project. I definitely relied on different sites, mostly blogs, to help me understand many of the concepts of how to make something like this work. I did not retype all of the code, but did go through all of it to make sure I understood it. I have to say that my plan was go to through and retype all of it, but I was really surprised by how much troubleshooting I had to do to adapt other projects to mine.

Here’s the link to the GitHub repo for the code I used.

Here is the link to the Python3 files I modified to connect my 4.2″ WaveShare e-paper display via Raspberry Pi to a Google Sheet!

For the push button on the Kiosk, I used code to connect using p5 Serial Control.

For the email forms via PHP, I followed this tutorial.

For getting my paper screen working, I used the information provided by WaveShare for the Raspberry Pi, but this was mostly for the drivers. I followed this tutorial for connecting the 4.2″ WaveShare e-paper screen to Google Sheets!

This tutorial helped me get up with the API needed for the project. Thanks, again!

Takeaways

Knowing all I went through to get here, I feel happy with what I was able to accomplish for this project. More than anything it was a reminder of how complicated, convoluted, and overwhelming so many of these technology interactions can be. You can have all the parts of the system working together in their ‘segment’ but, when you try to connect them, you realize your approaches are incompatible; much like when you go to connect parts of a Brio transit and realize the two pieces you were planning to connect have protruding parts…. there is a solution, but you’ve got to sort through things a bit to find it. Another big takeaway: diagrams totally help!

I’ll leave you with one of my little successes along the discovery path that made it all worth it…