Personal Sensors and Event Networks

A few weeks ago AJ Fisher wrote about sensor networks, and the structure of what he brilliantly calls a Sensor Commons. I love the future he describes, and the benefit we will gain as a society from the information gathered by little sensors all over the place.

AJ’s vision addresses the problem of sensor data in the large, but I struggle with a different problem. I want a better way to install, configure, and use sensor data in the small. I’m glad that I can contribute the weather information from the little station outside my house, but I also want a better way to tie that into my house thermostat and my alarm clock.

My Sensors

In my personal life right now, I only have a few sensors. One of them is my cell phone, which is perhaps the best current sensor for life activity. I’m also eagerly awaiting my Twine device, a result of my backing their KickStarter project. I foresee a future with sensor data available from my appliances, my power system, and the lights, switches and plugs in my home. Most of this data is already known, but not shared.

My thermostat knows what the temperature in my house is. It displays the current temperature on the front and uses it to automatically turn my furnace and air conditioner on and off. Do you know what would be really neat? I’d love to see a historical graph of that data. I’m not talking about new, complicated data here. I’m just talking about the same data *already being collected* being shared and accessible.

Configuration

For normal human beings, tying these sensors together is a challenge. They want a way to easily add a sensor and give it behavior in a user friendly way. I believe the right way to do this is with a Personal Event Network. Devices connected in such a way are simple, because the behavior and logic is programmed in the network, not on the device. This allows low cost devices to be easily attached, and then configured via the user’s installation of Apps into their Personal Event Network.

I believe that Apps are really a collection of features. By choosing and installing Apps, a user configures their phone and their computer. Personal Event Networks can be configured the same way.

Sensor Data as Events

Perhaps the only component that I’d add to AJ Fisher’s design of the Sensor Commons is the concept of events and Evented APIs. The only current way to access sensor data is through a traditional API, and that means polling. And we all really hate polling. By supporting the concept of events in the Sensor Commons, an infrastructure of real-time, flowing data is possible.

I see a future where my personal sensors are connected to my Personal Event Network, and I share data from those sensors by installing Apps that share my sensor data with the Sensor Commons, making it available for the use of scientists everywhere.

Thanks, AJ, for sharing your thoughts with us. May we work together for this bright future.

Evented World: City

In today’s Evented World post, I’m going to stretch the definition of a Service to include a City. I’m going to choose a city, but this discussion is easily expanded to a County, a State, or hey, even a Country!
 
Cities are a really great example of a service. We pay for it through our taxes and services, and the events of a city have a direct effect on our lives. Cities typically provide or coordinate garbage and recycling services, snow plows, and utilities. They maintain roads, have parades, hold public meetings, and provide fire and police services.
 
I’ve picked only a few of the many events that are appropriate to give some examples of how they could be used. How many more can you imagine?
 
Evented Cities
 
road_closure - Raised when the city will close a road to traffic.
council_resolution - Raised when the council passes a resolution.
snow_plow_active - Raised when the plow is out, with attributes containing recently cleared streets and streets being targeted next.
evacuation_order - Raised when an evacuation order is in effect during a crisis such as a wild fire. Attributes include area of evacuation and references to additional information.
garbage_pickup - Raised when the garbage is to be picked up for a neighborhood. Attributes indicate when the pickup can be expected.

City Mashups

Due to a holiday, my garbage is not picked up on it’s regularly scheduled day. Two days later a garbage_pickup event early in the morning causes an alert to be sent to my bathroom mirror for me to see and acknowledge when I wake up.

 A council_resolution event is raised during city_council meeting. A CyclingAdvocate app on my Personal Event Network recognizes that the resolution involves bike lanes, and loads the details of the resolution into my Instapaper account for later reading.
A road_closure event from the city works department is received by the garbage company, who adjusts their pickup schedule to avoid the road closure. Every home rescheduled is sent a garbage_pickup event with the adjusted expected pickup information.
Smartphone location events from both my phone and my wife’s phone indicate that we are out of state. An evacuation_order event is raised due to a nearby fire, causing a message to be sent to the next-door neighbor asking them to take our pet cat with them since we are out of town.

