Categories
Uncategorized

MMPIS (Part IV)

MMPIS

See Also: MMPIS (Part I), MMPIS (Part II), and MMPIS (Part III).

During December’s “Space Improvement Workshop” at Milwaukee Makerspace I somehow convinced Chris to run a network drop for the permanent home for the MMPIS. This was after he convinced me to move the MMPIS to the permanent location. We both somehow convinced Tom to make a wall mount for the MMPIS. So yeah, the MMPIS is now permanently mounted in a location where you’ll see it when coming into the space. It’s right below the (small) LED sign, which is right below the big “TARDIS” letters.

It’s all pretty awesome. Check out the photo above! And yeah, we should probably drill a hole in the wall for those cables.

I also added one more screen. It’s a Mad Libs style thing which says “Hey, we should totally build a ________-powered ________ for the space!” with the blanks filled in with weird things from two different lists. Also, the challenge accepted guy is there to accept the challenge.

Here’s a few examples:

We should build...

We should build...

We should totally...

Let's build a...

Totally build we should...

There’s also a wiki page for the MMPIS.

Categories
Uncategorized

MMPIS (Part III)

Quote

See Also: MMPIS (Part I), MMPIS (Part II), and MMPIS (Part IV).

The MMPIS should also be somewhat whimsical. We like to be serious and safe at Milwaukee Makerspace, but we also like to have fun.

Buried in the deepest regions of the Milwaukee Makerspace wiki (actually it’s just in the ‘Miscellaneous’ section) is the quotes page. The quotes page is filled with insightful wisdom and… ok, many of the quotes are just amusing. At least to me, or other members.

Any member can get an account for the wiki, and therefore any member can add a quote to the page, and some have! I thought about scraping the page for quotes, but some are really long, and some I don’t find as amusing, so every now and I then I grab new ones I like and dump them into a text file. Then there’s a simple PHP page which reads in the text file, randomly grabs one, and outputs it. That’s what you see. (I’d share the code but to be honest if you’ve ever written any PHP at all, this should be a five minute exercise.)

Here’s a collection of some of my favorites. And yes, some of mine are in there, but they were added to the wiki by others, not me.

Quote

Quote

Quote

Quote

Quote

Quote

Quote

Quote

Categories
Uncategorized

MMPIS (Part II)

Info Screen

See Also: MMPIS (Part I), and MMPIS (Part III), and MMPIS (Part IV).

MMPIS is semi-related to reMMinderbot, in that it’s meant to actually provide helpful information. reMMinderbot lets us know (via email) when there is a meeting, or if we haven’t blogged in a while, or when the monthly cleanup day is coming. (It has to remind us of that twice! On Wednesday and Saturday before the actual Sunday we clean.) There’s lots of Perl and cron involved in reMMinderbot.

reMMinderbot is also supposed to send an email telling us what’s on the calendar each day. This occasionally works. I’ve been writing code to deal with calendars for way too long. It’s sort of a nightmare. The iCalendar format is best described as Wibbly Wobbly Timey Wimey.

There’s an old saying:

Some people, when confronted with a problem, think “I know, I’ll use regular expressions.”
Now they have two problems.

Parsing iCalendar files can be like that. Luckily, Perl has a module for everything! So iCal::Parser was pulled into service. Unluckily, it has bugs. iCalendar can be tricky. There are repeating events, but they can have exceptions, days they don’t actually happen. I’ve seen weird time zone issues, and differences between clients. Anyway, it’s all wibbly wobbly.

Our original Perl code grabbed the calendar file from Google, parsed the file, and then output the upcoming events to a file that is then included in the main page. As I said, though… it doesn’t always work. So I decided to scrap it.

In an ideal world, we would just clone the calendar page on the web site and display that. There’s just way too much Javascript on that page though, and it takes too long to render. I then remembered a web application I used years ago, so I turned to PHP iCalendar.

PHP iCalendar

PHP iCalendar manages to display things properly! All events revealed! Though the monthly view is not what I want. Nor is the daily or weekly view, but… At the bottom is a “This Month’s Events” section. We can use that!

List of Events

I took the files that showed the monthly view and started hacking. I stripped out the unneeded HTML, edited the CSS to get what I wanted, and it was pretty close, but… it was just displaying the current month’s event. This would mean that if there was an event on the first of the month, you’d never see it until the first of the month, which is silly. Digging through the PHP it was just a matter of changing things to look at the current month and the next month. Not 100% perfect, but an acceptable solution.

