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.

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]

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.

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!

Let’s be modular

As last year, modularity was a BIG keyword. The Java community has acknowledged the success of OSGi and is looking for a somewhat closer integration of these concepts. The Language Support for Modular Programming (JSR 294) will be part of Java 7 and will pave the way towards truly re-usable software components. In the WoT community and in our personal projects here at ETH and SAP research, we started using OSGi a little while ago. The physical world is definitely not homogeneous in terms of protocols, thus the need to create device adapters or drivers, understanding a particular device and providing its functionality as a Web API. OSGi helps there as it enables us to package these drivers and inject them, at run-time, on different platforms such as “smart gateways”.
But using OSGi also complexifies the whole developement cyle and thus a seamless integration to Java of the modularity concepts might help simplifying it! Wait and see…

REST rules
REST ohhhh REST core of the Web of Things! REST was already pretty strongly represented at Jazoon last year but it now seems to have gone beyond the hype and is in the process of being “tool-supported” in lots of ways in the serious world of Java Enterprise. The most prevalent example of this is the number of Java frameworks offering to help you implementing your RESTful API both on the server and client sides.
When we began our exploration of REST we basically had the choice between RESTlet and …. RESTlet (in the Java world). To me RESTlet has always been a great tool with a great community however, as a developer with Java Enterprise background I always felt not totally at ease with the level of abstraction used by RESTlet (which are really close toFielding’s thesis) and with the relative lack of tight integration with the enterprise tool-box such as JAXB.
The JAX-RS standard changed the deal. It offers abstraction levels which are more familiary to the Java developer and its implementations a tight integration with the Java enterprise tools (JAXB) and techniques (annotations, etc.).

Two implementations of JAX-RS were dominating at Jazoon, Jersey and RESTeasy. Jersey is the reference implementation from Sun (ohhhh sorry Oracle). We’ve been using it in two of our latest projects (that I shall present here soon) and I must say and really really like it. It was presented in several talks but I especially liked this one.
I can only advise you to have a look at Jersey and especially it’s integration to Grizzly, a embedded Web server to follow being only because of its very fast integration of bleeding edge technologies (e.g. Comet) and scalability!

The second framework I had the chance to discover was RESTeasy, a full implementation of JAX-RS as well. I did not have the chance to test RESTeasy yet but I was impressed by the presentation. I especially liked its out of the box support for lots of representations (e.g. RSS, XML, ATOM, JSON, YAML, etc.) and its out of the box support for caching, which is extremely valuable in a WoT.

One of the big problems Java WoT developers will now face is choosing the right framework because these are just three amongst the many poping up every month, the graph below is a hype-meter of the four major REST frameworks for Java:

It was created by a colleague at SAP who also made a great benchmarking of these frameworks (and others). I should soon be able to publish it here…

[to be continued]…

As a recap, Google Trends only shows trends for search terms (or combinations of terms) when the volume of single queries becomes interesting enough (i.e. big enough).

Note that, of course, the trend for the “Web of Things” is not as big yet as the one from his mother “Internet of Thing”, but it is growing (IoT is in blue, WoT in red)

This means that the popularity around WoT is growing and so is the hype. Let’s just makes sure it’s not only a hype and that it also roots on some solid ground that will, one day, make the world of “real things” truly part of the beautiful World Wide Web.

For that we need to do that thing Dilbert calls: “work” (thanks to Vlad for that one):

We created a page to host the application, you’ll find the latest version and additional info there.

Note that it currently only works with the Bluetooth Ploggs and on Windows (XP or later).

The bundle you download there basically contains two applications. First is contains a Web of Things Gateway for the Ploggs (written in C++) which is discovering the Ploggs and making them available through a RESTful interface. Then, it contains a Web UI and datastore based on the great Google Web Toolkit and on the wonderful RESTlet.

The bundle contains the binaries but not the source code. If you are interested in getting the source code please contact us.

We hope you’ll enjoy the software! Note that it is provided “as is” without support. However, you are very welcome to use this blog entry to post your comments, bugs reports or feature requests.