Linkage
The whole Evented World series on my blog.
A proposed spec for Evented APIs.
Kynetx, an event engine in the cloud, and the company I work for.

 

Types of Social Sharing

Facebook’s new Frictionless Sharing has started some conversations about what Social Sharing really is.
 
Items
Digital Sharing has a history that is mostly Item based. I’ll start with email (though sharing existed before) to limit the discussion to digital forms of sharing. Email was (and still is) used as a method of sharing Items. If you find something interesting, you can email a link or copy the content into an email. As Social Sharing grew with Social Networks, sharing has mostly followed this similar path. An explicit action is required to distribute the item of interest to my followers.
 
Item based sharing is meant to be received Item by Item. Email lands in an inbox till read. Items in Google Reader remain as unread till viewed by the user. Streams are designed to show a current view, and typically do not provide the user a method to start where they last left off.

Google+ seeks to refine the Item based social sharing, and their Circles method of selective sharing does a good job to refine the per Item flow.

Streams
Facebook is seeking a different type of sharing, one focused on Streams. In this model of sharing, shared items are not filtered, and the emphasis is on the Stream, not the Item. The value of each item is much less then Item sharing, but the value of the stream itself is more powerful with the constant flow of data.
 
Stream based sharing is not a progression from Item based sharing, but a new type of sharing enabled by the proliferation of APIs and web technologies.

Confusion
The current problem with Social Sharing is confusion between these two sharing types. Users and Services alike remain confused about which they are, causing flaws in design and misuse by users. Social Noise is a result of including Streams in an Item system. Other examples of sharing confusion:

  • Google+ is an Item sharing service, but provides no easy way to resume from your previous place in the list of posts.
  • Facebook is a stream sharing service, but provides no way for users to extract value from the stream in aggregate form. Pandora (through it’s Facebook partnership) should offer a Station based on the recently listened items from my social contacts.
  • Google Latitude has both Items (places I explicitly check in) and Streams (Places I am checked in automatically), but does not offer tools to handle these types of sharing differently.
  • Endomondo is a workout tracking and sharing service. They make no differentiation between Items and Streams, though some of my workouts are Items (an epic bike ride) and some are Streams (my daily bike commute).

Litmus Test
Do  you care if you miss an update? If you do, you are likely treating that as an Item. If you only care about what’s recent, then a Stream is more appropriate.

Now
We need to learn how to distinguish between these (and future) types of sharing, and learn how to best use each type. Something New isn’t necessarily Bad.

 

Evented World: Car

check engine light

This past Friday, the Check Engine light came on in my car. As far as error reports go, this is one of the worst. The presence of the light simply means that SOMETHING IS WRONG of an unreported magnitude. Reading the error code to find out what is actually wrong requires a specialized device that plugs into the car’s OBD data port. Most mechanics have one, and even some auto parts stores. Fortunately, I own a neat little gizmo that acts as a OBD to Bluetooth bridge, allowing an app on my phone to communicate with the car’s internal computer.
 
This particular car was originally sold in California, and it’s fuel oxygen sensor is a little picky at the higher elevation of Utah. I read the code with my phone, determined that I’ve seen this code before, and cleared the code, turning off the check engine light and returning the car to it’s normal operation.
 
Doing an Evented World post on a car has been on my list since the beginning, but my Check Engine light experience motivated it to the top of the list. I’m calling this an evented car, but this clearly applies to your truck, minivan, city bus, and even the Schwan’s refrigerated delivery vehicle.
 
The Evented Car

door_unlocked - Raised when a door is unlocked, with attributes indicating which door, and perhaps which method (key fob, key, internal button).
door_locked - Raised when a door is locked, with attributes indicating which door.
door_opened - Raised when a door is opened, with attributes indicating which door.
door_closed - Raised when a door is closed, with attributes indicating which door.
engine_started - Raised when your engine is started.
engine_killed - Raised when your engine is turned off.
engine_error - Raised when your Check Engine light is on, complete with attributes indicating the problem.
vehicle_status - Raised periodically with attributes such as fuel level, ignition state, speed, and location
crash_detected - Raised when airbags deploy or seat belts lock.

It is worth noting that most events will also be handled by the car’s internal systems, and that they are also signaled externally. The deployment of the car’s airbags does not depend on involvement of any external systems.