Right now it’s looking two weeks ahead, so you’ll get any event for the next 14 days. This is what you see below.

MMPIS Events

I may play around with setting the viewport to be 1920×1080 and then using overflow: hidden to better use the space on the screen, but I’ve also got the issue that I’m doing development on a 1280×720 screen, so I may need to do some CSS stuff depending on the screen size, if that’s even possible. (Also, to pick a nit, the resolution of the TV I am using today says it is displaying 1360×768.)

Anyway, the PHP iCalendar solution has been working so good I’ll probably roll it into reMMinderbot’s calendar code. It’ll take a bit of Perl-fu to do the right thing there (multiple servers are involved) but it should be a major improvement. (Hopefully.)

What’s that? You can’t wait for Part III? It’s coming…

Stay Tuned!

Categories
Uncategorized

MMPIS (Part I)

MMPIS

See Also: MMPIS (Part II), MMPIS (Part III), and MMPIS (Part IV).

I typically write about a project after it’s done, but I thought I should turn that around and start writing about a project much closer to the start. So here’s Part 1 of the story of the MMPIS, the project more formally known as the Milwaukee Makerspace Pi-powered Information System, which is a kiosk at the makerspace which will provide members (and guests) with useful (and silly) information.

First, the name… We have a history of naming things with acronyms and/or using an many “M”s as possible, such as: HMMMMMM, M6 (Milwaukee Makerspace Morgifying Marble Manipulation Machine), M4 (Milwaukee Makerspace Maker Mobile), reMMinderbot, M2C2 (Milwaukee Makerspace Can Crusher), MMLC (Milwaukee Makerspace Lighting Controller), and of course, BADASS (Beer Automated Dispensing And Security System). I choose MMPIS because it’s fun to say. I nearly went with MMKIS (Milwaukee Makerspace Kiosk Information System) but unless I’m outvoted, I’ll probably stick with MMPIS.

I’ve long had an interest in digital signage and kiosks, so after my recent Sir Like-A-Lot project, I felt like pursuing a kiosk for the Makerspace. We had a Raspberry Pi that had been floating around waiting for a project, and there’s a huge TV that jason g. brought in that we used only occasionally. Those two pieces and a few other things were all it took. Well, that and writing some code.

The heavy lifting is all provided by Screenly, and actually, it’s the Open Source Edition of Screenly. (Also on GitHub.) Screenly is a pretty nice open source kiosk application. I’ve discovered a few bugs, and have some feature requests, but it definitely works. I’ve been meaning to check out Concert and Xibo as well, but I’ve not dug into those yet.

The first group of screens is pretty simple, here’s a few grabs.

Info Screen

Here’s the main screen (for now) which tells you where you are (duh!) and shows the date and time. It also tells you where to park, has a quote from the wiki, and shows the upcoming events. Well, some of them. We’ll get into that in Part II.)

Park!

We’re also showing our Parking App to let members know which side of the street to park on. (This, as every other screen, may change in the future.)

HMMDMMH

We’ve also got our How Many Members Does Milwaukee Makerspace Have? page. The HMMDMMH page uses our member management software to let us boast about this impressive number.

What's Cookin'?

Prepare Thyself for Making

The last two are just graphics that live on the Pi that runs Screenly. All the others are web pages out there on the big old Internet. Oh, I should note that the pages need to be fairly simple. Large, complex pages utilizing Javascript or other heavy lifting don’t do very well, due to the lightweight nature of the Raspberry Pi and the browser Screenly uses.

OK, that’s our intro to the MMPIS. In the next installment we’ll get into the events that the MMPIS shows, or should show.

Stay Tuned!

Categories
Uncategorized

Sir Like-A-Lot

Sir Like-A-Lot

My latest project was sort of a failure, but I’m going to post about it anyway, because such things are important.

For a recent event I wanted to create a unique way for people to LIKE something, and get a reward for it, so I grabbed a Raspberry Pi and got to work. The idea was pretty simple, a full screen display showing the number of Facebook likes, with the URL for people to visit the page (on their mobile devices) and like it. The display would then update in “near” real-time (Well, every 10 seconds) and there would also be a surprise…

Step #1 is always configuring the Raspberry Pi. I installed Raspbian, had it set to boot to the desktop, and installed the packages I needed, mainly Apache and Chromium, since I’d be using a local web server and web browser for the display.

