Dad Finder, Map Edition

Three years after making my Dad Finder, I needed to update it to reflect my new commute. Rather than just print a new face for the clock, I decided to make a new version of Dad Finder with a new form factor and updated hardware.

I had picked up a frame from Ikea that is deep enough to conceal some hardware. I originally planned to use it to embed a few LED matrixes behind some artwork to display messages, but decided to use to mark my location on a Cold War era Soviet made map of the Bay Area.


Dad Finder v1(left) and v2(right)

For the hardware, I chose the Particle Photon which connects with the cloud platform. This was a radical simplification over the first Dad Finder which used five different components to connect to the internet and expose and API for me to hit from my mobile app. Additionally, the Particle platform has the advantage of being supported by IFTTT, so I no longer needed to use my own custom app to trigger updates as I move through different geofences.

Behind the map is a series of bi-color LEDs, one per location that I want to display on the map. On entering a geofence, I light the LED green, on exiting a geofence, I light the LED red.

The code for the Photon is available on GitHub.

Adding Sound

After using the new map for a few days, I received some complaints that it no longer made any sound. In the first version, the clock’s hand is moved by a hobby servo that makes a signature sound when moving the hand to a new position. The LEDs updated soundlessly and it turns out that my family missed having the audio cue that let them know that I was on the move.

To remedy the situation I added a small piezo speaker to the picture frame and added the ability to play melodies as the different zones are activated. We decided that some snippets from classic video games would do the trick. At present it plays the Mario 1-up sound when it starts up and either the first 4 notes or all 12 notes from the Zelda found item tune. Expanding the set of melodies so that each geofence has its own sound is on the todo list.

Using the Photon

I really enjoyed working with the Particle Photon hardware. The whole platform is quite easy to use and it is nice not to have to think about connectivity at all. To pass messages between IFTTT and my Dad Finder, I subscribe two functions in my Photon code (lines 9 and 10 in the source code). To trigger the function, I set up a series of recipes in IFTTT each defines a geofence and publishes to either the updateExisting or updateEntering event with Data that identifies the correct LED to light within the data of the event.


Screen capture of example recipe from IFTTT

These events automatically trigger the assigned functions within the Photon code (lines 33 and 40 of the source code).

This is radically more simple than working with the Xbee radio which required coding and configuring many more pieces including the Arduino board, the radio module, the hub, the Digi cloud service and an App Engine app to trigger the events reported from my mobile app. What took many weekends to set up on version 1 of Dad Finder took only a couple hours for version 2.

Screen Shot 2015-10-17 at 2.49.49 PM

The components used to connect v1 (top) and v2 (bottom)

However, it did take a bit of time and trial and error to get things stable on the Photon. Originally I was trying to use an LED matrix and backpack from Adafruit, but using that in combination with the cloud platform seemed too much for the Photon. I found myself restarting the board often to reestablish connectivity with the cloud. Even after simplifying the code to its present state, I have had to update the firmware to improve reliability.

The Xbee system may be more complex to set up, but I don’t recall touching the code or the hardware in the three years it was running. Time will tell if the final build of v2 will be as reliable.

Helpful overview of the Gimbal SDK from Qualcomm

Gimbal is an attractive ecosystem for BLE beacons with two different beacon form factors (a fairly basic Series 10 and a more heavy-duty Series 20), an SDK and web-based management services.

from Inside Gimbal: Qualcomm Beacons Tackle Bluetooth LE Challenges | BEEKn.

There are some incredibly appealing reasons, however, to use the Gimbal ‘cloud’. They’ve managed to take a lot of the pain away in developing beacon-based solutions.

Give people stories to tell about ambient interactions powered by the IoT

Successful wearables may need to offer more than utility and fashion to succeed. Telling people stories helps them better understand otherwise ambient interactions, an important part of proving ongoing value. Personally, the accessibility of these stories has definitely influenced my long-term adoption of devices and services (and, more often, my abandonment of them).

From A narrative architecture for The Internet of Things:

But the more intriguing challenge is to start with the devices and build narrative from there: to layer the convention of storytelling onto the framework of the Internet of Things:

  • How do you add narrative elements to your smart watch?
  • How does a store “talk” to you as you walk through the aisles?
  • How do you add a sense of agency and narrative tension to your morning jog?
  • How do you tell stories about energy and sustainability and collective effort in a connected city?
  • How do you use foreshadowing, climax, and denouement to help users understand where they are on a particular journey through a connected experience?
  • How do we use history, legacy, myth and heroes as tools in the armament of connected experiences?

Who owns the data?

The authors of Who owns the Internet of things? raise an interesting question: what expectations will consumers have over the ownership of data collected by their connected products?

Prevailing thinking in many developing IoT markets is that the provider of a product or service is the center of gravity. For example, original equipment manufacturers OEMs in many industrial and commercial markets expect to define and deliver new services by leveraging IoT capabilities in their products. The implied, and often explicit, assumption is that OEMs will own and control the resulting data.

The owners of all those IoT-connected appliances, cars, and industrial equipment are likely to believe that the data those items throw off is theirs–not the OEMs.

I personally expect the service to own the data but expect that that data will be made available for me in perpetuity. This is simply the model I have built through my entire life of interacting with service companies.

Take my credit card as an example, I fully expect that my bank owns the data about what I buy. They need this data to provide me the service and all I expect in return is to be able to access that data and some level of analysis of my habits. As I became a more sophisticated consumer of credit, I looked for banks that I could trust with this data and ditched those I could not, but I never stopped to think that the data belonged to me.

So far, I’ve transferred this perspective to connected device services like TiVO,, Nest, Nike+ and others. As I see it, they collect data about me in order to provide a service that is valuable enough for me to provide them with the data. In cases where I can export that data and maintain joint custody, all the better, but I don’t feel like I own the data.

It does get a little blurry. When it comes to dropbox, I my expectation are a bit different. Data they collect about the my usage of their service is theirs but I certainly don’t expect them to stake a claim over my files.

Anyway, as I said earlier it is an interesting question and I look forward to seeing if my opinion is shared by others and if it changes over time. If it does change over time, I hope it won’t just be an issue for IoT companies to contend with. It seems like long standing services, like banks, utilities and every other business that collects information about their customers could be challenged to adapt.

FitBit Glassware

Many of us at Nurun are very interested in wearable technology. When one of the developers in our San Francisco office was accepted into Google’s Explorer Program, we jumped on the opportunity to start working on Glassware.

The first prototype we built delivers Fitbit data to the Glass timeline using Google’s Mirror API and Fitbit’s public API. It is designed to help users reach their personal goals with timely, easily accessible micro-interactions.

via FitBit Glassware.

Connected Personal Objects: Getting Intimate with the Internet of Things

Last week, Guthrie Dolin and I presented at the Planning-ness 2012 conference. The conference was great, and I love it’s theme, “Get Excited and Make Things.”

The standard format for a session is present on a topic and then run a workshop in which conference participants make something to present back to the group.

In our session we provide an overview of the Internet of Things before going into detail about the potential of connected objects to encourage specific behaviors. We break down the components of an IoT ecosystem and discuss how they can be used to collect data and drive insights and change.

Following the presentation, the assignment was to use the framework and design a physical product and service around a personal object or situation. We provided a few catalysts and blank worksheets to help get people going. The results were great and we’ve posted each group’s worksheets on slideshare as well.

All-in-all, a great expreience and a ton of fun. Thanks to everyone who turned out to learn about the Internet of Things.