Java Card refers to a technology that allows small Java-based applications (applets) to be run securely on smart cards and similar small memory footprint devices. Java Card is the tiniest of Java targeted for embedded devices. Java Card gives the user ability to program the device and make them application specific. It is widely used in SIM cards (used in GSM mobile phones) and ATM cards. The first Java Card was introduced in 1996 by Schlumberger‘s card division which later merged with Gemplus to form Gemalto. Java Card products are based on the Java Card Platform specifications developed by Sun Microsystems. Many Java card products also rely on the GlobalPlatform specifications for the secure management of applications on the card (download, installation, personalization, deletion).

Here are some features of it (text stolen from here):

• JDK6 Compatible VM: Except for floats, it support class file version 50.
• Full Java Language support: Java Card 2 has restrictions on the language itself. But JC3 has no limits. You can use all language features like annotations, enhanced for-loops etc… (except floating point)
• Rich API: This is mixture of CLDC, GCF, Servlet, JavaCard2 API, Sockets, Threads, Transactions …
• Three application models and two library models, which makes it possible to have virtually any kind of secure application on JC3: o Servlets, extended-Applets, Classic-Applets o Extension-Library and Classic-Library
• Servlet Container with Servlet 2.5 support.
• HTTP and HTTPS interface: No need for special client programming. Use any web client to reach JC3.
• Still tiny(!!):24K RAM, 128K EEPROM, 512K ROM with a 32 bit processor
• It is not just “Card” any more: With the newly added USB interface this technology can go beyond Smart Cards into devices like secure USB tokens, Secure Personal Databases, Embedded Servers, WebDAV compliant thumb drives and more.

The hot part is that smart cards support directly HTTP/HTTPS. This means it can be part of WoT and support natively Web-based communication (HTML/SOAP/REST), so it could be very nice to see new applications that could be built with it. Any experience on your side with that?

However it seems like the REST-* initiative is also generating a lot of unhappy people amongst the RESTians. One of the reason is that they fear the REST-* initiative being a generated WS-* initiative (which is pretty much the case, JBOSS is an Enterprise Server after all, not a Web Server…) will end up with lessons like: “look guys, we did great stuff in the WS-* world now let’s apply what we know to the REST world”.
Fundamentally this would of course be wrong. If the initiative really takes off (which I quite doubt looking at the virulent feedbacks) then it is a great opportunity to rethink the WS-* integration patterns and not re-do what was done for WS-* in REST.

Essentially the first goal of such an organization should be (and is probably going to be, let’s hope) to educate people on the RESTful philosophy. Because it is definitely not trivial to entirely master (while trivial to use) and takes a while to fully understand. It probably took me over a year to go from “REST is just about URLs and Verbs (PUT, POST, etc.)” to “REST is really an architecture with constraints and great great benefits when you are interested in making you application PART of the Web”
REST is simple to use for the RESTful “API” (as word that RESTians don’t always love…) user but hard to grasp in a correct way for the RESTful “API” architect or developer.

So please REST-* guys and gals, do not do standards for the sake of it. The WS-* galaxy has so many standards that no one on earth can tell me how many (watch you eyes if you click on that). REST-* is a great idea which could turn so wrong, don’t waste it!

Indeed, there is a need to clarify what RESTful Web Services (which go beyond REST only) are about and this organization may help towards this particular goal. As a starting point what really helped ME towards this goal already exists. It is a book (a thing with a lot of pages that you can read without Internet connectivity) by people who understood most points of a RESTful architecture. A book that I read over and over again, understanding each time a little more while putting it in practice.

Btw, we are currently writing a more techie and scientific article for a conference which we will publish as a more detailed white paper once it is ready. It should also give its share of advices on building RESTful architectures for… things!

In this first talk of the 2nd International Workshop on Mashups, Enterprise Mashups and Lightweight Composition on the Web at the WWW conference (WWW 2009), Volker Hoyer (a colleague from SAP Research in St-Gallen) talks about patterns to integrate information resources (e.g. an ERP) and generic cloud services (e.g. storage) in the context of enterprise computing.