I’m going to limit this exploration to these simple events, but I’m sure you can imagine more.

Car Mashups
Calling these ideas car mashups just sounds bad, doesn’t it? Here are just a few of the potential evented mashups involving a car:

A vehicle_status event with an updated location, followed by an engine_start event causes a comparison between the location of the car and the location of all valid drivers of the car. Finding no valid match and not having the Allow Guest Drivers preference set, the engine is killed and an alert sent to the car owner.
A crash_detected event sends a message to OnStar and to the insurance company. OnStar opens a call to the vehicle to determine if emergency services is needed, and the Insurance company notifies the local agent.
An engine_killed event, followed by a vehicle_status event causes the car’s location to be recorded. Smartphone location events from the driver are monitored, and when the driver begins to head in the direction of their car, guidance information appears on the screen of their smartphone guiding them back to the car.
A vehicle_status event uses the location of the car and the fuel status to alert the driver to nearby cheap gas prices convenient to their location. This saves fuel by not requiring additional driving to reach a cheaper station.

Linkage
The whole Evented World series on my blog.
A proposed spec for Evented APIs.
Kynetx, an event engine in the cloud, and the company I work for.

 

Evented World: Utilities

Outside each of our homes, there are utility meters carefully measuring our use of water, electricity, and gas. These devices can tell us about our utility usage, and therefore our monthly bill, just by walking outside. When was the last time you checked one of your meters?
 
The collection of data does not automatically make it useful.

Most of us see utility information when we get our bill, which is usually a week or so after the monthly billing period ends. This delay between measurement and reporting is one of the reasons why we are not very efficient with our use of utilities. Can we shorten the delay between measurement and reporting?

Evented Utilities

current_usage_rate - Raised periodically with the current usage rate as event attributes.
price_update - Raised when the utility is adjusting prices.
daily_usage_total - Raised after the close of each day with the totals for the day.
monthly_usage_total - Raised after the close of each month with the totals for the month.

Monitoring devices like utility meters produce a constantly changing numbers. In order to limit the number of events to a sane amount, these numbers must be filtered and consolidated. Two common methods are time intervals or significant change thresholds. It’s probably accurate enough to have utility data reported every 5 minutes. This is simple to build and keeps the values to a minimum. Another method would be to report the new values whenever they change significantly. This will send fewer events for measurements that don’t change very fast, but will send one immediately when one does change.

Utility Mashups

A location event from my smartphone indicating that I’m away from the house, followed by a current_usage_rate event for my electricity that is higher then normal (when I’m home) sends an alert to my smartphone.
A daily_usage_total event indicates that my water usage is much higher then my monthly budget allows. During that day, I’m alerted whenever a current_usage_rate is high, so I can determine the main uses of water in the house. When daily_usage_total events indicate that my use is within budgeted amounts, no alerts are received.
By monitoring price_update events, apps in my Personal Event Network can make adjustments to the thermostat or scheduled running times of my appliances to reduce running costs.

Linkage
The whole Evented World series on my blog.
A proposed spec for Evented APIs.
Kynetx, an event engine in the cloud, and the company I work for.

Evented World: Consumer Shipping

One of the clear winners of the eCommerce revolution was consumer shipping companies. Shopping online has become mainstream, and UPS, FedEx, DHL, and others have the pleasure of moving our goods from one place to another. Oddly enough, these shipping companies only maintain a relationship with the shipper of the package, and not the receiver. They do provide delivery alerts, typically in the form of an email or SMS, but that is where their involvement ends.
 
Connecting shipping companies to Personal Event Networks will have some incredible benefits that our current systems don’t allow. Imagine not giving your shipping address to the online merchant. Your Shipper knows where you live, and quotes shipping options accordingly. Shipped packages raise events into your Personal Network, and personalized service could enable delivery to where you are, not to a predetermined address.

For Personal Event Networks, all this magic is easy. Now, on with the show.

Evented Shipping

new_package - Raised when a new package has been created in the shipper’s systems.
package_progress - Raised when delivery progress has been updated. This event will be raised frequently during the deliver process. Event attributes will include estimated delivery dates.
package_delivered - Raised when the package is delivered to it’s final destination.

