Oh man, where to begin on this one? I guess I'll start by saying that as I'm writing this, the menu board isn't 100% there. I'm still working through some bugs on the Arduinos/WiFi Shields. If you're not sure what an Arduino is, picture it like a really tiny computer you can only program to do one thing at a time. It doesn't have too much memory either, so it can't do anything too complicated.... A WiFi shield just connects the Arduino to the Internet (kinda, you still have to do a little programming to get it to work).

But, before I get too far into the adventure this menu board has been, let me start with why it exists. For that, I'm going to tell a story. Here it is:

Hemstreet walks into a barbershop+clothier. He is immediately welcomed by a friendly Spruce team member, "Welcome, what can we do for you?"

He grabs his toothpick and moves it to the other side of his mouth, "How long 'till the next cut and style consultation?" 

Everyone in the shop points at the menu board.

FIN

Well, so, that isn't how it started, but you can see how much better that is than the way it was. You see, everything at Spruce is cell phone driven. We have a special teammate mobile web app everyone uses. They can book appointments, invite people to the system, see upcoming appointments, review profiles, take notes, take photos, it even syncs with the calendar on their phone.

What would happen is as soon as someone walked in we would have to whip out our phones to look up next available time. You could even check from our iPad. But, it was never close. This wasn't too bad all things considered. At most modern appointment/reservation based establishments you have someone on a computer telling you wait times and taking reservations (think host at a restaurant)

But, on a phone, you're probably doing other things, so when someone walks in you have to switch between apps. Then, once the app was focused, you'd have to wait a second or two for the numbers to refresh. All in all, it took way too long.

By having the wait times big and visible, we can cut down the time to answer, "How long till the next appointment?" from 5-10 seconds to almost nothing. Way better, right?

So, now that we have that out of the way, lets talk about building this sucker. 

Building this sucker

Immediately I knew we were going to need help creating the art for the board itself. Not only did we need someone who was a good artist, but it was crucial that we work with someone local. One thing I know is that the creative process is tightly coupled to proximity and in order to really do your best work with someone, you often times have to be in the same room as them. Luckily, a quick Google search introduced us to the Chalklatier.  He's local, an amazing artist, and as a bonus, already technically inclined! Here is a standing arcade he and some friends built a few years ago. Needless to say, we found our man!

More on the tech

Right from the start I pictured this thing with the 7 Segment LED displays. I knew the big question was going to be feeding data to so many displays. Luckily, a hardware hacker friend pointed me towards I2C. Once I had a direction, I found a tutorial on how to connect and configure a bunch of displays at once. 

After configuring all the I2C backpacks on the LEDs we knew how many Arduinos we would need (hint, the answer is 2). So, off to Micro Center to grab some hardware!

A note about Micro Center

I hate this place. Are they all as poorly put together as ours? I feel like a few people decided they thought electronics were fun and that having a company would be neat, so they rounded up a bunch of money, leased a building, threw a crap ton of stuff on shelves, in buckets, even all over the floor, then offered jobs to a bunch of people who hate electronics. Seriously, how is this place in business still? Probably because there is no other alternative. There should be. Do yourself a favor, reserve online before you head in. Otherwise you'll be lost in a sea of unhelpfulness!

The Arduinos

So, I started off with two Wildfire Arduino boards with integrated WiFi. One of them worked perfectly, the other... not so much. I looked around and found that people were having issues with the cc3000 and freezing. More on that later... 

My strategy for getting this whole thing working was pretty simple. Firstly, because our appointment system uses SSL and Arduinos do not support secure requests, I knew I was going to need to somehow securely connect to the system and then in an unsecured manner send the wait times to the Arduinos. Enter RaspberryPi! We already had a RaspberryPi powering our sign so most the code we needed to make this work was mostly finished.

Now, the Pi has a static IP. When each arduino boots it'll get a new IP. So, when an arduino boots, it'll send a string identifier to the Pi and from nodejs I get some information about the arduino (including IP).

Once the arduinos have reported their ID and IP, I send a pipe "|" separated string to each Arduino. In-between each pipe was going to be a wait time (in minutes) for a particular service. Then, it was just a matter of parsing the string on the Aurdiuno and sending the numbers to the LEDs to be displayed. The only tough part was that I had to make sure the numbers were sent in an order that corresponded with the LEDs, i.e. the first wait time got sent to the first LED, so that number should actually be for whatever services the LED is posted under.

Sounds easy and straight forward enough, right?

Launch Day

It's t-minus 7 hours... By the time we had the whole thing 95% put together it was already the day of our first IoT meetup. We had about 68 people RSVP'd and I really wanted to have this thing ready for them. Also, I'm deadline driven, so I knew that setting this event as the official unveiling would force us to stick to our schedule.

It seemed like every time we hung the board and tested it, it would not work. Times were showing, not updating, but also seemingly out of order... it was extremely frustrating. T-minus 30 minutes and we decided we need to take the broad down to check it one more time.

People started walking in.

Steven and myself pulled it down to check the connections one last time. After some minor tweaks, we hung it back up and plugged it in.

And waited....

The way I had the ardunios programmed, they assumed the RaspberryPi was already booted. But, because the Pi boots slower, the arduinos needed to be restarted once the Pi was up.

I reached around the back of the menu board and hit the reset switch on each arduino...

They booted.

Reported their IP's.

It worked!

Check out the photos from that night.