Usman Haque (architect and director, Haque Design + Research) and founder of Pachube pointed me to this image from T.R. Oke’s book, “Boundary Layer Climates” (original photo source Prof. L. E. Mount’s The Climatic Physiology of the Pig) to explain his approach to the “software” of space.
My focus as an architect has always been to consider what I’ve called the “software” of space (sounds, smell, light, temperature, electromagnetic fields, social relationships, etc.) rather than the “hardware” (floors, walls, roof, etc.) as it has traditionally been considered. The image (above) really sums up why I think this is important.
It’s the same piglets, in the same box, but on the right hand side the temperature has been increased. This small change in how the space is “programmed” has dramatically changed the way the ‘inhabitants’ relate to each other and how they relate to their space. This approach to architecture became my challenge: how to translate such strategies into the general architectural discourse and how to bring into reality such possibilities for the construction industry.
“Connecting Environments, Patching the Planet”
Pachube is the culmination of 12 years of work.
“It is now occupying pretty much all my time and will do for the foreseeable future,” Usman told me.
Haque Design + Research is not foregrounded on the Pachube site. And I did not make the connection at first. But when I followed a small link at the bottom, I was soon delving into the work of Usman Haque. Then the penny dropped and I realized that Pachube is not only:
A web service that enables people to tag and share real time sensor data from objects, devices and spaces around the world, facilitating interaction between remote environments, both physical and virtual.
Pachube is also a really big idea.
Ubicomp and the “Software of Space?”
Usman suggested that, if I really wanted to go back to the beginning of the Pachube vision, I should check out the work of Dutch architect Constant Nieuwenhuys and his 1956 proposal for a visionary society, New Babylon
Constant Nieuwenhuys is certainly an inspiration for Pachube. He envisages a globally connected architecture, built by its inhabitants – configured, reconfigured, reappropriated…
For a more contemporary reference, Usman noted there are lots of overlapping concepts with Adam Greenfield’s work. Adam is head of design direction for service and user-interface design at Nokia. see Everyware: The dawning age of ubiquitous computing, and Urban Computing and its Discontents to understand more about the vision Adam Greenfield has been developing.
The City… takes everything explored in Everyware as a given, and a point of departure.
It assumes that emergent technologies like RFID, mesh networking and shape-memory actuators…will simply be part of how cities will be made from now on…
The Pachube Team
The Pachube Team – Usman Haque (creative director), Chris Leung (EEML developer), photoshopped laptop: Chris Burman (“example-maker”. e.g. SL code and Google SketchUp plugin), Ai Hasegawa (graphic designer), Sam Mulube (technical producer and website development).
Also, with Bruce Sterling as a “visionary” adviser and other luminaries involved, Pachube has some brilliant guiding lights. Usman pointed that many people have “have helped, prodded, nudged and advised along the way!”
Pachube is not just a social networking project for sensor data.
Pachube evolved out three strands of thought:
1) the geographical non-specificity of architecture these days as people live their lives in constant connection with people in remote spaces
2) a desire to open up the production process of “smart homes” in reaction to current trends for placing the design and construction process solely in the hands of knowledgeable others.
3) an emphasis on contextually specific “environments” rather than object-centric “sensors”
Sensor/actuator integrations are a part of what Pachube is about (also see Peter Quirk’s in depth post on the strong connection between virtual worlds and sensor networks), and an interest in home automation and energy management is giving a lot of early momentum to Pachube.
But Usman makes clear Pachube is about “environments” rather than “sensors.” “An ‘environment’ has dynamic frames of reference, all of which are excluded when simply focusing on devices, objects or mere sensors” (Usman explains this in depth in the interview below). A central part of Pachube is the development of the Extended Environments Markup Language.
Extended Environment Markup Language
Pachube came about as a direct attempt to enable the production of dynamic, responsive, conversant ‘environments’.
The Extended Environments Markup Language (EEML) (which is the protocol around which much of Pachube is based) is being developed to make the idea of “dynamic, responsive and conversant environments” a reality. It works with existing construction standards like Industry Foundation Classes (IFCs), but exists to extend them to account for dynamic, responsive and, dare I say it, conversant buildings.
A key member of the Pachube team doing EEML development is Chris Leung. Haque Design + Research is industry sponsor of Chris’ doctorate that:
investigates how Architectural and Engineering consultancies can use advanced imaging, sensing and visualisation technology to capture, record and playback the responsive behaviour of built Architecture in response to its environment as a decision-support tool to meet this unique challenge.
Usman explained to me the full vision for Pachube is not yet fleshed out on the web site (so read the full interview!), and this is in part because the focus has been on building a backend capable of handling millions of users.
The business model for Pachube
Usman explained his commitment to an ethically driven business model to allow a diverse group of companies and individuals to transition to the internet of things. Usman emphasizes that one of his chief concerns is to make sure that these technologies of “extreme connectivity,” that will soon be part of every aspect of our lives, are in the hands of all who want to use them.
Pachube is here to make it easier to participate in what I expect to be a vast ‘eco-system’ of conversant devices, buildings & environments.
Pachube will facilitate the development of a huge range of new products and services that will arise from extreme connectivity. It’s relatively easy for large technology companies like Nike and Apple to transition into the Internet of Things, but Pachube will be particularly helpful for that huge portion of smaller scale industry players that *want* to become part of it, but which are only now waking up to the potentials of the internet — small and medium scale designers, manufacturers and developers who are very good at developing their products but don’t have the resources to develop in-house a massive infrastructure for their newly web-enabled offerings.
Basically, having built a generalized data-brokering backend to connect physical (and virtual) entities to the web, others can now start to build the applications that make the connections really useful.
An Inspired Community of Early Adopters and Business Visionaries
What attracted my attention to Pachube, at first, was the small but highly energized community of early adopters I noticed experimenting with Pachube. Nigel Crawley @ni), and James Taylor, (@jtonline) were some of the first to plunge in. Rick Bullotta, Usman noted, has been very active in the community forum bringing much-needed automation expertise to the conversation. Pam Broviak (@pbroviak) is an early Second Life adopter. And Matt Biddulph (CTO of Dopplr) was the first non-Pachube person to get a feed up!
A very active early adopter is Carl Johan Rosen wrote an openFrameworks addon (see here) for Pachube that he presented at the OFLab at Ars Electronica Festival.
After the first inaugural HomeCamp, where Usman and Chris Burman from Pachube were presenters, (see slides here), I began to notice that people were sending their current cost feeds into Pachube. And recently, it was announced that Pachube has carbon footprint calculation app which:
makes it very easy to take any Pachube feed that measures electricity consumption in watts or kilowatts and convert it into a Pachube feed that shows a realtime estimated carbon footprint for the last 15 minutes, the last hour and the last 24 hours.
The app makes use of international data provided by ‘AMEE – The world’s energy meter’. AMEE provides figures that are specific to electricity suppliers in UK & Ireland and specific to country in the rest of the world.
This app, combined with the Current Cost app makes it simple to monitor your carbon footprint on a day to day basis!
While enterprise and government projects are on the near horizon, Pachube is designed to introduce a DIY approach to ubicomp. Usman said he is “concerned by developments in ubiquitous computing whereby ‘making technology invisible’ equates to placing the design and construction process solely in the hands of knowledgeable others.
DIY City (see the Do-It-Yourself-City Project) is developing a similar vision here in NYC.
Natural Fuse: “A city wide network of electronically-assisted plants.”
I think we’ve really not even begun to imagine the kinds of applications that will be important,” Usman Haque.
Haque Design + Research which still continues, and has a separate team will be involved mostly in the kinds of things it has in the past, but it is “also in pushing development of things that *use* Pachube,” such as the project Natural Fuse, by Usman Haque, Nitipak Samsen (Designer), Cesar Harada (Designer), Barbara Jasinowicz (Producer), was commissioned by the Architecture League & Situated Technologies: Toward the Sentient City and will open to the public in Autumn 2009.
Natural Fuse harnesses the carbon-sinking capabilities of plants to create a city-wide network of electronically-assisted plants that act both as energy providers and as shared “carbon sink” circuit breakers. By sharing resources and information between the plants, energy expenditure can be collectively monitored and managed.
The purpose is to create a collective “carbon sink”, that offsets the amount of energy consumed by the plant owners – a natural “circuit breaker”. If people cooperate on their energy expenditure then the plants thrive (and they can all use more energy); but if they don’t then the network starts to kill plants, thus diminishing the network’s energy capacity, (a full description of natural fuse in the interview below).
The Street As Platform
Image courtesy of Timo Arnall - who is an awesome photographer and mover and shaker in ubicomp. “The way the street feels may soon be defined by what cannot be seen with the naked eye,” writes Dan Hill in his post “The Street as Platform.” Usman comments on Dan Hill’s other “must read” post:
“The Personal Well-Tempered Environment” is full of “fascinating propositions… …they’re relevant to things I’m interested in…
In a summary of his ideas on personal well-tempered env., Dan Hill writes:
A real-time dashboard for buildings, neighbourhoods, and the city, focused on conveying the energy flow in and out of spaces, centred around the behaviour of individuals and groups within buildings.
A form of ‘BIM 2.0′ that gives users of buildings both the real-time and longitudinal information they need to change their behaviour and thus use buildings, and energy, more effectively. An ongoing post-occupancy evaluation for the building, the neighbourhood and the city.
A software service layer for connecting things together within and across buildings.
As information increasingly becomes thought of a material within building, it makes sense to consider it holistically as part of the built fabric, as glass, steel, ETFE etc.
Interview With Usman Haque
Tish Shute: You have been involved in many awesome projects but Pachube seems to be quite a new direction. What are the key influences in your career and the development of your thinking? And, could you tell me more about how your previous work brought you to creating Pachube? Is Pachube a central focus for you and Haque design now?
Usman Haque: To me Pachube is the logical culmination of everything I’ve worked on for the last 12 years since finishing my post-grad architecture studies.
A lot of my work until now has centered around large-scale mass-collaboration interactive “spectacles” involving many thousands of members of the public at once. I found this a good medium in which (a) to explore strategies for collaboration that take account of the granularity of participation (i.e. the fact that different people have different interests, skills and intentions in any participative act); and (b) to work at an urban scale; i.e. in a way that has an effect at the scale of buildings, parks, and streetscapes etc.
Open Burble was a good example of this approach: essentially a framework, composed of 2m carbon-fibre modules, it had electronics embedded in 1000 helium balloons. Members of the public could configure and assemble these, inflate them and then unfurl the complex structure up to the scale of a 15 storey buidling. Finally, by shaking, rowing, twisting and bending a handlebar embedded with sensors (the same as in the Wii controller as it happens), dozens of people at once could have an effect on the Burble’s position and the colours streaming through it.
Along the way I became interested at times in what an “operating system” might mean in the context of architecture (paper, Hardspace, Softspace and the possibilities of open source architecture, 2002 (PDF), particularly an “open source” operating system (Urban Versioning System, http://uvs.propositions.org.uk/ ). I was also interested in developing tools for supposedly “non-technical” people to start building their own interactive systems or environments, hence the release of The “Low Tech Sensors & Actuators for Artists and Architects” pamphlet , co-authored with an old friend, Adam Somlai-Fischer, back in 2005.
An off-shoot of this has been an obsession with trying to rescue the concept of “interaction” from oblivion – I say oblivion because I think the really exciting possibilities of the concept of interaction are being lost because we’re being sold a billion so-called “interactive” devices and gadgets that are, in fact, merely “reactive”. In this, I turn often to the work of cybernetician Gordon Pask, particularly active in the 50s, 60s and 70s in the development of truly interactive systems. (And also a collaborator with Cedric Price, one of my favourite architects).
Which brings me to Pachube, which is now occupying pretty much all my time and will do for the foreseeable future. (Haque Design + Research still continues, and has a separate team — it will be involved mostly in the kinds of things it has in the past, but also in pushing development of things that *use* Pachube, such as the project Natural Fuse ).
Pachube came about as a direct attempt to enable the production of dynamic, responsive, conversant ‘environments’. It basically evolved out of three strands of thought.
The first was the notion of the geographical non-specificity of architecture these days. By this I mean that, for many of us now, “home” is an idea constructed from several places –we live and work in environments composited by networked technology from fragments that bridge huge geographical distances. These environments are resolutely “human” (in the sense of being inhabited, designed and determined by people) yet context-free (because they do not privilege geographical location). I wanted to find a way to “connect” up remote spaces, much like Remote Home and a whole range of other projects had done, but in a generalized way so that it would be possible to keep adding to the ecosystem of connected environments on an ad hoc basis; a global architecture if you will.
The second strand of thought came from the desire to open up the production process of “smart homes.” I’m concerned by developments in ubiquitous computing whereby “making technology invisible” equates to placing the design and construction process solely in the hands of knowledgeable others. Whereas it’s still possible more or less to do DIY on your home, if many ubicomp technologists had their way it would become less and less possible simply because of the complexity of reverse-engineering such closed-systems. It’s already a problem with larger buildings: service companies go out of business, proprietary skills or tools disappear and complex lighting and sensor systems remain unused. So, with Pachube I wanted to help foster a more open way of developing the discipline: to embrace the concept of the maker, and to help people negotiate their technological future.
Reconfigurable House, an environment constructed from thousands of low tech components that can be “reconfigured” by its occupants.
The final strand of thought relates to Pachube’s emphasis on “environments” rather than “sensors.” I believe that one of the major failings of the usual ubicomp approach is to consider the connectivity and technology at the object-level, rather than at the environment-level. It’s built into much of contemporary Western culture to be object-centric, but at the level of “environment” we talk more about context, about disposition and subjective experience. An ‘environment’ has dynamic frames of reference, all of which are excluded when simply focusing on devices, objects or mere sensors. If one really studies deeply what an ‘environment’ is (by this I mean more than simply saying that “it’s what things exist in”), one begins to understand that an environment is a construction process and not a medium; nor is it a state or an entity. In this I would refer to Gordon Pask’s phenomenally important text “Aspects of Machine Intelligence” in Nicholas Negroponte’s Soft Architecture Machine though it makes for extremely tough reading (Negroponte compared it in importance to Alan Turing’s contributions to the computer science discipline).
Ultimately, though, Pachube is here to make it easier to participate in what I expect to be a vast ‘eco-system’ of conversant devices, buildings & virtual environments. Pachube will facilitate the development of a huge range of new products and services that will arise from extreme connectivity. It’s relatively easy for large technology companies like Nike and Apple to transition into the Internet of Things, but Pachube will be particularly helpful for that huge portion of smaller scale industry players that *want* to become part of it, but which are only now waking up to the potentials of the internet — small and medium scale designers, manufacturers and developers who are very good at developing their products but don’t have the resources to develop in-house a massive infrastructure for their newly web-enabled offerings. Basically, having built a generalized data-brokering backend to connect physical (and virtual) entities to the web, others can now start to build the applications that make the connections really useful.
Tish Shute: You mentioned that both Bruce Sterling and Gavin Starks (AMEE) have given input on Pachube. Can you describe any specific ways they (and others?) have influenced the evolution of Pachube? You mentioned the concept of “engaged responsible spime wrangling” when we talked on skype?
Usman Haque: Yes, I am very grateful to a whole bunch of people who have helped, prodded, nudged and advised along the way!
I asked Bruce to be a “visionary” adviser because he was one of the people early on to envisage the concepts and ramifications of “spimes” (his neologism for ‘space-time objects’). While I agree that “spimes” are directly relevant, what I found most important from his conception was the concept of “wrangling” – being actively and productively engaged and responsible in the development of spimed environments. I think it was a crucial leap: to talk about “wranglers” rather than “end-users”. So the kinds of questions I’ve turned to him for regard how to nudge people away from being “end users” and towards being “wranglers”; and about how to transition from being a “hacker toy” to “major infrastructure”. He had some great (and invaluable) responses, of which one of the most important to me was something he said in email: “…I think total openness is fatal. It’s like lying in a blazing sun under a sky full of vultures, naked. It’s also rather rude, like babbling anything or anything that flies into your head and still expecting people to pay attention.”
Gavin Starks and also Dopplr’s Matt Biddulph have been sort of “friendly neighbours” to Pachube: they’ve made some great introductions and I turn to them often for advice on being a London start-up. What’s been really useful for me is that they are active in a related area and have directly useful advice: Gavin, of course, since he’s involved in metering the world’s energy; and Matt perhaps less tangibly in his day job as Dopplr’s CTO but more so in his active Arduino-enabled social life!
One very important Pachube advisor has been Dr. Paul Pangaro, who has previously been CTO at a number of technology startups, and brings vital experience from his time at Sun Microsystems as Senior Director and Distinguished Market Strategist. (Oh, and he’s also a former student and collaborator of Gordon Pask’s!) He has been very helpful in developing a viable business model in conjunction with my brother Yusuf Haque, who, with his experience in raising capital for startups, has led the fundraising process.
Of course, direct daily input from the Pachube team has been vital to the development of the project, and without Chris Leung (EEML development) and Sam Mulube (backend development) it would be a very different thing indeed!
Tish Shute: Now the emerging internet is the world as a networked, enhanced virtual/reality environment – sorry about the inadequate terminology, but as you said “the distinction between real and virtual is becoming as quaint as the distinction between mind and body”. You are participating in the Sentient City exhibition organized by the Architectural League of New York for September 2009.
Could you explain more about the Sentient City project and what your contribution Natural Fuse which uses common house plants, energy-monitoring sensors, and Pachube to create “a city-wide network of electronically-assisted plants that act as carbon-cycle circuit-breakers in much the same way as conventional electrical circuit-breakers do…..” is about?
Usman Haque: Situtated Technologies, founded to explore the impact of “situated” technologies (i.e. locative media, etc.) in urban spaces, kicked off with a symposium organised by Mark Shepard, Omar Khan and Trebor Scholz and supported by the Architecture League of New York a couple of years ago, and continued through a series of pamphlets (the first by Adam Greenfield & Mark Shepard; the second by me and Matthew Fuller; the third and fourth by Benjamin Bratton & Natalie Jeremijenko and Laura Forlano & Dharma Dailey). This is now culminating in an exhibition, “Toward the Sentient City”, opening in September 2009, as a public manifestation of many of the concepts raised over the years.
Natural Fuse, a project funded by the Architecture League to be part of that exhibtion, is really a Haque Design + Research project rather than Pachube project alone. It came about for two reasons. The first was because we had been investigating for several months many different ways to use plants and vegetation in interactive architectural design: as living walls, as responsive systems, as visual and olfactory indicators, as passive ventilation — fantastic research undertaken predominantly by my invaluable production assistant Barbara Jasinowicz. We were particularly interested in energy creation and monitoring and had made a number of (unsuccessful) proposals to develop building systems based on plant interaction. The second was because I wanted to have a good demonstration project for Pachube: a system that was not just end-to-end single-point communication, but one in which the system increased its efficiency over time through more and more geographically-dispersed connections. So Natural Fuse developed through a series of conversations with a very intelligent and witty designer Nitipak (Dot) Samsen who was then an intern and who will now lead design work along with Cesar Harada (similarly intelligent and witty!).
Briefly, the point of Natural Fuse is to use networked plants, based on the Arduino ethernet platform, to harness the carbon-sinking capabilities of plants to create a city-wide network of electronically-assisted plants that act both as energy providers and as shared “carbon sink” circuit breakers. By sharing resources and information between the plants, energy expenditure can be collectively monitored and managed. The purpose is to create a collective “carbon sink”, that offsets the amount of energy consumed by the plant owners – a natural “circuit breaker”. If people cooperate on their energy expenditure then the plants thrive (and they can all use more energy); but if they don’t then the network starts to kill plants, thus diminishing the network’s energy capacity. Of course, the network functionality is enabled by Pachube. The plan is to distribute these to some households in New York and offer plans and downloads for people to build their own as well.
Tish Shute: You describe Pachube as linking environments not just sensor to sensor (as sensorbase.org does) – an environment for Pachube could be a web page. An essential concept in Pachube is the concept that anything could be an environment and such environments are treated equivalently with EEML. You describe EEML as a protocol that sits comfortably with existing building protocols “what it brings to the picture is the ability to describe buildings that change.”
How will EEML change our understanding of architecture and enable the view of architecture that “includes smells, sounds, light, electromagnetic fields – buildings as dynamic and changing?” (Prasad Passive House?)
You describe EEML as straddling and designed to work alongside IFC construction industry format. Who is involved in the creation of EEML? Could you explain a little bit how it is different from SensorEML? You mentioned little has been done re post-construction evaluation of buildings. How will EEML enable buildings to share strategies (for example on energy consumption) as you put it?
Usman Haque: The Extended Environments Markup Language (EEML) (which is the protocol around which much of Pachube is based) is being developed to make the idea of “dynamic, responsive and conversant environments” a reality. It works with existing construction standards like Industry Foundation Classes (IFCs), but exists to extend them to account for dynamic, responsive and, dare I say it, conversant buildings. In the perhaps prosaic world of construction, this helps to facilitate a number of architectural requirements such as post-occupancy evaluation, realtime site-based environmental feedback at the design phase and simulations that synchronise with realworld installation. With EEML and Pachube you’ll be able to start working with, say, an Autocad model at the design phase, and include *real time* environmental data from the site, as well as to model expected sensor and assumed energy consumption data of the design; use the same model during the construction phase (because it will translate fine to standard modelling descriptions), and keep working with the same set of information even after the building is occupied and running — making it a whole lot easier to learn from the design and maintenance processes than it is currently.
At the same time this does not exclude the possiblity of talking about “sensors” (as SensorML wants to), but we are more easily able to consider, say, the dozens of different ways that different clients will want to address, access or search for those sensors; the changing contextual motivations for actually processing sensor information; and the capacity for flexible sensor ontologies — where you don’t need to know from the beginning everything you’ll be looking for once you’ve recorded mountains of data.
We can consider, equally as ‘environments’ a mountainside, the interior a building, the context of a webpage, the internal status and external context of a mobile device, the interactions within something like Second Life.
As a result of this conception of “environment” we remove the need for a distinction between “real” and “virtual”. We can consider, equally as ‘environments’ a mountainside, the interior a building, the context of a webpage, the internal status and external context of a mobile device, the interactions within something like Second Life — all these are environments and can communicate with each other on equivalent terms. More importantly a single “environment” can be expressed as a snapshot in time; or it can be expressed as a sequence of many snap shots over several years.
One very important thing we’re looking at now is how to transition the protocol from something that is status-based, to something that can express transactions, goals and processes. We’ve just started looking at how RDF and machine tags might help in this, largely spurred on by perceptive comments from one of my favourite designers, Toxi, a.k.a. Karsten Schmidt.
Tish Shute: You mentioned that you see “smart” buildings and “smart” cities as environments not just a collection of devices? On the Pachube web page there is a chart describing potential interactions between entities (one to one, one to many, etc.) but you do not give many pointers to how two unrelated objects that are connected would derive any value out of the connection…could you give me some examples of the kinds of use cases (Natural Fuse is one of course!) and interesting new opportunities to create shared value that Pachube will enable?
Usman Haque: Yes, I recognize that the Pachube website information leaves a lot to be desired…! Apart from a whole lot of conceptual information that’s missing, there are a number of undocumented API features that nobody has yet uncovered!
Well, in answer to your question: much of it is intuition – I don’t know exactly _how_ it will be valuable but I do expect the community to find ways to make such seemingly disparate interoperability valuable.
To make a prosaic example: say, (once privacy options are introduced) that a manufacturer creates a Pachube input application, like an electricity meter that automatically charts on Pachube. There is a certain benefit to its customers in being able to monitor their usage over time and to compare their usage to the aggregation of others in a similar class, but anonymised. Say that someone else has produced a Pachube output application like a mobile phone Pachube viewer. Now the electricity meter users can use this new output application as an extension to be able to monitor their consumption on a mobile phone. Now, imagine if someone else develops a new product, a networked lamp — it would now be very easy for that designer to write a little app to make the networked lamp switch on (or change brightness) according to the electricity consumption, even remotely. The point is that the more input and output apps are added the more valuable they each become.
Scattered House, like Reconfigurable House, but spread throughout various cities in the world to demonstrate the implications of designing environments and buildings in the context of family diasporas and ubiquitous ad hoc networked connectivity.
Part of Pachube’s emphasis, in not making specific connections more important than others, is that the community can develop new types of connection. So, while of course it makes it relatively simple to create remote control connections between seemingly unrelated entities (like mobile phones and houses; or web pages and furniture); and it makes it relatively simple to connect up environmental conditions from the physical world to seemingly distant Second Life (or, more interestingly to me, OpenSim ) which can make it a more viable interactive environment; and it makes data aggregation and comparison possible between wide ranges of energy consumers to facilitate aggregation analysis; but, the point really is to make it easy for people and companies to build in this kind of connectivity and invent new uses.
Through my close association with The Bartlett, University College London’s architecture school, I hope to develop some particularly relevant use-case scenarios for the architectural industry. I think we’ve really not even begun to imagine the kinds of applications that will be important, though I guess Natural Fuse exemplifies the kind of approach I would like to see in Pachube-enabled applictations: one in which the collective/hive experience contributes towards some end goal, to make it possible to create a “wikipedia of environments” as opposed to a web-based Wikipedia – it’s not that I necessarily want to create these things myself, but rather I want to make it possible to create such things.
Tish Shute: You mentioned that you hope Pachube to be the place to connect smart products – product to product communication? Also you mentioned that you would like to have a way that smart products can self register with Pachube. While all feeds are public now, you are going to create groups with different levels of privacy. Both of the aforementioned features would enable more business applications for Pachube. But could you describe the business model for Pachube?
Usman Haque: Essentially, there are three facets to the business model. The first takes a cue from Flickr in recognising that there are those who would like a more sophisticated set of services as “professional” accounts. The second is to be able to provide a set of tools and applications for medium scale manufacturers and developers who want to web-enable their offerings, who will be able to take advantage of the growing repository of Pachube.Apps and add-ons, and who want the convenience, security and economy that Pachube will be able to offer. The third approach is to become more directly involved in large-scale urban infrastructure projects. There is a fourth facet, but we consider it the killer so I’m keeping quiet for the moment….
So yes, in order to make all these things more useful we’ll soon be introducing a range of privacy options on feeds, the ability to create “aggregates” from collections of feeds, and the possibility of groups, organised around feeds. Another thing we’re hoping to introduce soon is open environment-level tagging, so that anyone will be able to tag environments, though there will be a way of evaluating the importance of any given tag.
Tish Shute: I know you mentioned that you are trying to find ways to find tools that allow people to contribute to their environment. There are a number of projects aimed at providing tools that will help people/business to reduce their carbon footprint – The Carbon Account, AMEE, Wattzon, Onzo Is Pachube working with any of these projects and how?
What are the most interesting ideas in this area of changing our relationship to energy consumption emerging from Pachube?
Usman Haque: The carbon footprint calculating industry is getting quite crowded…! So far I’ve particularly appreciated AMEE’s API (which is also used by the Carbon Account, I believe). So one thing we have just released a Pachube.App ‘plugout’ which will take a feed from an electricity meter tagged “watts” or “kilowatts” and convert it into a realtime carbon footprint calculation (driven by AMEE’s international and region- and supplier-specific carbon conversion factors). So it should be really easy to discover how many kilograms of CO2 you generated in the last 15 minutes…. that last hour… the last 24 hours. Here’s a list of some of the feeds that are already making use of this: http://www.pachube.com/tag/co2_last_15_mins
Tish Shute: I know the Aduino community has really taken and interest in Pachube. Who are the early adopters on Pachube? What are the most prevalent use cases you have seen so far?
Usman Haque: It has actually been more difficult than I thought it would be getting the Arduino community interested. This has partly been due to the difficulty of internet-enabling Arduino (until recently adding ethernet access has been a bit of a tough chore). Now that it’s easier to connect up Arduinos, some of the early adopters have been interfacing Arduino to Current Cost meters (alleviating the need for a computer in between); and others have been doing things like tracking temperature, humidity and light level in their homes and offices. Pachube user C4C has been pretty active from early on: http://www.pachube.com/feeds/1284
Tish Shute: Pachube is input heavy at the moment – you mentioned not many accuators are plugged into Pachube yet. You said this is in part because you have focused on making the backend robust and stable before taking a lot of hits. What new directions for Pachube will emerge from enabling the dynamic relationship between sensors and accuators?
Usman Haque: This will be a crucial evolution in Pachube, when we make actuators more evident. It’s input heavy at the moment, basically in the sense of being easy to see the inputs — you add “inputs” rather than “outputs”, so at the moment we have no idea of what’s actually plugged into the outputs unless people tell us! However, we know that there are plenty of outputs because they’re making API requests, we just don’t know what they’re being used for! Once the concept of actuators and output environments get built in to the system then I think we’ll know a lot more about how people are using the system.
To make this easier in the meantime we recently announce the Pachube.apps site, where people can start contributing Pachube ‘plugins’ and ‘plugouts’ — things that can be used by others without needing to code or hack, to create, generate or modulate Pachube inputs and outputs. One of these was Status2Pachube, which turns the online status of AIM, MSN Messenger, Skype or Yahoo! Messenger users into a Pachube input feed (to make it easy to create “remote presence” orbs and such); another was the CurrentCost2Pachube app to make it easy to connect up Current Cost electricity meters as input feeds; all of which can then be used by Pachube output apps, like the G1 Android phone Pachube viewer by Pachube user N4Spd or in the soon-to-launch Pachube2SketchUp plugout which will direct Pachube outputs into Google SketchUp (and by extension Google Earth) in order to generate or modulate 3-d models in response to realtime environmental/sensor data. (Pachube2SketchUp is pretty much finished for Mac OS X — but we’re having difficulty getting it to work on Windows, because of its sometimes pigheaded security measures… we’ll probably release it for Mac OS X alone soon anyway).
Tish Shute: Do you and Haque design expect to go beyond just providing a platform? Will you be producing more interesting applications like Natural Fuse on Pachube? If so, can you tell me more about what you have in mind?
Usman Haque: I keep a clear distinction between my work as creative director of Pachube.com and my work as director of Haque Design + Research. Basically, while Pachube.com continue development of the platform in general, I hope that Haque Design + Research will separately continue creating pioneering interactive experiences, some using Pachube and others not. We have some things in mind, such as the idea of creating an open source building management platform, but that’s all to come later…
Tish Shute: One very interesting project you have been involved in is the creation of “Urban Versioning System 1.0″ which asks “What lessons can architecture learn from software development, and more specifically, from the Free, Libre, and Open Source Software (FLOSS) movement?” Can you tell me more about this project, its goals, and its progress? How Does UVS 1.0 relate to Pachube?
Usman Haque: The Urban Versioning System was essentially an attempt to understand what lessons the “open source” approach in software might provide to the collaborative development of environments and cities. It’s a sort of quasi-license — not yet quite ready to have the status of something like Creative Commons (which nicely suits media and software based creations, but doesn’t suit quite so well hardware and physical things beyond their design files). It’s more of a challenge, a series of constraints that might be applied. It has a link to Pachube, in the sense of encouraging conception at the environment and systemic level — you might call it the manifesto that connects Constant’s New Babylon hypothesis to the reality of Pachube!
Tish Shute: I know that you imagine Pachube scaling up to millions (billions???) of users. But scaling the real time web has proved a challenge (e.g the frequent surfacings of the Twitter failwhale during big events). What are the key points of Pachube’s architecture and design that will enable successful scaling?
How do you see Pachube itself fitting into the FLOSS movement?
Usman Haque: This is a really important question. There are a couple of things we are doing. The first is constantly to assume that we have 20 to 50 times more connections than we actually have… I put a lot of pressure on Sam about making sure about this, so he’s constantly developing, thinking about and testing little things for weeks in advance while at the same time fighting the usual daily little fires that arise The second is that we’re trying to learn from strategies being developed by Vlad Trifa and his group at the Institute for Pervasive Computing at ETH Zurich in Switzerland regarding the development of infrastructures for millions or more entities.
Regarding the connection to the FLOSS movement, there is no specific technical part of Pachube that is currently open source (apart from all the example apps and tutorials of course). However, I find the approach taken by OpenSim and Hypergrid really fascinating: I haven’t given this enough thought to how it might be implemented but I find quite appealing the idea of a multitude of open source and geographically dispersed Pachube-enabled servers with seamless transfer of data connections between them as necessary…..
Tish Shute: I know you have an Android Viewer for Pachube. Android is a landmark for extended/augmented reality, as Wikitude proved, because with its compass mode Android brings together the essential ingredients for extended/augmented reality – knowing who YOU are, WHERE you are, WHAT you are doing, WHAT is around you. It seems Pachube could be a powerful backend to a number of multi-user, mobile augmented/enhanced reality android applications? Do you have any ideas/thoughts on this?
Usman Haque: That’s right — the Android viewer was created by rcreations.com/ a Pachube user — this new platform brings amazing opportunities to mobile devices. I would be really interested to see what I would consider the obvious next step: an app that becomes both a Pachube input and an output feed, one that overlays existing Pachube data, with new context-based, site specific data.
If I was to make a parallel to a Japanese anime, I’m fascinated by Dennou Coil a Japanese anime set 20 years in the future where children take for granted the overlay of the digital world with the physical world. BUT, I’d say that Pachube somehow relates more closely to Furi Kuri in its pataphysical stance and because one of the main characters has a portal to another galaxy in his head…….
Tish Shute: Do you do you see Haque design picking up on the challenge of creating some cool next generation interfaces/GUIs for extended/enhanced/augmented (sorry no perfect term) reality?
Usman Haque: Actually, no, I don’t see this as Haque Design + Research’s core focus going forward. We did some of this early on, getting involved in, for example, the development of a 3d smell interface; and exploring the role of electromagnetic fields on perception of haunted spaces. But these days, in the context of HDR, I’m less interested in making seamless interfaces and more interested in exploring what authentic interaction actually is (whether technologically based or not). I think it’s challenge enough for me to make a light-switch engaging, dynamic and conversant before getting to the perceptual infrastructure that goes on top of it all! HDR will also spend more time exploring passive systems, phase-change materials and plants in the context of the built environment.
Tish Shute: I know there has been some interesting integrations with Pachube lately – Andy Stanford-Clark’s mentioned using MQTT as the feed to get EML data into and out of Pachube rather than over HTTP. He said that’s interesting because MQTT is a much more lightweight protocol, designed for small sensors and low bandwidth / expensive (e.g. cellular) networks… and it’s also true push.. i.e. data is pushed to you directly from the broker (the hub in the middle), rather than you having to ask for it constantly (polling).
Have you opted for MQTT over HTTP polling?
Usman Haque: We haven’t yet implemented an MQTT bridge in part because it has proved pretty difficult. HTTP is quite important for us right now because there’s a whole universe out there using it; from your average web browser, to mobile devices, to ethernet devices and a whole range of languages and platforms — they all work, pretty much out of the box with HTTP. However, what we are exploring instead is being able to interface with Oliver Goh‘s Shaspa project — they’re already in the middle of solving the MQTT-Pachube bridge problem, and so that should hopefully provide Pachube access to and from MQTT devices.
Tish Shute: Chris Dalby just released Pachube Air. Have you had a chance to play with that yet?
Usman Haque: I have indeed! It’s still early days yet, and I know he did it partly just to test the AIR development process rather than solely solving a desperate Pachube need but I’m looking forward to future iterations!
Tish Shute: Peter Quirk felt the Pachube web page positions Pachube as a social networking site focused on data exchange, inviting anyone with an interest in sharing environmental or other data to publish data or construct interesting uses for the data.
What is your response to that?
Usman Haque: Hmm… I don’t really see Pachube as a social networking site. Yes, it perhaps enables the creation of social-networking objects and environments, but in itself and in terms of networking of people that has barely begun yet. Certainly Pachube exists quite comfortably in facilitating mashups and visualisations and other web 2.0 based social applications but I don’t see that as a driving force. I think it would be a mistake also to conceive of Pachube solely as being the storage of machine communication that then gets experienced by people; rather, it can transition quite easily to being solely useful for machine-to-machine communication.
In fact, with recent API releases (which as it happens as of this writing we haven’t announced… it’s now possible to use most of Pachube’s features without ever going to the website: i.e. your Arduino can create feeds, search feeds, edit feeds, delete feeds. Over time, as direct machine-to-machine communication becomes more prominent, it’s quite likely that the website itself becomes less and less important, while the backend becomes the focus of everything.
Tish Shute: I am interested in some of the differences between SensorBase.org’s project and Pachube. Is Sensorbase as more of a data repository (environmental data in particular)?
Usman Haque: The difference I see between Pachube and SensorBase is that while (from what I know) SensorBase is mostly about “write” operations, with later “read” operations (i.e. it’s about being a data repository), Pachube is really “read-write” (i.e. it’s about being both a data repository _and_ a quasi-realtime proxy). Pachube will be able to handle potentially millions of connections, both incoming and outgoing, and as we’ll soon start storing every data point ever recorded, so of course the data repository aspect will be crucial. However, the fact that it *also* facilitates one-to-many realtime broadcasts of that data (and facilitates conversion to a number of different formats: EEML, CSV and JSON now, more in the future) means that the two-way connectivity aspect of it is just as important.
Tish Shute: I know you mentioned something that sounding a lot like Pachube would facilitate buildings and products ability to benchmark and optimize themselves against/with each other?
Usman Haque: Further down the line, I would like to see Pachube able to help two particular processes:
1) to make it straightforward for developers and manufacturers to web-enabled their products and services; and 2) to help building and environment designers create their buildings (by providing access to realtime site data) and also help in the post-occupancy evaluation process — where buildings will be able to talk with each other, share information on energy consumption, resource management or occupancy rates and even “learn” from each others’ strategies. This type of approach has a parallel at the level of individuals (for example, networked electricity meter users who are able to compare and contrast their usage and strategies for conservation). I don’t want Pachube to become the application; rather I want to make it easier for other people and companies to create such applications. So in that sense, yes, perhaps Pachube can be considered an enabler of social networking applications…!