These events are hardly surprising. In fact, many shippers currently send notifications similar to these, usually in the form of messages intended for human consumption and delivered via email or text message.

Shipping Mashups

When a new_package event is received, an app called DeliverAnywhere uses permissioned access to personal data such as my calendar to determine that I’ll be attending a conference out of state at the time of delivery. The package is routed to that location.
An urgent package is being sent to my home. Because the package requires a signature (or, you know, a biometric id), it cannot be left on the doorstep. 10 minutes before delivery a package_progress event is raised with the updated delivery estimate. The music blaring in my workshop is gently paused, and I’m alerted that the sensitive package will soon be arriving.
While on vacation, a low priority package is delivered on my doorstep, resulting in a package_delivered event. Because I’m on vacation, a message is sent to a neighbor’s kid who is watching the house. He runs over to pick up the package and put it into our garage for when we return.

Linkage
The whole Evented World series on my blog.
A proposed spec for Evented APIs.
Kynetx, an event engine in the cloud, and the company I work for.

Evented world: Elementary School

When I was creating my original idea list for this Evented World series, Brad Hintze suggested elementary schools. While a school might not be the first thing that jumps to mind when you think of a service you use frequently, I hope I can change your mind. I’m specifically talking about elementary schools, but this could likely apply to all types of education institutions.
 
The Evented Elementary School

child_present - Raised when your child’s attendance is recorded for the day.
child_released - Raised when your child has been released. This will happen when class has ended, or when your child has been picked up from school. Event attributes will include the reason for release.
grade_updated - Raised when your child’s grades (marks) have been updated.
assignment_issued - Raised when the child has been issued a new assignment. Event attributes will include a information about the assignment, including the due date.

I’m sure there are more events that apply in this setting, but even these simple events can yield some powerful opportunities.

As with other evented systems, direct action is not required by a human to raise the events. These events will be raised by systems created to help manage the school. Attendance software will raise the child_present and child_released events. The teacher’s grade system can raise the grade_updated and assignment_issued events in response to assignment information recorded by the teacher.

Elementary School Mashups

A temperature_recorded event indicating a slightly elevated temperature, followed by a child_present event sends a message to the school nurse. The elevated temperature might not be a sign of the child getting sick, but getting checked early could help prevent the spread of disease through schools.
An assignment_issued event is received by a HomeworkHelper app I have in my Personal Event Network that helps me remind my child and links to resources that can help with the assignment.
After an earthquake, smartphone location events are combined with child_present and child_released events to help my wife and I retrieve our children from school and then meet up at a safe location.
The family’s game console automatically adjusts allowable play time per day based on grade_updated events. When grades improve, restrictions are gradually relaxed.

Linkage
The whole Evented World series on my blog.
A proposed spec for Evented APIs.
Kynetx, an event engine in the cloud, and the company I work for.

Evented World: Thermometer

Today’s Evented World product is a direct result of being sick all weekend. Achy muscles, and a high temperature. I took my temperature at least once a day to see how I was doing, but it was all I could do to remember the previous measurement. Somewhere in the middle of a sleepy haze, it occurred to me that this was a job for my Personal Event Network.
 
The Evented Thermometer

temperature_recorded - Raised when a measurement is taken.

A simple event really, but the power is the presence of this event in my Personal Event Network. We use our thermometer for everyone in the family, and which measurement is whose turns out to be important. The person being measured might be simply selected on the screen of the thermometer. In the future, a personal biometric device can monitor temperature on a more regular basis, raising a temperature_recorded event when any significant change is detected.

Thermometer Mashups

A temperature_recorded event indicates that my temperature has started to rise above normal. Since my calendar indicates I’m planning on going to dinner with family later in the day, a notice is sent to my phone letting me know I’m coming down with something.
When a high temperature is reported by a temperature_recorded event, an app I have activated on my Personal Event Network releases that information to an anonymized data analysis service. The service responds with the probabilities of what I have, based on recent temperature events and the eventual diagnosis of those individuals in my surrounding area. This helps me understand if I’m going to be out for one day or a week and arrange my schedule accordingly.

Linkage
The whole Evented World series on my blog.
A proposed spec for Evented APIs.
Kynetx, an event engine in the cloud, and the company I work for.

