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.

dadfinders

Dad Finder v1(left) and v2(right)

For the hardware, I chose the Particle Photon which connects with the Paticle.io 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.

ifttt

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.

Code for multi-switch posted to github

I’ve posted the code for my SmartThings multi-switch project to Github.

There you will find 3 files.

  1. smartthings_controller.ino – the Arduino code which communicated with the SmartThings cloud using the SmartThings Arduino library. I’m using an Uno.
  2. device_handler.groovy – the device handler code. This defines the device for use in the cloud and its UI in the SmartThings app. It is specific to the hardware, but not the use of the hardware.
  3. SmartApp.groovy – the SmartApp code. This defines how the device is used. In my app I tie specific hardware bits to specific device types (e.g. switch, switchLevel or musicPlayer).

For more information on the SmartThings IDE, writing SmartApps and related topic, have a look at these tutorials on the SmartThings developer site.

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, runnkeeper.com, 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.