Music in motion: a Firebase and IoT story

One of the best parts about working at Google is the incredible diversity of interests. By day, I’m a Developer Advocate focused on IoT paid to write code to show you how easy it is to develop solutions with Google technology. By night, I’m an amateur musician. This is the true story of how I combined those two interests.

It turns out I’m not unique; a lot of folks here at Google play music on top of their day job. Before I started working here, a Googler decided that we needed a place to jam, and thus was born one of our legendary Google perks: Sound City, a soundproof room in the middle of our San Francisco office. It’s an incredible space to jam, with one catch. You can’t book the room during the day. Anyone can go in and play at any time.

This was done for two reasons: to give everyone an opportunity and to foster the magic that sometimes happens when a random set of musicians ends up in the room at the same time, resulting in a jam of epic proportions.

Some of us, however, are not yet the musical gods we aspire to become. I picked up accordion recently. Finding time to practice at home is tough as it’s not the kind of instrument you can practice after the kids go to sleep. Having access to a soundproof music room in which to practice is awesome, but I don’t necessarily want to play when other people are in the room. I don’t want to subject anyone else to my learning of the accordion. That would just be cruel.

I brought this up to the folks that run the room, and suggested putting in a camera so we can see what’s going on in the room. They said that this came up usually once a year. Folks pushed back, because no one wanted to be watched while in the room. Sound detection in the room has the same problem. If something can pick up sound, it could theoretically record sound so folks vetoed it.

Being one of the IoT device folks at Google, I asked if anyone had considered just setting up motion sensors, and having it update a page that folks could look at. A lot of staring and blinking later, my idea was passed around to the folks that run Sound City and I got a thumbs up to go for it. So now I just needed to create a motion sensor, and build a quickie webpage that monitors the state of motion in the room for folks to access.

The setup 

This little project allowed me to tick all kinds of fun boxes. First, I 3d printed the case for the Raspberry Pi + Passive Infrared sensor (PIR). I took an existing model from Tinkercad, and modified it to fit my design. Using their tools I cut out an extra circle to expose the PIR, and extruded the whole case model. The end result worked great. I had plenty of room for the Pi + PIR (and added an LED to show when motion is detected to make it easier for me to debug).

The next step was to set up my data destination. For ease of setup and use, I decided to build this on Firebase, which makes it super easy to set up a real-time database. Like all things popular and open, there are several Python libraries for connecting and interacting with Firebase, including the Google supported Firebase Admin SDK. From a previous project, I had experience using a library called pyrebase, so I stuck with what I knew.

Creating a Firebase project is easy: from the console literally just add a project, give it a name and POOF, you’re done. Note that if you already have a GCP project, you can totally just use that. Just select the project from the dropdown in the Add Project dialog instead. I went ahead and created a project for the music room.

There’s a lot of fun stuff in here to play around with if you haven’t looked at Firebase before. For my purposes, I wanted to use the real-time database. First things first, I grabbed the JSON web config to work with my project. Clicking the “Add Firebase to your web app” button from the project overview home page gave me a hunk of code like so:

I copied that to the clipboard; I will need it later.

Next up, I needed to protect the database properly. By default, the read/write rules require a user to be authenticated to interact with the database. This was perfect for ensuring that only my device could write to the database, but I also wanted to read the state from my webpage without having to authenticate with the database. I clicked the Database on the left to get started and then clicked the Rules tab to see the default rules for the database:

To allow anyone to read from my database (important safety tip, do NOT do this if the data is at all sensitive), I changed the rules to the following:

Firebase supports a bunch of rules you can apply to database permissions; click here if you’re curious.

Next up, authentication! There are a few different ways I could have managed this. Firebase allows for email/password authentication, but if I did it that way, then everything is tied to an email, and that becomes unwieldy from a user-management perspective if someone else needs to administer things, or make changes.