Evented World: Fitbit Personal Biometrics

We’ve talked about the personal nature of an Evented World, and have even described a person’s collection of evented products as a Personal Event Network. Few things are more personal then our personal health information. Personal biometrics is an area only recently opened up by the development of small processors and longer lasting batteries, but there are a few available today. Today, I’m going to look at Fitbit, but the Jawbone UP does similar things, and I’ll include a nod to the BodyBugg, one of the first movers in this space.
 
I’m focusing on Fitbit today because it already has an API, and they even support a form of push data. The effort required by a product like Fitbit to support Evented APIs is very minimal, and I believe it is products and services like this that will add support first.
 
Fitbit Events

sleep - Raised when the user finishes a sleep session. Attributes will indicate how long the sleep session was.
physical_activity - Raised when a user’s physical activity is recorded. This may be directly after an activity, or reported once daily as a collective measurement.
food_consumed - Raised when the system records food eaten. Attributes will include health information.

With occasionally connected devices like the Fitbit, it’s important to remember that the events being sent are likely queued. The Apps receiving those events must understand the time delayed nature of the events. Even with this limitation, most of the events received can be useful in providing context for Evented Apps.

Fitbit itself is an event processing engine. It takes the little motion events that it senses, and derives meaning from those events. It can tell when you are sleeping, when you are just laying in bed, and when you are doing something physical like walking. The Fitbit then records higher order events, like sleep, or physical_activity and makes those events available to other connected applications.

The role of event engines in Personal Event Networks is powerful. I believe that we will see engines used to monitor low level events and raise higher order events as an important part of our experience.

Fitbit Mashups
After receiving a sleep event indicating that I’ve received less then 2 hours of sleep in the last 48 hours, my car limits it’s max speed to 80% of the speed limit on the roads I’m driving.
A series of physical_activity and food_consumed events (combined with weight events from my bathroom scale) are combined to produce a daily personalized exercise and diet plan.
A Testing Optimizer app monitors all these personal biometric events and uses test_score events from my university classes to identify the effect of personal health habits on my testing scores.

Linkage
The whole Evented World series on my blog.
A proposed spec for Evented APIs.
Kynetx, an event engine in the cloud, and the company I work for.

Evented World: Airline Flight

Airline travel is something that most of us do, and it’s filled with managing logistics. Existing systems, including the airlines themselves. You can sign up for text messages for emails letting  you know about changes to flight status. Smartphone apps can lookup and display this information.
 
The problem is that these messages are only designed for humans to receive. It is left up to the user to receive and process these messages. The problem is that I might not be available to receive those messages, and I might not want to directly deal with each of them anyway. Extending these existing systems to participate in event networks enables mashups beyond the scope of what these systems are currently capable of.
 
The Evented Flight
 
flight_estimate - Raised when the estimated boarding and departure time changes
flight_boarding - Raised when boarding has begun, perhaps multiple times based on seats or boarding zones.
flight_takeoff - Raised when the plane takes off.
flight_progress - Raised when estimated landing times are updated.
flight_landed - Raised when the flight has landed.

I am simplifying the events related to a flight, and this is on purpose. A full implementation of an evented flight is likely to include such events as pushed_back, taxi, etc, but let’s go with what I’ve started with.

Flight Mashups

My Smartphone signals a location event, which apps on my Personal Event Network use to determine that I will be late to the airport. A flight_estimate event also arrives with data indicating that my flight will be late. My Personal Event Network realizes that even though I’m going to be late, I’ll still arrive in time for my flight. A notice is sent to my car’s display letting me know this.
A friend has asked me to pick her up from the airport. After takeoff, strong tailwinds cause the flight to arrive at it’s destination a full hour early. My Personal Event Network receives several flight_progress events, notifying me that I will need to leave for the airport earlier then expected.
When I arrive at my destination airport, flight_landed events are forwarded to the off-site parking facility to notify them that I have arrived. When I get to the curb, the driver is ready, having waited two extra minutes to pick me up.

Linkage
The whole Evented World series on my blog.
A proposed spec for Evented APIs.
Kynetx, an event engine in the cloud, and the company I work for.