Enterprise mashups are web resources that combine other web resources that have a business relevance, but unlike traditional compositions mashups can be created by end-users using simple editors. For Volker Enterprise Mashups can be represented in a 3-layers architecture, we first have Resources (e.g. APIs to ERPs, information systems, etc.) these APIs are consumed by Gadgets which are basically visual representations (screens, graphs, maps) and building blocks (piping, flow, aggregates, etc.) consuming the resources’ API. Finally we have the actual mashups which often occur in an online editor
where the gadgets are combined together to create a new ad-hoc application.

Volker explains how resources should also go beyond APIs to enterprise information systems to also include services from the cloud such as storage, asynchronous queues, hosting, etc. In particular in their prototype they use the Amazon Web Services (EC2, S3, SQS, etc.)

As an example they demonstrate a promotion request system where a company A creates requests for promotions that other companies can accept to fulfill. When say company B wants to read the requests from A it can do it by extracting an Atom feed built from a storage cloud service at Amazon fed by company A.

Finally, Volker talks introduces the FAST project which deals with mashups in the enterprise context. Note that FAST is an open project, meaning the sources are available on the web.

You can find the slides here.

In order to better illustrate the application and for us not to have to carry a printer, a kettle and a… fridge around for each demo, we shot a video of the prototype.

The end of the video also contains some more technical insights on the structure of this project and of the web of things in general.

Enjoy! (PS: choose the HQ version, because it is rather hard to read the screen-casts on the other one, PS 2: Thanks to Iulia Ion for the great “fridge opening” acting!)

Apparently according to Tim O’Reilly at the Web 2.0 Expo the next evolution of the Web is going to be physical or to be more precise, driven by sensors.

In his O’Reilly Radar post, Dylan Field talks about a few concrete applications of this Web of sensors. We also listed some and are about to list the other ones we are working on. Understanding the use of the sensor Web and having examples of killers apps is really key in building the sensor Web and making it convincing. But instead of having us only describing our prototypes, it would be a several orders of magnitude more interesting to get YOUR input!

What application of the sensor Web to you envision/work on? Post your ideas and links here as comments and let’s blog about it!

But…

For a 5 year old kid. I found it very nice to test it, and it’s an awesome idea to give it for free at a conference. Great marketing guys. But, after discussing with their awesome product manager – who managed to sell me two of those – I kind of felt “shit, why the hell did I buy that thing?”.

MAJOR TURN OFF NO. 1: Pokens would be awesome and would really work only if everybody in the world would have one – which I doubt. As he told me, they sold 50k units but hey, who the hell would really would buy that (it’s 10 chf =~ 6 euros)?

MINOR TURN OFF NO 2: It just doesn’t look serious. I mean what would I think of a formally dressed VC that pops out a three eyed alien with a blinking led instead of his usual business card? I would be like “Dude, no. I don’t really feel like going to your place and see your electric trains collection and your lego city, but thanks for asking though”. The idea is great for conferences (at least much better than shockfish’s spotme), where you could leverage the social net of the conference and befriend all the people you meet automatically (@lift crew: why didn’t you leverage lift’s social net, and use the pokens to befriend people directly?? That would have been so cool!! the kind of things that we did at picnic rfid hacker’s camp).

MAJOR TURN OFF NO. 3: This was the worse for me: when I gave him my biz card, he back offed just as a vampire that was presented some garlic, and said “no no get away with that, our goal is to eliminate business cards from this world for every”. I realized that this idea is plainly horrible conspiracy. I am a business card design fetish and I think I’d be so sad if natural human interactions (business or not) were to be replaced with a generic digital high-5. I don’t want paper business cards to ever disappear. First because it’s something physical, tangible that conveys someone’s personality. Just like someone’s clothing, it gives you essential details about someone, how much do they care for details. But it’s also a gift, it’s something you cherish, you deserved his card. By seeing a business card, I remember much better about the person who gave it me, what we discussed about, eventually what I wrote about that person on it. A clean, well-designed business card, is just like an elegant suit, it shows that people have spend time to chose it. See, I’m really a fetish for business card, so maybe this turnoff is quite personal.