Getting the Raspberry Pi to work as a kiosk display was next. I didn’t want any menus or OS parts showing, so I used Chromium running in kiosk mode. My /etc/xdg/lxsession/LXDE/autostart file looked like this:

# config to launch Chromium in kiosk mode and load our application
@xset s off
@xset -dpms
@xset s noblank
@chromium --kiosk --incognito http://127.0.0.1/likealot/

We got rid of the part that lets a screensaver run, and added in the bits to fire up Chromium in full-screen kiosk mode. (Oh, one note about Kiosk mode, it does not hide the mouse pointer, but we’ll deal with that later.)

LIKES

The results on the screen looked like this. Full screen, no browser or OS bits showing. I like this solution as it can be used for pretty much anything you can code up as a web page.

The display is set to refresh every 10 seconds, so it’s pretty up-to-date, and you’re really only limited by what you can display in a browser (Chromium) running on Linux (on a Raspberry Pi, in this case.)

As for the code, it’s less than 50 lines of Perl running as a CGI, and about a dozen lines of HTML in an HTML::Template file. There’s also a little CSS and an image.

Speaking of the CSS, it was the solution to hiding the mouse pointer for Chromium running in kiosk mode. I just added this bit:

/*
 * using CSS to hide the pointer
 */
* { cursor: none !important }

For an informational kiosk you just want people to look at and not have to interact with using a mouse or keyboard, this solution works well.

JSON

You might be saying “Hey! How do you get the number of likes!?” Well, you just ask JSON, or http://graph.facebook.com/?ids=z2marketing to be more precise. Facebook Graph API data holds the key, you just need the value.

Oh, there was one more really fun bit! When someone liked the page and the page refreshed and the number increased, you’d hear applause!

The original idea was to just have the CGI do a system call to play the file using aplay. That did not work. I also tried mpg321 and that didn’t work. In the end I went the other way around and added… another Perl script! There’s a cron job that runs on startup, which launches a Perl script, which loops forever and looks at the counter file that the CGI uses. Every time the counter file changes (due to the CGI updating the number) the Perl script uses aplay to play the applause file.

The end result is pretty good. A person sees the display, goes to Facebook, likes the page, and within 10 seconds the display updates and you hear some applause!

I planned on making a sign or adding some text to entice people take action and get a “reward”. And of course the URL isn’t as helpful on a mobile device where you probably use an app instead of a browser, but this is all a good start.

Now, I mentioned a failure, so I should explain that part. For anything like this, where it needs to run for hours reliably and not just be a quick technology demo, you need some burn-in time. I had this running for a week with no issue. The first issue that came up was, what to do if you lose the Internet connection. (Hey, we use Time Warner, it happens!) You really don’t want to see a default Apache 500 error page, so the error page looked just like the main page, but with a message that said ‘Please stand by…”. That 500 page was set to redirect to the main page after 10 seconds, which would deal with occasional Internet or network outage situations. Since we were also using a WiFi connection with the Raspberry Pi, there’s always the chance of losing the WiFi connection. This didn’t seem to happen much, but it’s something you may need to deal with.

I also set Apache to not do any logging, as there’s really nothing valuable gained from logging after you’ve got everything running. It also helps to write less data to the SD card that holds the system because… corruption.

Oh yes, corruption! Every now and then I would reboot the system to make sure it would start up properly. It almost always did. Except when it didn’t. Once the Pi booted and there was a warning that the file system needed repair, so I repaired it, and all seemed well. I tested again for another week, and things seemed good. But then…

The day of the event, I had to move the system into place, and when I did that, and started it up, Linux would not boot. Even after 13 years I am still not enough of a Linux expert to fix every problem it throws at me, and I was stuck, and had a dozen other things to do, so it was dead.

I did the dozen other things and then ended up reinstalling Raspbian and trying to quickly reconfigure it, and get all my files in place, and got everything working except the audio… and the WiFi. There are a few tricks to getting audio working properly on the Raspberry Pi. I eventually got it working, but it was too late to deploy it. Oh well…

So next time, I will have a BACKUP SD card ready to put in place when the first one destroys itself. Or maybe I’ll just build two complete Raspberry Pi systems. Backups are good. Backups are good. Backups are good.

But don’t worry, I’ll take all the successful bits of this project and re-implement it in some other way in the future.