At last! We eventually have a document that vulgarizes the Internet and the Web of Things, oh JOY! I’ll be able to illustrate to mom/sister/grand children (I’ll have to wait a while for that though ) what I’ve been doing for the last 7 years of my life without having them go like: “hmmm oooookayyyyyy”! The one and only problem: the article is in … French. Désolé!

(Source: SVJ)

When Olivier Lascar, from Science et Vie Junior asked if I would be interested in participating to an article about the Internet of Things targeted towards teens I just couldn’t resist, especially since, as a kid, I never missed an issue of the magazine! A couple of interviews hours later and here we go: si vous parlez Français, je suis sûr que vous allez comme moi aimer cet article. It is a savory mix between vulgarization and facts, something that anyone (I believe) can more or less relate to, with plenty of well picked examples. The magazine is still on sale (SVJ 268), so get a printed copy. If you can’t, SVJ provided us with a free PDF version for our readers: L’Internet des Objets, SVJ 268

Remarks and commentaires are very welcome, as comme toujours!

When Massimiliano Ventimiglia (aka. Max, from H-art), first asked me to give a keynote at the BTO (Buy Tourism Online) 2011 conference, I was rather puzzled: what can the Web of Things bring to tourism? What innovation can we fuel in this rather distant field?

Well, after several brainstorming sessions with the crew at Evrythng, we had so many application ideas that I had to filter most of them in order not to overload the talk!

Not convinced? Well then make sure you watch the video below (I’m starting, in English, at 5:58:00 but if you understand Italian make sure to listen to the other talks in the session!):

or at least have a look at the slides:

Any other ideas of how we could contribute to Tourism 3.0? Let us know below

A while ago, in an interview for Postscapes I was talking about a start-up, good friend of ours and spin-off of our research group at ETH which was building plant monitoring sensors. I had the chance to test them and was rather amazed by this practical, truly Web of Things type of project. They are just about to ramp-up production of their first hardware product – a WiFi Plant Sensor. Internal sources told me it’ll be launched in Spring 2012 but we’ll keep you updated on this one.

Meanwhile, the guys are currently launching a Web version of their plant monitoring iPhone App. It’s currently in private beta, but we have invites for 50 Web of Things readers. Just visit my.koubachi.com and enter the code WOT2011. So WoTters and plant lovers, make sure to check it out!

To get a taste of it, check the video of the neat iPhone app below (@Koubachi: How about an Android version? Pleazzze!)

At last a slightly geeky post ! A few days ago I was at Google Zurich (GTUG) to present a more technical remix of a talk I originally gave at Jazoon 2011.

In a nutshell, the talk was about how HTML5 WebSockets would soon be ready for pushing data to mobile phones in a standard way (and possibly soon to/from any embedded device?). In a Web of Things context, we used this at the MIT Auto-ID labs to push data “directly” from RFID readers to Android or iOS mobile phones within a few lines of Javascript code (for the client) and 20 lines of Java code (for the server).

In this talk I focused on showing the elegance of using WebSockets for Web of Things applications. Indeed, thanks to the very simple Javascript client library, a WebSocket client is summed up as follow:


var myWebSocket = new WebSocket("ws://URL");
myWebSocket.onopen = function(evt) {
alert("Connection open ..."); };
myWebSocket.onmessage = function(evt) {
alert( "Received Message: " + evt.data); };
myWebSocket.onclose = function(evt) {
alert("Connection closed."); };

myWebSocket.send("Hello Web Sockets!");
myWebSocket.close();


Hard to make it simpler, right? However, the current reality is slightly different. Indeed, as the standard is still evolving, browsers and application/web servers support WebSockets in very different flavours (or just don’t!). Hence, in this talk I was also discussing the use of abstraction frameworks and in particular the impressive Atmosphere framework that deal for you with the current heterogeneous WebSocket support.

However, rather than a lengthy description here, I invite you to watch the talk which was recorded by the great Zurich GTUG crew, enjoy (sorry for the bad-jokes, it was a relaxed event ):

Due to popular demand (I wish ) I also posted the sources here.

And the slides are still available on slideshare.

A side effect of running the Web of Things blog is to get a daily number of “request for articles” (i.e., requests for free advertisement on your blog of my product). Most of them are totally completely and entirely unrelated to the Web of Things (and Vlad has a pretty interesting standard reply-mail for these ;-P) but once in a while you get a little pearl that is definitely worth talking about. We got two of those lately: one being rather serious, the other being awesomely delicious! Let me share the latter with you today and keep the other for later on.

When Johannes Schoening (a good research friend of mine) first mailed me about the project, I had to laugh for half an hour (before starting to wonder what kind of drugs he was on). But then he sent me a package, containing a sample of his invention: the first, Web-connected (ok, through a proxy but still) …. cookies! The idea is so simple, but just so nice: a box, full of ingredients for cooking cookies and containing some eatable QRCodes. These standard codes are resolved to a URL than can then be redirected to any online content through the QKies Website (German only, sorry about that!). Can you think of any better way to invite your friends to your next party or of announcing some happy event to your best (geeky) friends?

QKies – sag’s mit Keksen from r3 media on Vimeo.

Besides being a neat little product there is also one important thing we can learn from it: simplicity is the way to go forward to slowly but steadily bring the Web of Things to the masses! Big up Johannes

Part 1: Cloud & REST | Part 2: HTML5 WebSockets | Part 3: Physical Mashups

A few weeks ago, I started posting a series about the project we were working on while at MIT: applying the Web of Things patterns and blueprints to the RFID global network (EPC Network). Better late than never, here is the last part of the posts series: Physical Mashups.

Physical Mashups are applications unifying the Web of today and tomorrow’s Web of Things. Tech-savvies, i.e., end-users at ease with new technologies, can create Physical Mashups by composing virtual and physical services. Following the trend of Web 2.0 participatory services and in particular Web mashups, users can create applications mixing real-world devices such as home appliances or sensors with virtual services on the Web.

Thanks to the deployment of the EPC software stack in the cloud and the implementation of a RESTful architecture for RFID, we can now implement Physical Mashup editors for enabling users to flexibly model use-cases of RFID infrastructures. Let us think for instance of an Electronic Article Surveillance system (aka EAS). For this use-case, we design new mashup building-blocks:

These modules were implemented as building-blocks a modified version of the nice Clickscript mashup editor. Reducing interfaces of the EPC Network to Web interfaces enables each building block to be implemented with a small amount of JavaScript code. Using these building-blocks and other basic blocks, we can implement several EAS use-cases within a few clicks. As shown in the figure below, the building-blocks of the RFID mashup editor communicate with several components of the EPC Cloud Infrastructure. First, the RFID-reader block subscribes to the t-pusher HTML5 WebSockets push service using a particular reader ID (e.g., exit-gate). As a consequence, it gets pushed all the RFID events for this reader. The EPCIS block is then used to check whether the pushed RFID number (i.e., EPCs) represent goods that were already sold. To check this, the block uses a RESTful HTTP request on our open-source EPCIS Webadapter.

If it is the case, nothing happens. If it isn’t the case (i.e., the goods were stolen), the Video Camera block is triggered. This components represents a Webcam that can be used to take snapshots through a RESTful API. The URI of the snapshot is then sent to all subscribers of a particular topic (i.e., URI) through t-Pusher. As an example we developed a small mobile Web application with Sencha Touch which subscribes to the topic and loads the corresponding image alongside with the EPC number of the stolen good (see mobile phone in the figure below). Such an application can be used to push information about the theft to all staff members in a store.

