Archive for February, 2015

Build This Idea: Soft Meter, a smart meter for everything

Saturday, February 28th, 2015

This is second instalment of Build This Idea, where I write about stuff I want to exist. Treat it like an idea store; if you like something, take it; if you make it, let me know — I’ll be delighted to check it out. Today, a web service I think would be super neat but haven’t had the time to built yet.

I would like a web service where I can easily enter any kind of meter reading, transit trips, plane flights, etc, and have it collate those over time and calculate and display usage and approximate carbon footprint.

I was able to get this for electricity from a BC Hydro smart meter when I lived in Vancouver. But a lot of people, and a lot of data categories, don’t have smart meters.

Screenshot of a website showing a bar graph of energy use by day

BC Hydro’s daily energy use tracker

This would be the smart meter for everything else. Have a simple interface with one field: the current meter reading. The user walks by the physical meter with their phone and enters the current reading in the browser. Three or five days later, do the same. With two data points, the site can calculate usage. With three data points, the service can display a trend. Draw a graph.

Knowing the trend — and visualizing it — is perhaps the biggest thing. Nothing motivates quite like “you’ve used more this week than last week.” What can be measured can be improved, what can be tracked can be optimized, and what can be seen improving can motivate to improve more.

Most people get some feedback when they get their bill. But feedback every two months isn’t as effective as feedback every three days. People can link what they did in the past three days easier than what they did in the last sixty days. You can change behaviour quicker.

Frequent feedback can be done with a smart meter. Or it can be done with a service that will be a smart meter for the rest of us.

The neat thing is that the solution can scale itself to so many things. Electricity meter. Gas meter. Water meter. A car’s odometer. Also point data: a flight from Heathrow to Pearson; number of transit trips in a month.

I’ve created something like this for myself but updating it is substantially more involved than one input field. It doesn’t estimate environmental footprint (currently a 1000 km flight appears the same as a 10 km drive) and there’s quite a lot of technical debt. But it is a nice proof of concept and I did find that tracking motivates me to use less.

There will of course be privacy issues. I have been thinking of a Javascript-based site where all data is stored on user’s device unless otherwise requested, but there’s many possible solutions. Surprise me.

I often say that when you can measure what you are speaking about, and express it in numbers, you know something about it; but when you cannot express it in numbers, your knowledge is of a meagre and unsatisfactory kind; it may be the beginning of knowledge, but you have scarcely, in your thoughts, advanced to the stage of science, whatever the matter may be.

— William Thomson, 1st Baron Kelvin, Lecture on “Electrical Units of Measurement” (3 May 1883), published in Popular Lectures Vol. I, p. 73

If you can not measure it, you can not improve it.

— snappier Kelvin, according to the internet, so it must be true

Extra functionality

For when you’ve nothing left to do but add exciting new features:

  • Add ability to upload data from external sources, like CSV exports of BC Hydro smart meter data, or Oyster history exports.
  • When presenting trends, add generalized data from the city/region/whole system for comparison, or add weather history to help people understand what might be driving their usage.

Nexus 5, ten months in

Monday, February 23rd, 2015

I like bunnie’s exit review idea (e.g. on his T60p, on his 8700c): the thought that you can write a better review at the end of a device’s life than after a week or two. This is not a true exit review, but I will bend the rules here a bit and say that ten months, one winter, and one broken screen is enough to write down some useful thoughts about the Nexus 5.

I bought a Nexus 5 in April 2014. This is my third mobile phone after a Blackberry Pearl 8100 and an HTC Nexus One. I’ve also owned Nokia’s N800 and N810 internet tablet devices.

Factors involved in deciding what phone to get were wireless networks supported, size, software hackability, input methods, software updates, storage size/options, and the camera in roughly that order.

I somewhat seriously considered going back to Blackberry but couldn’t find a pentaband model I liked and could justify cost-wise. I briefly tried a Nokia E72 but found software and keyboard lacking. At one point I considered a Nokia E6 but ended up forgetting it (oops) when I resumed phone-shopping.

I paid $132.50 (USD) for the Blackberry in September 2008, $200 for the Nexus One in October 2011, and ended up paying $463.62 for the black 32 GB Nexus 5 in April 2014. My thoughts are mixed.

Blackberry Pearl 8100, HTC Nexus One, and LG Nexus 5 phones viewed from the front

The family, with factory screen protector still on the N5.


A week of car2go in Canada

Wednesday, February 11th, 2015

This post has been updated on March 27, 2015 with corrected data. The data posted initially was partially wrong due to a bug in analysis code.

The bug caused trips that started and ended in the exact same position to not be counted. The car2go GPS reports 5 decimal digits (resolution of about 1 m), but I have overlooked that cars at a designated parking spot always show the exact same GPS coordinates predefined by car2go. The bug then ignored trips made by cars picked up and returned to the same designated parking spot.

Depending on the city, this caused about 22% to 33% of trips to be excluded and underestimated total fleet utilization by 18% to 31%. Median trip counts per car were underestimated by 20% to 32%, while median trip distances were overestimated by 22% to 31% (see below for note on round-trip distances). Trip duration median were accurate to within a minute, but quartiles were overestimated by 5% to 10%. Because the bug only affected detecting round trips, the positions maps were accurate and have not changed.

car2go is a carsharing service operating in a number of Canadian cities. It has a one-way model in which cars do not have to be returned to where they were picked up, but can be dropped off almost anywhere within a specified operating area and picked up from there by another member by for the next trip. This mimics most bikeshare operations and in a sense provides a taxi you drive yourself.

Systems are outfitted with a uniform fleet of two-passenger Smart Fortwo vehicles and a parking deal is negotiated, most commonly to allow parking in any resident/permit location.

Data on usage of the service is available from an API, listing current positions of available vehicles. Collated over time, we can calculate a car’s trips, and some statistics about those trips.

I’ve been interested in using this data to create visualizations of the service. I have created a number of animated maps (uploaded to Youtube) that track locations of available cars over time.

This is something slightly different: I took in the data for a week of operations, and extracted all locations of available cars, plotting them on a single map. The result is an indication of use and demand for car2go service within each city’s operational area. Some interesting patterns emerge: correlation with residential and commercial density, impact of parking regulations and age of service.

Composite of unlabelled car2go data for four Canadian cities