MAJOR TURN OFF NO. 4: The website, just, simply, plainly sucks. I mean the toy works great and seems reliable, but their website is of a much lower quality than I’d expect from a Web 2.0 startup, and that’s a total turn off for me. It’s sad that they did such an excellent hardware, but neglected to do a really flashy, great, nice, appealing web site! It looks like a modified version of my first website in 1995, just with less animated GIFs. In terms of usability it’s really bad. Guys, please hire a decent designer, because I really don’t feel like using this website, and most people who see it won’t use it again.

Then it’s kind of befriending any people you speak to more than 5 seconds (hey let’s pokenize dude, see u soon, k thx bye). When connecting with someone on a social net becomes so easy, then I think it will just bring a bigger mess in your social net, where half of the people you just met drunk at a party and asked them for a fire to light your cig.

Oh, 1 mil $ question: you still have to friend the people on each network manually, as it doesn’t seem to automatically friend me when I met the peopl, or am I just plain stupid? If you still need to invite all of them to friend them on each network manually, then well it’s just a shortcut to search for people’s profile on each site, which makes me doubt the value proposition of poken.

For the good things, it’s a Swiss startup, which is awesome. Second you got a 1 GB memo stick with it… (so the business model of poken is to sell memory sticks, right?). For the rest, well, I wouldn’t buy that for me (okay, I did already, but I’m selling it, so mail me if you want a 3-eyed alien or a panda…)

I have absolutely nothing personal against the poken crew, I really wish them all good, and I encourage more people to do the same, dream big and build companies in this hot field. I just hope they’ll think about these point and adapt their product to something more useful and valuable, not just a cheap toy that you get bored after playing with it for more than 5 minutes.

Instead of a pure transcription I’ll try to sum up some aspects of the talk. Note that does not entirely reflect what Dave meant but rather my interpretation
of the talk. Dave began by talking about clairvoyance and magics. He explained how they materialized these chimers into the well-known Orb which changes its color according to a trend. Dave then explained how ambient devices where between push and pull technologies, how they should be peripherial and seamless with the environment(s).

He explained how facinated he was by the idea of dashboards a information concentrators. He especially focused on how to design them in an ambient manner so that they do not turn into pizza-style-portals with too much information to be really integrated to the environment. In the field of weather forcast he presented a prototype he designed recently. This small black screen provides very general information and is very ambient when people are far away. As people come closer it displays more accurate information and increases the info bandwidth and concentration on the screen.

The next part of the talk was about life-cycles of nature and the way to map it as an output interface for ambient devices. As an example gardening and the growing of fruits and vegetables could be mapped to something like the Orb. As apples grow they change their colors (green to yellow to reddish…) the same pattern can be applied to ambient devices.

He then talked about monitoring the energy consumption, an especially interesting topic to us our Energie Visible project develops. He pointed at the fact that energy metering is already in place just not at the right place and not using the right human-computer interface. It is in our cellars when it should be informing us in our living room. In this field he introduced the off-the-shelves products of Ambient Devices Inc.

He went on talking about one of the products of Vitality Inc. The Glowcap is the world’s first Internet connected pill cap! It may sound silly but it actually has a number of uses. It can be used to coordinate re-fills for instance or to check whether you really take your medications. It reminds me of a paper we wrote a while ago about RFDiyin the hospital. But Glowcaps go far beyond and I think they encapsulate the evolution of the Internet of Things. From being able to identify things to being able to enhance and literally connect things..

The last project he talked about was the Ambient umbrella, that knows when it’s gonna rain. While it has not real use it makes a point: take the information away from your browser, embed the Internet into every-day objects.

The coolest things is that now it also supports 2D barcodes. I’m not so sure where the guys are heading in terms of business model, because the ideas I have in my head to use tikit.. erhmmm… toughatag do not really use their services (if I take a QR code snapshot with a random mobile phone and software and go to the encoded page, where would I need touchatag???). In any way, I’m looking forward to check more their stuff (I like the idea of redirecting tags to urls.. . for example to devices… more to follow on that soon).