Another approach is to use GCP service accounts, which Firebase honors. Now, I won’t lie, service accounts are not the easiest things to wrap your head around as there are a LOT of knobs you can turn permissions-wise in GCP/Firebase. Here’s a good primer on service accounts if you’re interested in knowing more. I may need to write or find a good blog about service accounts at some point too. If you do go down this route, when you create the service account, be sure to check the box that says “Furnish a new private key”. There may be a message saying “You don’t have permission to furnish a private key.” Ignore that. Just be sure when you’re creating the service account, that you don’t give it full owner privileges on the entire project. You want to limit its access. For mine, I just set “Project->Editor” permissions. Even this is probably too wide open for most production uses. For this project, which is limited in scope and isolated network-wise, I wasn’t too concerned.

Once I created my service account and got my private key (JSON format), I copied and moved the key onto my Pi. So now auth with Firebase was (in theory) all set from a file standpoint.

The code

1. To know if there was anyone in the room
2. To view occupancy over time

Here’s the hunk o’ pertinent code that does the work from the device. There’s nothing super fancy in here, but I’ll walk through a few of the pieces:

The core of the script is a while loop that fires once a second. I wrote this bit of code to ignore the regular false positives that happen every minute, give or take. It’s intentionally not quite perfect, in that if it detects new motion that isn’t part of the cycle, it resets the cycle. This also means that motion that happens to occur a minute apart might be falsely ignored. The absolute accuracy that I sacrificed for simpler code was a fine compromise for me. If there’s one thing I can recommend, it’s to make life easier for future-you. An algorithm, or some logic, doesn’t have to be perfect if it doesn’t have to be. If it makes your life easier later, then that’s totally fine. Don’t let anyone tell you differently.

In this case, the potential faults could include:

• Real motion that occurs at one minute of time but is interpreted as false motion; this would likely self-correct within the next minute (the odds of it happening over and over are astronomically small).
• A false positive motion when real motion occurs and resets our one-minute false motion timer. Then, less than a minute later, an actual false motion happens, which is interpreted as a real motion (because it's been less than a minute since the previously detected motion). In this case, either there is consistent motion happening due to someone being in the room, or someone has just left the room and real motion has stopped, but the false motion was triggered. In the latter case, this just means less than a minute of extra detected motion before the timed pattern kicks back in and is ignored.

One aspect of this code that took me some time to debug (even when I THOUGHT I had fixed it) is the 'else' statement at the end. The PIR doesn’t always fire every minute. There were some cases when the PIR would go past one minute without firing, which would cause my test on time at the next minute (and all subsequent minutes) to fail.

Here is the second half of the while loop. It uses the config blob I saved earlier with a couple changes:

The service account handles the project ID and the sender ID pieces, so they aren’t needed in the config.

The rest, is nice ‘n’ simple. If the current motion detected is the same as the previous, don’t do anything else (I only cared about changes in motion as markers). I wrapped the Firebase connection and publish code in a broad try/catch because both can raise exceptions. But much as I didn’t care about perfect accuracy in the PIR correction code, the same goes for these exceptions. If an exception is thrown, it means one particular data point didn’t make it to the server, but this is fine because the code resets current_motion in the exception handling so that it will just try again in a second. So again, a couple seconds of being “wrong” is just fine in favor of simpler code.

The visualization

Even though this post is already pretty long, I wanted to at least talk through how to build a webpage which listens to Firebase data changes:

This is the Node.js configuration script to initialize the Firebase object. If I hadn’t set the authorization for read: true before, I’d need to go through authorization here as well.

Now that we’re all initialized, there are some events that we can listen to to get things rolling:

The document I’m updating in Firebase is that latest_motion piece. Whenever the latest_motion value changes (in my case, the timestamp of last motion detected from the device), that function gets called with the JSON output of the document.

Now, I didn’t HAVE to do that. I could have just made it a fully static page and required folks to hit the refresh button instead, but that didn’t seem quite right. Besides, as an IoT person, I don’t get a lot of opportunity to play with web front-ends.

If I were building a production system, there would definitely be some changes I’d need to make to this. But I just want to know if I can go practice my accordion without interrupting someone else who’s already jamming. Someday, I’ll be good enough that I’ll go up when there is someone jamming so we can jam together.

You can find all the device code and the Firebase web page project I used in my GitHub repo here. I also talk IoT and life on my Twitter: @GabeWeiss_.