Once a mashup has been successfully created and tested locally with Clickscript, it can be exported to our Physical Mashup Engine where is it going to be deployed remotely executed. This illustrates well the benefits of transforming every standard in the EPC Network to offer RESTful Web APIs: development is streamlined to Web development and cross-integration with existing services on the Web (e.g., social networks, visualization tools, could infrastructures, mashups) becomes very straightforward.

The full use-case was tested in a lab deployment at the MIT Auto-ID Labs featuring a standard gate (LLRP) RFID reader and an off-the-shelf Webcam as shown in the figure below. The average observed RTT (round trip time: from the reader, to the Amazon Cloud instance, through the mashup engine and finally to the mobile Web application) was around 1 second. However, it is worth noting that this RTT stronlgy depends on factors such as the available connection bandwidth, the type of instances used on Amazon EC2, the current load of the cloud appliance, etc. Since these factors cannot all be controlled this is a real challenge for IoT / WoT applications in the cloud and we are eager to hear about your real-world experiences in the comments!

For more details about the project, have a look at the published paper or the slides below:

Dear all,
In the middle of our thesis-writing, we gave an interview on the Web of Things to the american Discover magazine for a special issue on the invisible earth. The interview just got published and I wanted to share some thoughts about it with you.

Actually it was a really fun interview and came out as a really fun article. No rocket science but a funny, critical and futuristic look at the Internet of Things and the evolution towards the Web of Things. Beyond the fact that David H. Freedman (the author) definitely masters the art of vulgarization, he was asking me a tricky question about half-way in the interview:

What are the killer apps of the Internet/Web of Things?

A simple and not exactly rare question, so I came up with a number of traditional answers taken from our previous work and prototypes such as: drastically simplifying home automation and expending the cross-devices possibilities, making end-user things programming a reality, allowing (real-time) and tracking of every goods on the planet, making cities/transportation/agriculture smarter, linking objects and people through social networks, finding your keys anywhere in the world, etc, etc.

I also gave him a number of links to great startups in the field and briefly described some of their products: Evrythng, IoBridge, ThingWorx, Sen.se, Koubachi, Mirasense, OpenPicus, the Sun Spot crew, etc, etc, etc!

No way! He was still not finding a true killer app in those. My take is that although the world is almost ready for the Web of Things, we (as a community) still have to get a bit more down to earth, thinking beyond platforms about very simple use-cases that we can implement today already and that people can relate to.
Suggestions anyone? Let’s kick off the discussion!

Enjoy the article online as well:

	Read the article online >
The Internet and the Web of Things

As Google recently announced their plans to move in the home automation world with Android at home (and we are still wondering why they waited so long to do it), I thought I would share my view on that. I do believe there are many opportunities ahead for the “home operating system” domain. The combination of cheap, yet powerful networked digital appliances in the house (NAS, networked media players, WiFi routers, etc) along with an extensible application framework, and a market place for buying new applications (or installing drivers, etc) – will be a killer combo for home automation to take off, especially for building management systems (I’m not yet convinced the market is ready for consumer home automation – unless you’re millionaire and want to show off by turning off lights by clapping hands). But I do believe the Web of Things in this vision can be a solid innovation enabler by making it easy to integrate all kinds of devices and develop new home automation mashlets (mashup & applets – does this even exist? or should we call these phy-ma-les = PHYsical MAshup appLEtS? no? ok…. fine…).

But for this to happen, “we need a hub to receive all the sensors” according to a recent blog post. I disagree. We don’t need one hub, we need many hubs. But even more so, we need the ability to establish direct connectivity between anything electronic and applications. Exactly in the same way as one can search and download specific stuff from particular users that have it in a p2p network.

We have been exploring the field of home automation since the early days of WoT, and we have prototyped several versions of a fully web-based “smart home gateways” that allows the integration of heterogeneous embedded devices into high-level interactive, mobile, and event-driven Web applications. Our first iteration was built with Samuel Wieland [4,5] project, and then superseded by Aparat [3,6], done by another former student Vlatko Davidovski with whom we designed a modular framework (based on OSGi) to easily create applications, develop new devices drivers, that supported Web-based messaging (both pubsubhubbub and Comet), microformat-based resource and device discovery over HTTP, among other features. With another student (Andreas Kamilaris) we have designed in 2009 HomeWeb, a Web-based framework for integrating sensor networks on the Web and afterwards extended it to the home automation domain [1]. We also recently published a journal paper on this work as well [2].

As we’re nearing to IPv6 (dooms)day (actually passed it), more and more routers and networks will be switching (or at least supporting) it, and this will pave the way to better adoption and ripening of the market for Wi-Fi and other IP-enabled consumer electronics. On top of this ecosystem of interconnected devices, a Web-based framework that facilitates development and distribution of applications will clearly unlock the potentials and an open market that drive us away from the currently dictatorial and closed solutions in this domain. At least this is what we hope for.

Clearly, the biggest challenge ahead (and one that I keep seeing only marginally addressed in our research field so far) is security, authentication, and devices sharing. If your whole house is connected to the Web, there are major risks involved as virtually one could entirely control your house (turn off security systems), spy by monitoring all your movements (or hot summer nights via surveillance cameras), or do even more critical things such as lock elevators, close doors, and so on.

The security issue leads us to the following question as to what would be best? An open source security solution that everyone knows and can improve upon by eliminate bugs (thousands pair of eyes are better than a few), with the risk that any hacker can find out exactly how the whole system works? Or a black-box proprietary closed-source system that is hard to analyze and crack, which might be in fact more bugged? Also, how one can combine various modalities for securing that you are really “you” and you are at your home (RFID can hacked, mobile phones can be lost, pin codes can be transmitted). Also, what will be the role of biometric ID solutions (retina scanners, etc)? As long as authentication data is sent by an application over the network, then it can be forged with another “software emulation”, how this could be prevented?

We would love to have your opinion on these questions and feel free to join our discussion in the comments (or on our LinkedIn or facebook pages). We’d really appreciate if you would share with us projects and services that you think can solve this issue.

1. Andreas Kamilaris, Vlad Trifa and Adreas Pitsillides. The Smart Home Meets the Web of Things. Int. J. of Ad Hoc and Ubiquitous Computing, 7(3), 2011. [pdf]
2. Andreas Kamilaris, Vlad Trifa and Andreas Pitsillides. HomeWeb: An Application Framework for Web-based Smart Homes. In Proceedings of the 18th International Conference on Telecommunications, Ayia Napa, Cyprus, May 2011. [pdf]
3. Vlatko Davidovski (M.Sc. thesis at ETH Zurich). A Web-oriented Infrastructure for Interacting with Digitally Augmented Environments.
4. Samuel Wieland (M.Sc. thesis at ETH Zurich). Design and Implementation of a Gateway for Web-based Interaction and Management of Embedded Devices.
5. Vlad Trifa, Samuel Wieland, Dominique Guinard and Thomas Michael Bohnert. Design and Implementation of a Gateway for Web-based Interaction and Management of Embedded Devices. In Proceedings of the 2nd International Workshop on Sensor Network Engineering (IWSNE’09), Marina del Rey, CA, USA, June 2009. [pdf]
6. Vlad Trifa, Dominique Guinard, Vlatko Davidovski, Andreas Kamilaris and Ivan Delchev. Web Messaging for Open and Scalable Distributed Sensing Applications. In Proc. of the 10th International Conference on Web Engineering (ICWE 2010), Vienna, Austria, June 2010. [pdf]