A major burden for people, who want to save energy at home, is for them to identify how much energy is consumed by different appliances. How much does my computer consume in operation / when it is powered off? Is the consumption of my energy-saving lamp significantly lower in the long run than the normal lamp I’ve got there? Such questions are key to understand where energy can be saved without too much effort. Currently available solutions, such as pluggable power monitors, are helpful, but do not fully fit the needs of individuals. They lack demonstrating power such as being able to compare consumption on a centralized screen, in an appealing manner.

In this project we implement a system that’s very simple to set up and that can be used in everyday life. All you need to do is to get a number of Ploggs and plug them on the appliances you want to montior. Then, our software finds all the Ploggs in the environment and makes their functionalities accessible through a dynamic web page as shown below:

The interface offers six real-time graphs. The four graphs on the right side provide detailed information about the current consumption of all the appliances currently available (i.e. attached to a Plogg). The two remaining graphs show the total consumption (KWh), and respectively a comparison (on the same scale) of all the running appliances.

A more geeky description of that system is available in this post.

The software will soon be available for download here so stay tuned!

Remember not long ago I was talking about our first real-world implementation of the WOT concepts in an energy monitoring application: Are you Energy Efficient? Sense it the WEB way, well this system, now named “l’énergie visible” or “visible energy” was selected amongst a number of projects for the Jade national energy award in Switzerland.

It is now entering the final selection phase, 20 projects are on the list. The folk can vote for the projects on Jade Award. So if you like the Energie Visible project then do support us, vote for project 13.

More news on that when the selection occured…

The Trend
Cisco is forming the Internet Smart Object alliance, which promotes the used of IP in Networks of Smart Objects not long after this announcement they also acquired Jabber to extend their knowledge in messaging.
The EU is organizing a number of Internet of Things workshops, thus it seems like the IoT is becoming a reality not sci-fi anymore.

Spime Application Space
Spime is the contraction of SPace and tIME. It’s about a new category of objects aware of their surroundings. As an example CO2 Spime collects the CO2 level from a number of sensors sending it to the Web where the concentration of CO2 can then be visualize.
Social Energy meter is another example of Spime powered application. Its aim is mainly at visualizing your own energy consumption as well as on comparing it with others. WideNoise is an iPhone app that takes noise samples on a regular basis and mashes up the observations with a Google Map, enabling people to check the noise level at various places. The Spime design workshops are interactive sessions where 20 to 30 folks meet to think about how they could invent Spime based apps.

From OpenSpime to WideSpime, from Prototypes to Living in a World Full of Smart Objects
From 10 to the power 8 PCs, 10 to the power nine humans and mobiles David expects more than 10 to the power 10 of Spimes. As a consequence it is of prime importance for the Spimes to be autonomous, you can not expect humans to manage such a big number of devices. Manage their data, functionalities and instinsic properties such as battery state.

OpenSpime provides a free and opensource toolbox for building based on these fast growing objects aware of their surroundings and environment. OpenSpime is a python framework that uses the XMPP messaging prototcol. The new evolution of OpenSime is named WideSpime. The goal here is to accept the challenge of massively distributed computing environments based on wide network of things. In WideSpime they want to re-think the way we design computing systems in order to take into account the >1000 smart objects per people we will soon have to deal with.

We just gave a talk on the Web of Things, over at the folks from liip, a cool swiss Web development company with whom we share common interests (i.e. making the Web cooler). The slides of the talk are online: intro & demo (@Dom: put your slides here dude, UPDATE: It’s down there dude! ). Too many things to present in such a short time, but we hope this would lead to further discussions (and hopefully collaborations) with Web developers, to learn and create new things together. We are working hard to release at some point some code and examples, just a little more debugging.

Sorry for the low activity these days, but you know, Christmas, new year, and some hardcore paper deadlines very soon (as in tomorrow). Things will become more regular soon.

UPDATE: Let’s just do like everybody, we put it on slideshare, and we’ll do so for all presentations from now on!