Building the Pinoccio Pomodoro

This week, I had the chance to hang with the team at Pinoccio – they’re building magical little wireless microcontrollers that talk to each other (via a radio mesh) and to a web API (via wifi). When you combine those boards with prebuilt “backpacks” of sensors and other tools, you get a powerful tool for building your personal internet of things.

I was looking for a short project to learn how to interact with my Pinoccio troop. The company has built an easy to use node.js module, so I decided that a little javascript app would be a great starting point. I also wanted to build a tool that would both talk and listen to the troop, passing commands via the API and receiving instructions back. Since this was both my first Pinoccio app and my first Javascript app, I wanted to keep things as simple as possible.

After poking around with a few ideas, I decided to build a little Pomodoro timer, powered by Pinoccio. I spend a lot of time at my desk context switching between writing/programming on my laptop, and reading/studying on my kindle or paper textbook. Having a big, visual indicator telling me to focus or take a break would be really useful – sort of a needlessly technical version of Chris Poole’s chart.

For this tutorial, I’ll assume you already have a Pinoccio troop, consisting of one wifi connected lead scout, and one scout with a button installed. I’ll also assume you have Node.js installed, and that you have a tiny bit of familiarity with javascript. No idea what I’m talking about? No problem – just start with this guide to setting up your troop (via the browser!) and this tutorial for getting a button working with your scout. Node.js docs can be found here.

Once you’re all setup, take a minute to play around with your troop in Pinoccio HQ. Turn your LED’s on/off, and make sure your scouts are responding to scoutscript commands (you can type them right there in the browser!).

Next, lets install the Pinoccio node module. After you login, run the “pinoccio token” command to make sure you’re setup properly. Save the token that returns, as we’ll need it in just a minute.

Now, on to setting up our javascript app. Create a new folder for your app, then create a new javascript file. I called mine “pinoccio-pomodoro.js”.

Next, you can run “npm install pinoccio prompt” from the folder you created your javascript file in. Make sure you also make the changes in the javascript comments, adding your token and the correct troop/scout ID numbers. Once our file is setup, we can start listening to Pinoccio’s streaming API:

The first console.log() is a quick test to make sure we’re properly connected. run your app from the terminal, and you should see a stream of JSON on your screen. Press the button on your scout, and you should see new data being reported.

Next, delete or comment out the first console.log(), and uncomment console.log(“Button-press task started.”). Rerun your app. Now, you’ll see “button press task started” each time you press the button on your scout. Not working? Make sure you’ve have the correct value for your troop and scout names.

Now, we need to write two simple functions to interact with the user via the command line, and to pass messages down to the pinoccio that will display our timer light. Starting with the user interaction, we’ll use a simple instance of the “prompt” module which makes it really easy to interact with users on the command line. Our code for this method looks like this:

The prompt documentation has a good explanation of the different configuration options, if you want to make any changes. To wrap everything up, we just need our actual timer method.

Most important here are the two calls we make to the Pinoccio REST API. We use the node module to post led.red to the scout when the timer begins, and when the timer expires we change post a new command to switch to green.

These commands are simple ScoutScript, so read the docs and experiment with making changes: make the LED turn different colors, or pass entirely different commands.

So, now all that remains is putting it all together. The complete code:

You should note the addition of the call to setTimer() when a button press is detected in the API listener. The same call is added to the “yes” answer if-statement in the runPrompt() function.

So that’s it! You should now have a working indicator light that responds to either a button press or console command. Each time you start a new timer, it will run for 25 minutes, before prompting you to start a new pomodoro.

As a next step, I plan to add better tracking of completed tasks (maybe some sort of goal/progress tracking), and maybe figure out a few more interesting Pinoccio interactions to add in. I’ll probably also hook the lead scout (with LED) up to a larger board that can be hung up over my desk.


Robots, Inequality, and Seattle’s Minimum Wage

(Cross-posting from Medium. There’s also a good discussion on /r/seattle about the post)

The story on Seattle’s decision to introduce a record high $15/hour minimum wage is being told looking backwards. Pundits from both sides of the political spectrum are focusing on a narrative of middle class wages, union membership, and inner-city poverty. This standard narrative misses the greater story: Seattle’s decision puts the city at the center of the rise of service job automation, while also accelerating the dramatic inversion of the American city. The Seattle City Council’s attempt to combat rising income inequality (driven, in large part, by a booming tech sector and the increasing automation of low wage manufacturing work) will unwittingly set off a gold rush in technology and automation.

There is surprisingly little consensus among economists on the impact of dramatic increases in the minimum wage. The best data can be summed up as this: poverty does decrease, but so too does the total number of jobs. But what Seattle is attempting is nearly unprecedented, in that the increase is dramatic (a nearly 50% increase over the existing wage), sustaining (pegged automatically to inflation after implementation) and gradual (phased in over 3-7 years, depending on the size of a business). I predict there will be two major impacts, neither of which are being discussed extensively, and with both representing major unintended consequences from the perspective of Seattle legislators.

First, and most importantly — Seattle’s City Council just made their city ground zero for the automation of service industry jobs. Imagine this: You’re an entrepreneur working on the next generation of those (currently terrible) self checkout systems. You’re bootstrapping your company, but having trouble getting traction with merchants. Everyone you talk to sees the value in automating the checkout process, but most businesses can’t quite justify the capital expenditure required to save on staffing costs. Seattle just created a geographically dense collection of highly motivated customers overnight. If they aren’t already, that entrepreneur should be on a plane to Seattle, ready to pound the pavement for new customers.

Remember, Jeff Bezos famously started Amazon in Seattle due to its combination of technical talent and advantageous tax situation. Watch closely: as the new wage phases in over the next seven years, expect large companies to test their US automation efforts in Seattle first, and expect a boom in startups bringing cheaper, easier forms of automation to cash-strapped small businesses. The net effect of that boom will be more highly skilled jobs in the Seattle region, and a commensurate increase in income inequality in the city.

Second, and related to the problem of rising urban income inequality: the gravitational pull of dense, wealthy city centers is intensifying the inversion of American cities. Since the 1940’s, American cities have been typified by poor, urban cores, with wealth distributed in concentric bedroom communities connecting commuters to the remnants of traditional downtowns.

The past decade-plus has seen this trend reversing, starting with the revival of urban cores in New York, Chicago, and San Francisco. Whatever your pet cause for this reversal (ranging from the changing lifestyle preferences of millennials, to falling urban crime rates driven by the elimination of leaded gasoline), it is now clear that in almost every city, wealth is concentrating in the center, while poverty is pushed out to formerly affluent suburbs. Seattle just unintentionally accelerated that process. Minimum wage workers in the city will be better able to afford a rising cost of living, but those workers that lose their jobs will be forced out to lower paying opportunities in the suburban periphery. Along with the aforementioned rise in inequality due to a booming tech sector, expect Seattle in ten years to look wealthier and less diverse.

At first glance, these predicted consequences paint a dim, even critical view of the decision to increase the minimum wage. I think the opposite conclusion can be drawn, and that Seattle should be lauded for putting themselves ahead of the coming automation wave. By recognizing the increasing political power of wealthy, dense metropolitan areas, Seattle can take action on what will ultimately be a series of difficult political decisions. How do cities cope with poorer commuters streaming in from the periphery? How does a tax base change as staff-heavy businesses become more capital intensive? Perhaps most importantly, what does an American city look like when it’s densest areas are almost universally affluent? The next 50 years will see these questions answered across the developed world, and Seattle will be leading the way.