You all know it (or should) we are soon running out of IPv4 addresses. Since we, the Web of Things community, pushing IP literally everywhere, feel a little bit guilty about it we wanted to show our support to today’s IPv6 world day!

Parts of our test-beds at ETH Zurich already run IPv6 (thanks in great parts to our local IPv6 champion, Mathias Kovatsch).

Of course, it is worth noting that we would even add more support to a 6LoWPAN world day, the stripped-down version of IPv6 that supports resource-constrained devices such as Wireless Sensor Nodes but IPv6 is already a good start!
How about a Web of Things day?

Our friends from Oberon microsystems (who designed yaler), just released a tech book (just like we love) about they experience with hacking around the Internet of Things. The book called “Getting Started with the Internet of Things” which is publish by our favorite nerditors O’Reilly Media is available in PDF and paper, and is written by Cuno Pfister.

Learn to program embedded devices using the .NET Micro Framework and the Netduino Plus board. Then connect your devices to the Internet with Pachube, a cloud platform for sharing real-time sensor data. All you need is a Netduino Plus, a USB cable, a couple of sensors, an Ethernet connection to the Internet—and your imagination.

This looks lovely (other than the reference to the thing that starts with dot and ends with net and we’re looking forward to check it out. Especially as they just announced a hosted Yaler instance (try.yaler.net, register here to get an account), I guess to try the examples in the book, so that makes this book even crunchier.

Part 1: Cloud & REST | Part 2: HTML5 WebSockets | Part 3: Physical Mashups

In a recent post, we were explaining how in a project common to MIT and ETH Zurich, we simplified deployments of IoT applications based on the EPC Global standards.

We operated this simplification by applying four of the Web of Things patterns: Cloud Computing, RESTful Interface, Real-Time Web and Physical Mashups.

In the first related post we described how we used Cloud Computing and RESTful Interfaces. It is now time to talk a little bit more about one of the other pattern: the Real-Time Web.

Real-Time Web: HTML 5 WebSockets to Enable Near Real-Time Applications

Early on, experts of the RFID domain asked us to enable mobile or Web clients access to the raw data directly pushed by RFID readers. The challenge here is that the Web was designed mainly as a client-pull architecture, where clients can explicitly request (pull) data and receive it as a response (we have a paper about the matter, here!). This makes uses-cases where near real-time communication is required rather challenging. As an example, a typical use-case is one in which we would like to push events that are being recorded by an RFID reader directly to a mobile browser application for monitoring purpose.

Here, the “Real-time Web”, one of the most recent blueprints of the Web, can be leveraged. The Real Time Web encompasses several new techniques that can be used to push events directly to browsers. We focus on two of these here. The first one, called Comet (also called HTTP streaming or long-polling) is based on the concept of long-lasting HTTP connections and keep-alive messages. While this is supported by most browsers and HTTP libraries, it works by using an existing loop-hole. More recently, Websockets (part of the HTML5 drafts) were proposed. Websockets propose duplex communication with a single TCP/IP connection directly accessible from any compliant browser through a simple Javascript API. The increasing support for HTML5 in Web and Mobile Web browsers makes it a very good candidate for pushing data on the Web.

For the EPC Network, we created tPusher, a service that combines a RESTful API with a Web-socket and Comet server. Using
a RESTful API, clients can subscribe to RFID event notifications for a particular reader by using a URL such as:

http://.../t-pusher/reader/READER_ID

This initiates a Websocket connection with the server on which RFID events recorded by READER_ID will be pushed.

Our implementation is based on the great Atmosphere framework. Atomosphere is a Java abstraction framework for enabling push support on most Java Web servers. One of the advantages of this approach is to be able to deploy tPusher on recent Web Servers such as Grizzly, which are highly optimized to push events on the Web because of their usage of non-blocking threads for each client. In order to support browsers or other clients that do not support HTML5 Websockets yet, we use a client-side abstraction Javascript library called Atmosphere JQuery Plugin which falls back to a Comet connection in case Websockets are not supported by the client.

To better understand the impact of tPusher in the context of RFID apps let us talk about our demonstration: When setting up RFID readers or maintaining existing deployments it is valuable to have a direct feedback of the tags observed by a particular reader in order to monitor the manufacturing process or to debug the readers. In the current implementations of the EPC software stack this would require to use and configure a (expert) monitoring tool such as the Fosstrak LLRP Commander on a desktop computer. Thanks to the RESTful interface to the Real-Time Web capability of tPusher, the tags observed by any reader can now be directly pushed to any browser or HTTP library.

We developed as Mobile Web page that can display them in a user-friendly manner. The page uses HTML5, Javascript with the Atmosphere JQuery Plugin. All code required for such a page to subscribe to events pushed by readers through tPusher and display them fits within 5 lines of Javascript. The code is shown below:


// called whenever an event is pushed :
function callback(response )
{alert(response.responseBody + response.transport) ;}
// subscription to the events of reader "exit1 "
$.atmosphere.subscribe (
"http://EPC_CLOUD_APPLIANCE/t-pusher/reader/exit1" ,
callback , $.atmosphere.request =
{transport : ’ websocket ’ }) ;

Add some bits of Sencha Touch HTML and CSS and you get a nice, user friendly mobile Web application within a few hours of work. The app does not require any installation (just access a URL!) and works accross mobile Web browsers (e.g., iPhone Webkit, Android Webkit / Firefox mobile, etc.)
.

In a next post we will talk about the last pattern: Physical Mashups.

For those who can’t wait, you can already sneak into the presentation of the full project below.

Part 1: Cloud & REST | Part 2: HTML5 WebSockets | Part 3: Physical Mashups

Since last summer, I had the chance to work at the MIT Laboratory for Manufacturing and Productivity (LMP) in the Auto-ID Labs sub-group, working with the lab associate director Christian Floerkemeier and Prof. Sanjay Sarma. Six month after the beginning of the project we reached a fist milestone and thought it would be good to wrap up what we did there.

The idea of the project is to study how Web and Web of Things blueprints (i.e., architectural patterns) can help to foster the adoption of the EPC Network by making it simpler to deploy and develop upon.

The EPC (Electronic Product Code) Network is probably one of the most comprehensively standardized IoT (Internet of Things) infrastructures: it offers standards that address every steps from encoding unique number on RFID tags, to reading them with standardized readers (LLRP), aggregating events (ALE) to persiting events in their business context and make them available for applications (EPCIS).

Recently, RFID is getting a second youth, its hype phase passed, it is now slowly coming to maturity in a number of applications. A lot of which combine RFID with other sensors and actuators. Not to forget the recent announcements of Google to boost the adoption of NFC (Near Field Communication, another type of RFID tags) by adding native Android OS support for NFC readers embedded in mobile phones (e.g., in the Nexus S).

However, while the adoption the hardware (EPC tags and LLRP readers) is progressing significantly, the adoption of the software standards is yet to take off especially for SMEs.

We believe that part of the reasons for this lack of adoption is the complexity of EPC Network infrastructures. As an example, the leading open-source implementation of the EPC software standards, Fosstrak, requires a total of 12 software components to be installed, configured and maintained. This was our starting point: what if Web and Web of Things architectural blueprints would make the EPC Network simpler to deploy, maintain and develop upon.

After looking a little more a the pain-points of EPC Network deployments we discovered that we could help on at least three of them with Web (of Things) remedies. We came up with 4 different remedies. In this post we look at two of them and will look at the others in a next post.

Cloud Computing and Virtualization to Reduce Installation, Configuration and Maintenance Costs/Hassle

We used virtualization (sometimes called Private Cloud) to create a development virtual machine, instead of hours of installation, the EPC dev virtual machine lets you test and develop with the EPC software stack within a few minutes.

We then used Cloud Computing (Utility Computing in a Public Cloud) to create an Amazon EC2 instance of a whole EPC back-end called EPC Cloud Appliance. Instead of weeks of installation by domain-experts, you now

1. buy an (LLRP) standard reader,
2. log onto Amazon EC2, select the EPC Cloud virtual machine fire it up on any number of appliances and off you go, you are ready to create your RFID applications, backed by a scalable, standard, EPC software infrastructure.

RESTful Interfaces to Simplify Application Development

Next, we wanted to simplify the currently rather complex interfaces to enable new types of apps using the EPC Network such as mobile apps, apps on sensor nodes or Web applications. The pattern we used for this is REST. Like in most Web of Things projects, we developed a RESTful architecture for the EPC Network in order to provide interfaces to RFID data and devices that are lightweight, easy to use, and easy to integrate with existing services on the Web.

Our first step in this space was to RESTify the information service of the EPC Network (the EPCIS) in a component called: EPCIS Webadapter as described here open-source software framework here. Using the Webadapter, every tagged product, reader, location, etc. gets a unique and resolvable URL.
Try it for yourself on live data by clicking the link below:
restepc.webofthings.com/location/urn:ch:sap:regensdorf:frc/reader/urn:ch:sap:regensdorf:frc:shopfloor/time/2010-12-28T12:23:28.000Z/event

With this interface, RFID data can be consumed by any Web client such as browsers, mobile phones, sensor nodes, etc.

In part 2 of this post we talk about how we used the Real-Time Web and Physical Mashups blueprints to further help easy Web development on top of the EPC Network.

You can also sneak into the presentation of the full project below.

Over the last few years we had the chance (and increasingly have) to meet plenty of WoT researchers but also people who work for companies developing Web of Things software and products. This is the first in a series of posts where want to share with you a few companies and their people that we had the chance to visit and liked a lot.

A few weeks ago I had the chance to visit the Oracle Labs (Ex-Sun Labs) in Menlo Park, California. There I had the chance to meet, live, some of the actors of the Sun Spot project such as Vipul Gupta, Ron Goldman, Pete St pierre, Randy Smith. Sun Spots are wireless sensor nodes that have the particularity to be:

1. Very powerful (for sensor nodes)!
2. Java programmable (end to end, they run the Squawk JVM!)
3. Rather Web of Things “compliant” and friendly

Getting better insights on the fact that the project was more alive than ever (it seems like Oracle, who inherited from the labs, is keen on investigating the Internet/Web of Things) was very nice. They also gave me the chance to have a first look at the latest generation of Sun Spots, that they are shipping since last week (I was even shooting a nice un-boxing video there but in the process of not properly unmounting my SD card I entirely lost it ).

We definitely liked some of the new features such as:

1. A faster CPU (now at 133 MHz)
2. The 8 Mb of Flash and 1 Mb of RAM
3. The tri-colors light sensor
4. The onboard speaker…

This new hardware release goes alongside with a new software release named Yellow, find more info about both here.

Finally, we also were happy to be able to count on the labs support with devices for our Web of Things workshop and hackathon, more about this to come but until then, long live the Spots

Because we don’t like just talking but also doing, we’ve decided to set up an exciting warm-up for our upcoming WoT2011 workshop. I named: a hackathon on social device that will take place on the 11 June 2011 somewhere in San Francisco. In 3 words (okay more than 3):

We propose to create, play, hack, build real “stuff”. Social devices. We will start with a bunch of embedded devices and other electronic things (sensors, robots, urban screens, toasters, etc.) provided by our partners and we’ll ask participants to put them on social networks, to explore how to share them, make them talk to each other, secure them, and see what happens and what can be done. We intend to put in the same room developers/coders, hardware hackers, and interactive designers that will brainstorm on simple projects that can be done in 1 day (and night…) that combine programmable electronics, Web APIs, and social networks along with funny technologies and standards (activity streams, HTML5, OAuth, Facebook connect) and we’ll explore what it means to “publicize objects”. The actual topics that each project will emphasize (from “how to share devices with friends”, to how to “secure access to private electronic appliances”, to “social networks for objects”, how “to fast prototype social networks on mobile phones” etc.) is of course free for each team to decide.

SOOO, we are also looking for partners that would like to: bring some hackable devices, pizza and beers, give us access to some nice APIs or experimental sexy tech we *have* to try (mark zuckerberg, wanna come with some source code?) or platforms, or simply bring some tech expertise. Interested in bringing something to the table (or literally a table… as we don’t know where it’s gonna take place yet, so if you have some big office space with wifi to host a bunch of nerds)? Mail us!!

Register NOW!

Besides the fact that we are big Sun SPOTs fans, we also got increasingly more interested in the OpenPicus platform, not only because the constant motivation of the project founder Claudio Carnevali is impressive but mostly because the FlyPort (the OpenPicus wireless sensor node) is featuring a WiFi module and a Webserver (according to them our WoT community influenced them on that point) which makes it a nice, compliant, Web of Things device.

Yesterday, the OpenPicus project released their free, open-source, IDE which supposedly makes it really easy to develop Web of Things applications backed by Wireless Sensor Nodes.

The team asked us to post some news about the IDE, instead of that, I decided to test it and report here:

1. Got the IDE here. First small decrease of my tremendous motivation: the IDE is .NET/Windows-based, hem, slightly strange choice provided the WoT community is probably 50% mac, 50% Linux (or it least I’d like to believe so), but let’s not be so futile, and simply remove the dust off my XP VMWare virtual machine.
2. The IDE requires the .NET 4 framework which installed smoothly on my VM.
3. Unzip, sorry un-rar (Duh! Ok, let’s download 7 Zip) the IDE.
4. No install required, neat, the IDE starts smoothly. It has a familiar Office 2007 / 2010 look and feel. It’s actually not bad, simple and quite efficient. The code-completion works fine which really helps discovering the OpenPicus and FlyPort API.
5. I plug my FlyPort for the first time in my VM, again it is smoothly discovered as a USB/Serial port, which means the install does not need any additional driver.
6. This video, guides you through your first FlyPort project. The whole process ran smoothly on my VM as well (for people using Linux like me and wanting to use the OpenPicus IDE in a VM, make sure you get a WiFi dongle, as VMWare maps any native WiFi interface of your computer to a wired network in the guest operating system.
7. The video also shows how to deploy the native Webserver to the FlyPort, which takes, in essence, 3 clicks and is entirely customizable so that you can make your services truly RESTful, very neat!

To sum up, I need more experience with the device to really judge it (coming soon!) but it seems like a very good platform for easly prototyping Web of Things applications, very good job! On the drawbacks I would have liked a Java, cross-platform, version of the IDE and Flyport stack rather than a .Net one but I must admit that the IDE’s simplicity and integration is impressive and after all what only really matters to us is the out-of-the-box ability to hide the FlyPort’s internal language behind a Web API (more to come on that part as well, I’ll test the FlyPort against the Web of Things cookbook!).

No breaking news in this post, but we were just informed about the fact that one of our articles was in the special selection of Service Oriented Computing of IEEE Computing now as well as Featured on ZDNet.

We never really talked about this work because it largely discusses WS-* services (DPWS in particular) which are also known as “evil-services” by the RESTifarians

We actually began our IoT journey with DPWS, were quite frustrated with it, but it evolved a lot since then, became an official OASIS standard, and thanks to the crew of WS4D became a lot less buggy and a little less heavy.

While we still stick to a more pure Web-approach because of its simplicity and ease of integration with the existing and fast growing world of the mashable Web, in this paper we were trying to federate them both and to explain how they could be leveraged to create an composable Intranet of physical services in an company.

The paper discusses the differences between REST and DPWS, points at several features of DPWS that are addressed in limited ways by REST (and vice-versa) such as service discovery: you can discover REST resources by getting their URI (HATEOAS but how do you get that URI in the first place, how do you resolve it?) and proposes the use of small local units, called LDUs (Local Discovery Units) to enable the discovery of both DPWS and REST services.

It also discusses how to improve the “searchability” of services for developers so that they can find the service they look for in the real-world context they want. For this it uses the LDUs (e.g., services inherit from the location of LDUs) as well external services such as Wikipedia, Google, or domain-specific portals, to extend the available semantics with extracted keywords, without overloading the devices (e.g., sensors) themselves with heavy semantics (btw, sorry but we actually were forced to patent the process )

Finally, I’d like to point out that DPWS papers are welcomed to WoT 2011, we actually had some at WoT 2010! We are especially interested in report of experiences on how can DPWS and REST coahbit, because after all, nothing prevents you from using DPWS-enabled devices if you need some of its features but design nicely interoperable RESTful APIs on top.

Lately we’ve been quite busy working on different book-chapters. As we finalized one of them I wanted to share it with you. This chapter is the draft version (before final edition as this is the one we are actually allowed to publish here, for the final version you should buy the book!) of a chapter the “Architecting the Internet of Things” book, edited by Mark Harrison, Florian Michahelles and Dieter Uckelmann.

Quite an interesting book filled with chapters on how to make the Internet of Things a reality, ranging form how to build the infrastructure to how to make it profitable. The book will be published very soon by Springer and we’ll make sure to update you whenever it’s out!

Meanwhile please enjoy the draft of our chapter, which is basically something we wanted to come up with for a long time: a cook-book on how to implement the Web of Things in your daily prototypes and/or products. This chapter was written in a way that it is accessible to a broad range of people not necessarily familiar with the core of modern Web-technologies.

Writing it was a nice adventure from us as we co-authored it with two of our mentors: Erik Wilde who ensured that the “Web-touch” was accurate, and Fridemann Mattern, one of the fathers of the Internet of Things, who made sure the “IoT-touch” made sense!

In our second talk at IoT 2010 we presented a project we kept warm (and working on) for a little while now: bringing RFID to the Web. Not RFID in the sense of small RFID readers like the nice phidget reader meant for prototyping, but the world of standardized RFID networks and in particular the EPC (Electronic Product Code) Network and its EPCIS (Information Service).

The Electronic Product Code Information Service (EPCIS) is a standard which defines interfaces enabling RFID events to be captured and queried. The query interface, implemented with WS-* Web services, enables business applications to consume and share data within and across companies, to form a global network of independent EPCIS instances. However, the interface limits the application space to the rather powerful platforms which understand WS-* Web services.

In the EPCIS-Webadapter (aka. REST-Adapter) project, we propose seamlessly integrating this network into the Web by designing a RESTful (REpresentational State Transfer) architecture for the EPCIS. Using this approach, each query, tagged object, location or RFID reader gets a unique URL that can be linked to, exchanged in emails, browsed for, bookmarked, etc. Additionally, this paradigm shift allows Web languages like HTML and JavaScript to directly use RFID data to fast-prototype light-weight applications such as mobile applications or Web mashups. We illustrate these benefits with a JavaScript mashup platform that integrates several services on the Web (e.g., Twitter, Wikipedia, etc.) with RFID data to allow managers along the supply chain and customers to get comprehensive data about their products.

You’ll find the paper (btw, IoT 2010 best paper award nominee) here the slides below as well as the project description, source code, and live demo on our new “projects” page. As I moved to the MIT Auto-ID labs to work on this project for about 6 month, there will be more coming, stay tuned!

(btw, thanks to Vipul from Oracle Labs, for coming up with the nice title of this post )

Together with Vlad and Erik Wilde, we’ve been trying since a while to write a scientific paper out of our common technical report that would sum up the founding concepts of the Web of Things. The paper finally got accepted for IoT 2010. This is a good sign because it emphasizes the fact that the Internet of Things community is now really looking into Web standards as a candidate common integration bus for the application layer of the physical world. A fact that did not really hold two years ago, when Erik’s attempt to publish a WoT paper at IoT 2008 did not succeed.

In a nutshell the paper is based on the fact that many efforts are currently centered around creating large-scale networks of “smart things” found in the physical world (e.g., wireless sensor and actuator networks, embedded devices, tagged objects). Rather than exposing real-world data and functionality through proprietary and tightly-coupled systems, in the paper we propose to make them an integral part of the Web. As a result, smart things become easier to build upon. Popular Web languages (e.g., HTML, Python, JavaScript, PHP) can be used to easily build applications involving smart things and users can leverage well-known Web mechanisms (e.g., browsing, searching, bookmarking, caching, linking) to interact and share these devices. In this paper, we begin by describing the Web of Things architecture and best-practices based on the
RESTful principles that have already contributed to the popular success, scalability, and modularity of the traditional Web. We then discuss several prototypes designed in accordance with these principles to connect environmental sensor nodes and an energy monitoring system to the World Wide Web. We finally show how Web-enabled smart things can be used in lightweight ad-hoc applications called “physical mashups”.

Enjoy the paper here, feedback is very welcomed!

Below is the current version of the slides I’ll present tomorrow at IoT 2010 in Tokyo:

Warning: this is an extremely technical post! But since this bug drove me nuts for a little while, I do have to expose it to the WoT community

Finalizing the open-sourcing of our framework for making RFID tags part of the Web (more about that here!), I was testing it the whole day on various browsers.

Firefox, fine! Opera, fine! IE, fine! Chrome, what the heck is that page!?

As you might know, a resource in REST is not bound to a format (or representation as they call it). Rather, a well-done RESTful API should be able to serve several representations depending on the client. A mashup client would for instance be better off with JSON rather than XML or HTML. A browser, would rather render HTML or XHTML. To express this wish the client uses a standard HTTP 1.1 mechanism called “content-negotiation” which, by the way, is a nice, standard and rather lightweight system for things and smart gateways to serve different formats.

Now, to negotiate the format it wants, a browser uses an HTTP header field called “Accept” Header, for instance this is what Firefox 3.6.12 sends:

Accept text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8

I.e., “Hello I’m Firefox, a browser, and I mostly speak HTML. I can also understand XML but like it less (0.9).” Nice!

Now, here is what Chrome or any WebKit based-browser (e.g., Safari) will say:

Accept application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5

I.e., “Hello I’m Chrome and I love XML (1, default) like less HTML (0.9)”. Duh! That’s a lot less nice since it means that any well-done RESTful API, that uses HTML and not XHTML as a human representation, will return XML to Safari, and XML (except in its XHTML form) is not exactly as human friendly as HTML!

Now, as an API developer this makes you wish the WebKit developers (i.e., builder of one of the biggest client of the HTTP standard) would have read this example of the HTTP 1.1. RFC:

Accept: audio/*; q=0.2, audio/basic SHOULD be interpreted as "I prefer audio/basic, but send me any audio type if it is the best available after an 80% mark-down in quality."

This might not seem like a huge problem but in fact is extremely annoying and I’m not the only one to complain about it. If browsers do not respect the rules of content-negotiation it makes the mechanism pretty useless…

In our case we found a workaround thanks to Jersey (a great framework for RESTful applications in Java) upon which our RFID framework is based. Jersey support a server-side “qs” (Quality of Source) parameter (not part of the HTTP standard but tolerated and understood by many Web-servers such as Apache). Thus, for each resource producing HTML we add the:

@Produces({"text/html;qs=2", ...})

annotation which means that the server will prefer text/html if the client understands it. Nice, except that this overrides the client wishes. If a client sends:

text/html;q=0.2,application/xml;q=1

Then the server will not listen to the client preference (q=1 for application/xml) and will send HTML since the client understands it.

That kind of bug illustrates it, standards are only as good as the people implementing them, and BIG players (for the records Web Kit is the engine of browsers of any Android OR iPhone smart phone!) sometimes just get lost as well (for the records again, even IE does implement it the right way…).

By the way, if any of you already had this issue please share your workaround!

It’s a known fact that we (or at least) love Sun SPOTs. Not the ones on the sun but the Sensor nodes developed by Sun Labs (now/soon Oracle Labs?) a couple of years ago.

Speaking Java better than any language out there (including French ), when the first fully-natively-java Wireless Sensor Nodes came out you can imagine my joy. Since then I can’t remember a paper we wrote that does not use Spots in its prototype! We worked quite a lot with them, created several stacks to make them “Web-enabled” and RESTful, to make them part of the Web of Things!

When we had the chance to meet part of the Sun SPOTs crew at WoT 2010, they told us they were about to release some software to be able to apply and experiment with the Web of Things concepts.

Well, here we go! The Sun SPOTs now have their own WoT stack. Probably the most important innovation when compared to the already available WoT stacks for the SPOTs (such as ours), is a Nano App Server. Inspired from the Java App Servers, which are basically Web Servers on steroids, it lets you register Web Apps which run on the nodes or on the gateway (i.e., host PC). The Web Apps are then responsible for handling part of the URL subspace (e.g., /…/blink which would be an app for making the SPOTs LEDs blink) and serving the Spots functionality in a RESTful manner.

The Nano App Server also offers support for great functionalities that definitely make sense for such small nodes such as HTTP compression or built-in support for caching!

All of this is best summarized on Vipul Gupta’s blog. Tutorial files and coding exercises are also available on this blog. Last but not least, a presentation guides your through the most important parts and steps, enjoy!

Ok, so we talked a lot about integrating sensor nodes to the Web, then about integrating home appliances to the Web or about integrating industrial machines to the Web.

How about simple, dumb, traditional objects? Well the community is working on it! As an example, one of our latest projects is to Web-enable the global RFID networks (EPC) so that every RFID-tagged object becomes a true citizen of the World Wide Web (see our paper at IoT 2010). I’ll tell you more about this project soon but meanwhile I want to talk about even more dumb objects: those tagged with barcodes only!

We are big fans of barcode scanning. Most of our projects (like the home mashups project) use them as a “bootstrap” for obtaining the entry address of smart things (i.e., the root URL). We are even bigger fans of mobile barcode scanning because, actually, the mobile phone is probably the best interface to smart things out there.
But until today, barcode scanning (and especially 1-D barcode scanning) was a rather painful/frustrating/oh-my-gosh-I-wont-do-it-again process!

Say hello to Mirasense! Knowing the guys behind it, we actually knew about their superior scanning technology a while ago (and could really test it!). Now, they are going live on the iPhone platform with the Scandit free iTunes US Appstore app.

Scandit shows that barcode scanning is about to become a real input modality, a commodity. The app manages to scan almost any barcode in any situation, check it out:

Yeah I know the video looks suspicious and you can show whatever you want on a video. But hey your devoted blogger had the chance to test it live. Still not believing me? Well this is backed by a scientific paper at the IoT 2010 conference. Still dubious? Well just install it then!

While this does not yet address the pure “Web” aspect of barcode tagged object (i.e., how do you create RESTful Web APIs to access authoritative data, traces, etc. about these objects), in their Scandit app, they further integrate the scanner with a lot of different services and information on the Web (BestBuy, social networks, twitter, etc.) turning the shopping experience into a giant and automated data mashup:

Having recently moved from iPhone to Android and feeling sooooo good about it, I just can’t wait for the Android version to come out (apparently it’s planned).

Imagine every home appliance being 1) IPv6 enabled 2) RESTful, imagine the tools you could create on top of such an eco-system!
In particular, imagine the idea of “physical mashups” becoming a reality in our homes sweet homes: creating simple, ad-hoc applications on top of your appliances as easily as you can create Web 2.0 (virtual) mashups nowadays. The dream of every hacker and tech-saavy? Well at least one of our dreams (and part of my Ph.D. proposal by the way )!

Well a dream that we have been trying to demonstrate and implement lately. The outcome is two papers. In the first one, “Mashing up Your Web-Enabled Home” (Bibtex for references is here), presented at Touch The Web 2010 we especially look at the requirements for a home mashups and propose an early framework on which mashup editors can be easily built. We also illustrate the use of the framework and guidelines by means of two concrete mashup editors, one built upon the nice Clickscript mashup tool, one built on Android that let’s you manage the energy consumption of your home from your smart-phone. More in the paper, enjoy the slides below:

In the second one, “Embedding Internet Technology for Home Automation” (Bibtex for references is here, co-authored with Matthias Kovatch and Markus Weiss), we look a bit more at the alternatives. What are the limitations/advantages of the Web of Things when applied to the home environment, in particular when considering a RESTful Architecture on top of IPV6. How does it compare with technologies traditionally used in home environments such as X10 or EIB/KNX.

Ready to mashup your home?!

Some of you might remember/have attended our SXSW 2010 workshop. Well we enjoyed giving it so much that we decided to come up with two brand new proposals for this year’s SXSW!

The Real-World as a Web API is our first proposal:

The world of “physical devices” such as home appliances/electronics, real-time city data, RFID-tagged objects, mobile phones, etc. has long been longing for a seamless and universal integration platform. Out of a great number of heavy-and-not-so-great middleware a surprising one is emerging: the Web! In this presentation we would like to show how Web developers might well be the next generation of real-world hackers. We’ll demonstrate how the current developments in Web standards make it one step closer to the real-world. We’ll show how REST and the light IPv6 (lowpan) protocols fit really well to control most physical devices. We’ll illustrate how the real-time Web (Web sockets, Pubsubhubbub, Twitter, etc.) makes it easy to sense the world and get physical devices to trigger events. We’ll show how HTML 5, Microformats/data, rich snippets and social networks can help us to search and share the real-world. We will finally show how this Web integration and Javascript toolkits (e.g. JQuery, Sencha touch, etc.) enable us to mashup the world on the Web layer as we wish: from configuring our connected homes to building on top of our real-time cities with our mobile phones. The success of books such as “The Next Internet” or blogs such as Web of Things and theinternetofthings.eu emphasize it: the Internet of Things is coming and Web developers are its most powerful actors!

Next, we have a closer look at the city use-case in:

The public infrastructure of our cities are obscure structures whose workings are not accessible to most citizens. What if every sensor in our cities would have a Web API anyone could access in real-time and mashup? Open and easy to use Web platforms that enable efficient integration, processing, storage, and access to the enormous amount of data digital cities generate are increasingly needed, and we’ll explore the various technologies that are making such solutions possible. Furthermore, we’ll go much more beyond the technical aspects of such a platform to address the more controversial implications of such an Orwellian scenario. Hopefully, this session will provide a forum for the different disciplines involved in the design of future cities to establish a common ground for better interdisciplinary cooperation and understanding in this area.

The idea is to concentrate the first workshop on the technology side and the second a little more on the conceptual side, if you want to be able to attend any of those at SXSW 2011 then please vote here: The Real-World as a Web API or here Web Mashup Platforms for Future Programmable Cities. Or better vote for both
Votes are closing Friday 27th of August!

We are organizing the First International Workshop on the Urban Internet of Things at the IOT 2010 conference, at the end of this month, and we would love to invite you all to submitting a demo or a paper.

Unlike the WoT2010 which brought together WoT researchers, we emphasize here concrete applications practical solutions that can be built on top of WoT. We particularly welcome real-world deployments that can highlight the plus/minuses of using WoT as infrastructure for a scalable urban-scale data collection and processing.

We would like to bring closer practitioners in the area of smart cities (industries that build the various components of smart cities such as infrastructure, sensor, software, middleware, hardware, etc), along with researchers in various fields related to networked objects (that’s why we do this workshop in the context of IOT conference), and with architects/designers/urban planners that are in charge of designing the points of contact between citizens and this invisible (& growing) digital infrastructure.

The outcome would be for participants to get to know the latest trends in research/technology (& each other) and at the same time get practical insights about the challenges in building such scalable (city-wide+) infrastructures to collect, process, share and store huge quantities of real-time data from various urban sources. Pretty much like a combination between twitter and data.gov, but for sensor data which emphasizes open access to real-time data streams from cities (public APIs that anyone can access and code with).

As we wanted to avoid a “classic” mini-conf like workshop to enable active participation, we have been preparing a few surprises that will allow you to get your hands dirty and join the conversations and hands-on sessions with world-class experts in this area. More to follow soon.

Also, we are still looking for sponsors that could cover the travel costs of our keynote speaker, so if you know someone or are interested to sponsor us in exchange of some promotion/visibility, please get in touch with us (info@{guesswhat}.com would do).

Read more on the official call for papers/demos.

The OpenPicus community released a wi-fi module called FlyPort. It is a small device that uses the Microchip PIC24F (256K Flash+16K Ram, 16Mips@32Mhz) and MRF24WB0MA/RM WI-FI certified module. FlyPort runs a wireless Stack (TCP/IP version 5.25 from Microchip) and has a 26 Pin connector for easy prototyping. Applications and libraries are open source and can be freely downloaded from the openpicus website. Programmers have full control of the wi-fi module, thus the Flyport can act as tiny Web server and client that can directly interact with other Web resources directly, without requiring a gateway. Besides, this project has a social aim too, they give away free development kits for students and universities that want to develop their applications on this platform, as long as they want to share the code and results with the community (mail us if you are interested by such a kit, or just write in the comments and we’ll get back to you). According to the project’s founder, Claudio Carnevali, the Flyport will be available soon to a wider public for less than 30 Euros each.

We have seen more and more projects around embedded wi-fi modules, and we believe this direction will have a strong impact in making the Web of Things happen. For a few bucks more, every electric appliance out there could host one such wifi module on-board, and coupled with a Web server on it this. For example, companies such as RedPine, GainSpan, ZeroG Wireless (that has been recently acquired by microchip), or G2 Microsystems are among the key players to watch in this area, and I’m sure that we’ll see a proliferation of Web-enabled appliances in the next years [ thou, smart fridge, will u finally become real?? ]

Now that wi-fi chips are virtually easy to integrate in appliances, the next important step to make WoT happen is to also offer a free, easy to use high-level programming environment that would allow people to fast prototype Web of Things applications on top of the wi-fi substrate – just like the Arduino did, but on a even higher level. Instead of learning how to read and write signal to digital & analog pins, developers could interact with these devices simply through a RESTful Web API. After a great discussion I had last october with Massimo Banzi (co-inventor of the arduino), the next stage is clearly a wifi version of the Arduino (nothing disclosed about that yet), which would make it straightforward to also run a Web server on it. I can’t wait for the day this will happen.

[Thanks to Claudio Carnevali for providing us this information and we're looking forward to the evolution of the OpenPicus project]

A few days ago I had the chance to participate to the “touch the Web 2010” workshop.
The goals of the workshop were rather similar to the ones of WoT 2010 however, rather than being hosted at a Ubicomp/Pervasive venue, Touch the Web was collocated with ICWE2010, a pure Web engineering conference.

The most surprising fact was probably how close the two communities are getting. Web people are increasingly interested in embedded/physical/sensor computing, and on the other hand, pervasive people are getting more and more convinced that the Web protocols as not so bad after all (take this paper for instance), at least good enough for a good range of applications. Quite a change of mindset compared to a year ago.

One of the good outcomes of the workshop was the fruitful final discussion. Three big challenges seem to emerge: the discovery of things, the real-time things and understanding the needs for Web-enabled things. Three challenges that were also identified as keys at WOT 2010.

Discovery
We need to look at describing things so that they can be both discovered by machines (i.e. network discovery) and their “services” understood by humans (i.e. service discovery). REST is good, REST is great but it’s raw expressiveness is not enough to understand things. By crawling a RESTful API you can find the resources it exposes, by reading the URIs you can get rough “tags” (e.g. /temperature) describing their nature. But this is not enough for users, neither for machines. As an examples, attendees mentioned the need to generate sense-making UIs on the fly or to customize page rendering depending on the thing one discovers. A simple example of this is Google rich snippets where the search engine renders the page results differently if they embed some semantics. What if Google could render search results for things in a way that helps users interacting with them.

Thus, researchers are exploring ways of better describing things directly inspired from the semantic Web. In “A Triple Space-Based Semantic Distributed. Middleware for Internet of Things” the authors suggest using RDF. In the mashup framework we presented an RDFa based solution to be able to integrated newly discovered devices as mashup actors directly. Those solutions however have the drawbacks of being based on well-know syntax but “proprietary semantics”, i.e. they cannot be understood by One alternative we (and others) currently explore is the use of Microformats which enables to use “agreed-upon” lightweight semantics. Their recent fast-pace expansion makes them even more interesting (I should post about our early experiments with things and microformats here soon!).

Real-time Things
Next in line of the important aspects for a WoT was the need for real-time communication patterns. Not ground-breaking, since this topic has been around WoT architectural discussions since the beginning but the workshop made it clear: client server architectures are great for controlling things, but for monitoring we also need things to be able to push data. Of course, we would also like this push pattern to be as Web oriented as possible. On the REST-side People talked about Atom and especially the latest push based mechanism using it, aka PuSH (or pubsubhubbub). On the more WS-* side, speakers talked about using WS-eventing. We also talked about our experiences with WS-eventing in DPWS (a device tailored WS-* stack) and concluded that it was getting better but still quite heavy for many devices and rather hard to get hands on.
Overall it seemed that this space for still open for further exploration. Speaking of which we also presented a paper at the main conference about a light messaging service for things called RMS (Vlad will tell you more about it here soon!)

Understanding the Needs for Web-enabled Things
Last but not least one really tricky question emerged: “why do we do this?” We propose a re-programmable world where everything is created not as a single purpose object but rather as an API ready for opportunistic applications, but do people want that and why?
Most of the people there believed they do and for various reasons ranging from sustainability (objects have a second life thanks to involving them in new use cases), to customization (things are often not quite the way we want them to be) and satisfaction of DIY (Do It Yourself).
However, raising this question is key and depicted the strong need for better understanding the “mashup space” from an end-user point of view. What would people like to mash in their homes, cities and offices?

As in our project we needed a (quickly setup, reliable, and flexible) backend system to store sensor data, I played around with CouchDB as I wanted to explore a RESTful data store. As a matter of fact, the version 1.0 was released just a few minutes before I installed it. First impression, wow. Sleek, pretty fast, damn easy to use, flexible as any software should be (not the conventional click and run install, but damn well documented installation). I have to admit I’m impressed by the quality of this release, just as much as by the documentation.

I think this is the best option out there to store relatively low-frequency changing data, such as device metadata, information about locations, etc, but I really wonder how it performs for high-frequency data, such as sensor samples. Considering that it is a document store (for JSON data for example), I wondering how it handles the storage of thousands of incoming “documents” per second. This question is certainly worth exploring and I will hopefully be able to share some insights on this question soon.

In the meanwhile, we are looking forward to hear about your experiences with Web-oriented datastores.

After the last draft released in december, the COAP folks just released a few days ago a more refined version of the COAP draft, with additional thoughts on coap-http mapping, RESTful verbs for constrained environments, and pub/sub notifications, and more.

Abstract

This document specifies the Constrained Application Protocol (CoAP), a specialized RESTful transfer protocol for use with constrained networks and nodes for machine-to-machine applications such as smart energy and building automation. These constrained nodes often have 8-bit microcontrollers with small amounts of ROM and RAM, while networks such as 6LoWPAN often have high packet error rates and a typical throughput of 10s of kbit/s. CoAP provides the REST Method/ Response interaction model between application end-points, supports built-in resource discovery, and includes key web concepts such as URIs and content-types. CoAP easily translates to HTTP for integration with the web while meeting specialized requirements such as multicast support, very low overhead and simplicity for constrained environments.

Definitely worth looking at it and try to reuse as much as possible from there in your designs. I’ll be analyzing it soon and give my thoughts on it later.

I gave a few thoughts recently about what the iPad (& iPhone) represent for the WoT.

NIWEA

As our friend Hannes Gassert awesomely summarized it recently, NIWEA (Native Interoperable Web Applications) is the sweetest method to build interactive applications for all things mobile, plus NIWEA feels like it was made for the Web of Things. In a nutshell, NIWEA are simple Web applications (developed only with HMTL/CSS/Javascript) designed to look & feel like a “real” (native) mobile application. This not only provides a great environment to develop easily apps for the iPhone/Pad, Android, Blackberry & co, but in particular it is the perfect platform to fast prototype various interactive applications for the WoT.

What it means for developers is that one doesn’t need to learn cocoa & co. and similar weird & proprietary languages for each target platform anymore. It takes time & money to develop an iPhone app (thus the designers’ nightmare when the client says “me too want iPhone app”). As our colleague Erik Wilde mentioned, many apps in the Apple Store could be implemented as Web apps directly (games are a different story and might need to be native for performance reasons). Besides, HTML5 seems to be a pretty versatile, lightweight, and powerful alternative to Flash, and full HTML5 support on future mobile browsers would be the perfect trick against the lack of support for flash in the iPhone (not everyone seemed to agree with the end of flash though, maybe now things have changed 2 years later…).

There’s been a significant move towards more and more simple Web apps directly for mobiles (especially as mobile internet has pretty much become a commodity), and what we see is only the beginning. Simply look at the tremendous progress in Javascript recently: more and more server-side javascript engines, tons of libraries for animations, pretty plotting & vector graphics, etc. Additionally, with all the noise around Real-time Web, highly responsive event-driven Web applications can be developed, especially with the Web Sockets in HTML5, which is much cleaner than Comet, therefore paving the way for a new generation of versatile and mashable-by-design Web content distribution platforms.

Beautiful Interfaces

There is a lot going especially around sleek framework for building interactive and visually appealing UI for mobile devices, among which jQtouch, iui, or Sencha (pretty much everything about this was said by Jonathan Stark at our favourite sxsw’s presentation).

Sencha Touch Introduction. “Sencha Touch allows your web apps to look and feel like native apps. Beautiful user interface components and rich data management, all powered by the latest HTML5 and CSS3 web standards and ready for Android and Apple iOS devices. Keep them web-based or wrap them for distribution on mobile app stores.“

Caching & the N of NIWEA (native)

Using Web apps for mobile device might give the impression that the mobile *must* have Web connectivity at all times, which obviously wouldn’t be that practical. The simplest solution to have stand-alone (offline) Web apps is to use PhoneGap (PG) or Titanium which are the first steps towards NIWEA.

PhoneGap is described on the original site as:

An open source development framework for building cross-platform mobile apps. Build apps in HTML and JavaScript and still take advantage of core features in iPhone/iTouch, iPad, Google Android, Palm, Symbian and Blackberry SDKs.

An interesting alternative is to leverage the caching features of HTML/HTTP, so you can explicitly specify what data can be cached locally on a devices and for how long. But there’s a long road ahead towards a common definition (& rigorous/uniform implementation on all browsers). This is definitely an area that deserves through exploration, in particular for how to optimize Web apps rendering and sensor integration for various classes of devices.

iPad is more than just a big iPod

An essential virtue of the iPad was to open our eyes towards what it means beyond just an iPhone with a bigger screen, especially in terms of HCI. As explained by Matt Jones, the novel types of multi-users/-touch interactions enabled by such a larger display offers a fresh perspective for devices, an interactive surface you can share and use with others. Another excellent example is the great iPad radios (sorry, in german), an intriguing Web radio that augments the listening experience with pictures of the singer, and has been developed by our friends at liip (check this awesome “behind-the-curtains” overview of radios).

If you think of the Chumby as a great platform for interactive information display, then NIWEA is Chumby on steroids. Not only because it runs on many more platforms, but especially because the development life-cycle of NIWEA apps is so much shorter. And trust me, there are many Web developers out there waiting eagerly [for NIWEA frameworks] to put their talent and build great Web apps for pervasive screens.

Mag+ from Bonnier on Vimeo.

Looking at the Mag+ concept video above offers a great glimpse into the future of media. In this gorgeous example, a digital surface such as the iPad offers countless new ways to distribute and interact with information, while gaining back the clean and aesthetically pleasing features of print media – the tangible experience. In our world overloaded with information, subtle, appealing, and efficient interfaces are required to interact with all types of media, and a flexible solution accessible to most is needed to maximize its utility.

An iPhone is useful only when you use it, else it’s just there, doing nothing. Because of its form factor, an iPad can be useful even when not used: while you leave it on a desk to charge, it can show stuff to you. The idea of ambient information display is certainly not new, but the iPad just reminds us how we (as designers) barely scratched the surface of all the interaction possibilities hidden behind such a simple (& falsely considered non-disruptive) gadget. What is needed now, is an elaborate, ease-to-use, and efficient framework for building flexible UI with support for smooth tangible interactions of all sorts (multi-touch, sensors, GPS, etc) that can run on a various classes of devices. Such a framework would offer a uniform, high-level, and transparent API that can be used directly from Javascript by people without deep technical expertise, thus enable them to explore the realm of possibilities offered by such displays. This would allow to easily (& cross-platform”ily”) leverage a common set of interactions seamlessly in various NIWEA apps, yet could be still optimized and suited for the hardware platform under consideration.

More to follow soon!