Review of OWL Intuition Heating Controls and Monitor

In earlier blogs I wrote about the heating control prototypes from Telepure which became OWL. Things have moved on in a big way and I have just installed the complete, integrated product set consisting of wireless optimising thermostat and energy monitor.

By pure coincidence as I was writing this I saw an ITV programme “How to cut your energy bills”. Not just a plug for switching but showing the potential savings for families who have not thought a lot about this. Quote: “You can save as much by changing your heating controls as you can by changing all your windows”.

A new product range can be seen on the OWL website and Shop. This is a very flexible, modular system.  The parts I have installed at home are:

  • Network OWL – the bridge to the Internet

  • Room thermostat (single zone)

  • Tank thermostat (single zone)

  • Boiler relay (makes room stat completely wireless)

  • Energy monitor for grid and PV system

This can be extended with multiple zones as and when I add the extra plumbing.

This is all managed through my account dashboard on the OWL website.  There I can easily adjust the settings and see real-time graphs of the system’s performance.  A slightly-reduced set of controls and displays is available on the free smartphone apps for iPhone and Android.

The website seems to imply that these are two separate systems (Intuition-h and Intuition-pv). It’s actually one system with one dashboard, one phone app and one network OWL. The boiler relay is only needed if you don’t have (and don’t want to add) wires from the room stat location to the boiler. It’s not included in the basic Intuition-h price.

The following is about heating controls.  Having mentioned the monitor I would simply note that it’s best in class and concentrate on the heating and hot water. There are also some excellent, hidden “geek-mode” features that I discuss below.

Here’s an overall system diagram.  It may look complicated but you’ll notice that all the necessary connections are similar to standard thermostats.  Just add Ethernet.

The key features for the normal domestic user include:

  • Heating and hot water are completely programmable so you only produce heat that you need.  As energy bills keep increasing the importance of this increases proportionately.

  • The settings are really easy to control via a simple web interface.  This means that you are likely to apply well-thought out settings. This is the opposite of old-style video recorder-style programming.

  • The system has a built-in optimiser so you don’t have to guess warm-up times or adjust the settings as the weather changes.  You just tell it when you want to use hot water and at what temperature and the system does the rest. Likewise with heating.
  • Normal user controls use a simple three-button approach, viz. Comfort/ Standby/ Boost. In my opinion this is far superior to a dial marked in degrees of temperature which, although perfect for plumbing geeks, confuses people who just want to quickly over-ride the normal programme.  All routine adjustments are made automatically.

      

  • All normal end-user controls are available physically, on the phone apps and via the web.

  •  It’s easy to install and works with almost any boiler.  I have a modern condensing one and it’s ideal for that.  Unlike some products that require you to run extra wiring this just slots into whatever wiring is already in place.  You have a lot of flexibility in where to site the controls.
  •  The optional energy monitor shows both grid and PV usage and calculates overall cost.  You can see the generated energy and what you are selling back to the grid.

Optimisation – how does that work?

  • As mentioned, the purpose of this is to maintain constant comfort levels without altering the programming as the weather changes.

  •  The inputs to optimisation are the internal and external temperatures and the house EPC rating.  The current version does not know the power of the boiler.  In my case I find that my installer underestimated that so I have adjusted accordingly.  Occupancy does have an effect too (e.g. teenagers and their friends coming in and out).  The system could be adapted to take care of that at some time in the future.

Learning – automatic program adjustment

  • Although not implemented there is the potential for tuning the programming in response to users’ over-ride actions.  For the moment it seems that OWL decided not to do this.

  •  If there are frequent requests for more heat and/ or hot water the system could adjust the program automatically.  This could cause issues between the bill payer and other occupant(s) of course.  More importantly, if the European market is mainly people with economy high on their list this could be seen as a reason not to buy.  (BTW, The NEST does this but does not seem to be available in a UK-compatible version – I don’t like the temperature-based control anyway).

Additional features for geeks include:

  •  Graphs that show how the heating system is working. You see the warm-up timing and can spot where your settings are heating air or water more than needed.



  • Ability to extract detailed data for analysis via downloads or programmatically (via an API that uses UDP multicast). Using this we capture the data in real time and send it to Xively. From this we can visualise it how we like. We are looking at how this could be used for forecasting and boiler diagnosis, adding extra sensors and displaying everything on a single graph.

  •  Ability to remotely program the system over UDP via an API.  We used this in a demo where the room temperature settings are controlled via a google calendar. We hope to get this proven and open-source it.

Results

  • In general I’m now satisfied that we have the right balance between comfort and economy.

  •  We have not had any repeat occurrences of the heating coming on in the middle of the night as the programme is much more visible and much easier to adjust. This resulted in significant savings.
  •  I think there’s room for improvement in the user interface, especially in the program setting but the UI is nevertheless streets ahead of the previous programmer we had.  The graphs as they stand do not give geeks everything they need.  However, the openness of the interface allow us to graph, analyse and control the system every which way.
  •  Some aspects of the physical UI (buttons) confused me at first.  I would have preferred the 2 functions on the top button for the heating not to be overloaded.  Hopefully we’ll get used to this.
  •  I reckon that some of the wording in the documentation could confuse some people.  I can’t see an easy solution to this as it needs to be clear for people in the trade as well as the end-user, geeks or otherwise.  “Next comfort period” is an example of this.
  •  I’m still a little sceptical about the optimisation.  This is a proprietary part of the system – fair enough – but I need confidence in its efficacy.  I think this will come with time.

Conclusions

  • I would not be without heating controls of this calibre.  The investment was paid back within six months and since then we’ve not only had lower bills but more consistent performance of the overall system.

  •  Despite my scepticism I am a firm believer in automatic optimisation.  However, the jury must remain out on the learning concept that NEST uses.  I prefer to make any programme adjustments manually and this the way OWL have decided to go.
  •  I’m very interested to see what may emerge from the geeky part of the user community given the existence of open interfaces for data extraction and programming.  I am planning to open source some of what I’ve done with these interfaces.  Meanwhile there is already some code from @aalan on Github. I’ll probably build on this with my stuff.

SusLab Home Energy Hackday + Knudgic

SusLabNWE offers an international facility for testing and developing new concepts to reduce energy consumption in the home environment. ‘Living Labs’, user feedback and a common Sensor Network are central elements of the SusLab infrastructure.

This hackday, ably coordinated by @danlockton and Flora, was intended to bring new thinking into the project.  Attendees were @RCAeducation students, alumni/ae and sundry folks from London IoT.  The idea of a 1-day hack was unfamiliar to me but it worked well in a number of ways.  Obviously not many hacks could be physically built and demonstrated in that time.

Our team titled itself “Normative Nudging”, the idea being to deliver energy-saving nudges that would be personalised and therefore more acceptable than the usual straight comparisons that ignore peoples’ circumstances.  Team members were @SophieEMWalker, Will A-M, Jesse H, @aideen_mcc and myself.

The solution looked like this:

Knudgicsystem

The idea was to use off-the-shelf whole-house energy monitors (until smart meters rolled out). Shame about gas but we have ways of doing that if nececessary.

The “Knudgic device” was conceived as a fridge magnet with a small graphic display, wirelessly connected to a home hub/ router.  This would be challenging to design so that it was thin and low-power.  The idea of a small e-ink display should be investigated.

Screen shot 2013-11-12 at 12.06.56

We did a small presentation on normative nudging to explain the concept to the others present.

One of these days we should actually build one of these.

In conclusion, if you bring people together with no prep they can certainly come up with some nice concepts.  (Several other good ideas also emerged from the day.) To be able to hack something like this together (as a working prototype) could be done by a small team in two days but only if the idea was in place beforehand.

Finally, thanks to the organisers. Food, drink and facilitation was excellent once things got started. You are forgiven for lack of coffee at 8:30am ;-)

Post-script: Initially, I admit to a little scepticism about small e-ink displays.  However, I subsequently got hold of one (from Embedded Artists) that would be suitable.  It’s rectangular of course.  It can display 264 x 176 px.  It could be used with almost any micro-controller. For this app I would pair it something like a Jeenode or equivalent that includes a radio receiver.

e-ink display

 

Raspberry Pi with RFM12Pi and wireless sensors and actuators

These days while I wait for Galileo I’m using RPi as a house controller.  On it I have:

You need at least 4GB of SD for this much software.

As I mentioned Galileo I should also mention the BeagleBone Black.  This would also do the job in that it’s easy to interface and runs linux and therefore all the nice stuff like object brokers and node.js.  However, I really like the RFM12Pi and this is Pi-only at the moment.

My plan is that sensor devices will usually not hang off the RPi. This is largely for packaging reasons.  Obviously they could be hung on the local Ethernet, although this will make them more costly.  One great low-cost alternative is to connect them by simple wireless networks on the 868MHz band.

This is where the RFM12Pi comes in.  It’s a little module that fits inside the RPi’s case.  It contains a wireless transceiver and an Atmel 328 MCU that is programmable Arduino-style. Being based on JeeLabs device protocol it is compatible with numerous devices.

RFM12PiV2

I’ve started with these two wireless devices:

emon-th
bbsb_socket

The software I needed to make this fly consists of an MQTT client written in node.js to publish the sensor data and subscribe to the commands to drive the power sockets.  An early version of this is on github.

Wireless connections have obvious advantages when controlling mains-powered devices such as lights and motors – they provide complete isolation of mains voltages from the control electronics and they save wiring.  A small price to pay is the need to change batteries on the sensors.  This will get better over time as sensor implementations improve so that less power is needed.

The emonTH (and emonTX) sensors, also have the same MCU and and programmable.  At first you might think this is a minor feature.  However, in putting this together it was essential to be able to mess with the data format while testing it and writing the the MQTT client code.

Putting it all together: this is where MQTT comes in.  Once again I demonstrated this with a thermostat application that switches power to a (virtual) boiler when the temperature is lower than the set-point.  This can be built in nodeRED with the following flow:

thermostat demo

The control panel has a lot of unused sliders and switches.  One slider controls the set-point and another acts as a dial showing the current temperature, being updated by subscribing to the output from the temperature sensor.  The thermostat function contains the logic.  When that says to make heat it publishes that to the mains socket supplying the virtual boiler.

For more detail on how I do the UI please see my earlier blog.

You may notice a function called “make integer”. That’s because the MQTT client is producing a string when we need a number.  Arguably, that should not be needed.

To complete this picture I’ll add the following when time allows:

  • a multi-day, multi-session timer UI to control where heat is required
  • holidays could be sourced form my google calendar
  • an outside temperature sensor (or link to weather underground)
  • a function to calculate the optimum start and stop for the virtual boiler

At this point I could connect up my real boiler and replace my OWL boiler controls.  I probably won’t though. Unless you live alone there are some things in life that should just work and should not be tinkered with ;-)

nodeRED and creating end-user UIs

The #IoT world is spawning some nice new gizmos at the moment.  For me as a systems guy, one of the most important is @nodeRED, “a visual tool for wiring the Internet of Things“, recently launched by @knolleary and team at IBM.

In my world of IoT systems development the key features of nodeRed are:

  • its ability to talk a lot of protocols
  • its ability to implement rules (via “functions”)
  • its light weight (runs just fine on ‘Pi and ‘Bone) and
  • its openness and extensibility.

OK, so it doesn’t do websockets at the moment.  Not a problem, I added a couple of “nodes” that do that via a proxy so we’re up and running.  It would (currently) struggle with a large number of nodes and functions (rules). Not a problem, it will be easy to link in other subsystems and rules engines.

And another thing I should mention as an early-adopter: the turn-around on issues is impressive.  I found a few and was pleasantly surprised when they were fixed within hours.

There are already a few very useful blogs out there and I won’t repeat all that here, not that I’ve done all those things myself.  See these:

As we all know, the IoT must include people so we need to be able to hook end-user interfaces into a nodeRED flow.

One possibility is to pair nodeRED with something like OpenRemote.  However, after looking into that I decided it did not give enough flexibility.  Given all the great tools around jQuery UI, the benefits of a ready-made system are not that significant unless home entertainment is your focus.

So I’ve augmented the basic nodeRed with a user control panel.  This is important for me as I am current testing a system that is based on an #MQTT bus.  I need to be able to prod it and poke the system and nodeRED looks ideal for that given a few extensions.

Now nodeRed does have “inject” and “debug” which provide user interaction.  These are for developers of course, not end-users.  Even for devs, we need a method of control that does not require re-deployment and we need a more visual way to monitor what’s going on.

The solution is an html page which talks to nodeRed via a pubsub protocol.  Right now I am using faye, courtesy of @jcoglan.  This is based on websockets and implements the bayeux protocol.  I have written “nodes” fayein and fayeout for nodeRED and will publish these when they’re stable.  These are both clients and need a broker running in the background, just like MQTT does. So you fire up the faye server before using nodeRED with these nodes.

This is what a control panel looks like when making use of jquery ui and plugins on top of that. I have juxtaposed it with the node UI as you would need for testing.  Once tested the user would just get their control panel. As you can see, this one is mobile-sized.  With Phonegap it could be converted to a native phone app.

demo-shot

The above user UI elements could be auto-generated (next project) although these were hand-written.  They include switches and sliders for input and dials and lamps for output.  In this example I have used sliders doubling as dials to save space and all these controls are useful for both input and output.

BTW. You can do part of this with httpin.  However, as httpout does not (yet) support pubsub to a browser I preferred that both input and output work the same way, hence using faye for both.

For the demo I added two other hacks:

  • a jQuery button that looks like an electrical switch;
  • a modification to inject to allow it to generate random temperatures (easier than hooking up a sensor when testing the flow).

As you can see, the flow to implement thermostat functionality is very simple. The thermostat “function” just compares the temperature with the current set-point and sends out a command to the heater/ boiler.

I have also tested this with some other devices connected via MQTT.  These are easily hooked into the above nodeRED flow. Similarly one could easily send the data to xively and pull it back into a graph.  This would be a separate control panel element connected to xively via websockets. (I use highcharts or flot for this, configurable with jQuery.)

The next task is to extend this demo to more sensors and actuators using all 8 controls.  I’d also like to generate the dashboard html and specific .js automagically with server-side scripting to create a desired number of controls of each type.

I’ll report back here with more info after I use this on my real project and knock the wrinkles out of it.

Over The Air 2013 @ Bletchley Park

This is always a great event thanks to the organisers’ skill and persistence. All hail @mobilemaggie, @torgo, @matthewcashmore, sponsors etc. This year was no exception with plenty of great talks and workshops plus hacking. As usual, I wanted to do something with hardware and had brought a big bag of parts.

“Airsome” – Protecting Cyclists from Pollution

This idea came via keen cyclist Hugh Knowles of F4F. We had not got round to it until now (for reasons see to-dos below) but this seemed like the ideal opportunity to do air quaility measurement using wireless communications. The We in this case included Stephen @millipedia (aka Sooper) Cooper who is a dab hand with mobile software.

The general idea is as follows:

Airsome

A sensor board is mounted on the bike. This has a bluetooth transmitter and sends periodic readings of gas concentration (CO and NO2) to the phone. The phone knows its location and sends this and the measurements to a cloud-based data store. The phone can then pull down a time-averaged dataset and plot a heatmap of the polution level.

airsome_bike

This gets much more interesting when you can multiple bike inputs, supplemented by offical data from government AQ networks. This was beyond what we had time for in this 24-hour hack.

The sensor setup for this hack used an Arduino with AQE Shield and Bluetooth module. Not enough accuracy for a real-life solution and not robustly packaged but it did produce readings and showed the effects of driving around a local traffic island compared to the environment in the park.

map_real_data

The sensor module was powered by 4 AA rechargeables.  Fine for short-range use.  We assumed within this hack that we always had a mobile data connection from the phone.

We were pleased that we had enough hardware parts and could get this all working in the time available. We used Phonegap’s Bluetooth plugin which seemed to work fine for the most part, although we had to filter out some extraneous characters.

To-Dos

  • Sensor devices with better accuracy and professional calibration are needed. Ideally sense more than gases, particulates being a greater health risk.
  • The packaging for the sensor unit needs to be robust and suited to bike mounting in such a way that air passes over the sensors.
  • Need to think further about battery life or adding a battery and/ or charging system.
  • It should not be assumed that there is always a mobile signal.  Relatively little storage on the phone would avoid data loss.  We could use SMS as a fallback for alerting the rider when maps cannot be used.
  • The solution should be secured to that location data is not exposed.
  • It would be good if the whole solution could be open-sourced.

As usual, watch this space.

Wuthering Bytes 2013

* Readers beware.  This was somewhat of a live blog.  I’m still adding missing bits and correcting spelling etc. **

Great to be back in the Pennines.  Back in the excellent HB hostel. First up: walk up a hill.  This should clear out some cobwebs.  Headed out in a random direction that I had not walked before.  Ended up finding a nice route with great views.  Shame about the light level but that’s September for you.  My route:

hebden bridge 130914.png

Made it down to the venue.  Good buzz here.  First 2 talks started.

Blaine Cook somewhat scathing about github.  He seems to be using it for human-readable text.  I hadn’t thought of that.  Has not mentioned googledocs yet.  Will ask next time I see him.  As most of use it for code I think we’re very happy with it.

Brilliant to see our youngest ever speaker, 14 year old Amy Mather, to tell about her experiences as a maker and girl geek.  Not her first outing on the speaker circuit.  She showed us a video from Campus Party where she had presented.  Amy got interested via the MadLab sessions in Manchester.  Exciting things to do with coding and making.

Got straight onto the gender issue.  Toyshops have gender-specific toys; science is for boys?  Stereotypes need to change!

At the MiniMaker faire Amy made an Arduino volcano.  Was inspired.

Amy wanted suggestions for how to get more young people involved, especially girls. From the audience.  Inputs fro the floor:

  • get them young
  • add to curriculum
  • STEM ambassadors
  • clubs social and learn from each other
  • educate teachers
  • pink electronics (meet ‘em half way)
  • use games; make it fun
  • start with activities that give instant results
  • fix media attitude and have role models

Some discussion about external pressures, trolls etc. Amy has a very mature attitude to all that. Have to ignore the negatives for the time being. It’ll be a slow process.  Social media mostly good. Has a lot to offer in getting help when you need it. Put me in mind of @stubbornella’s youtube talk “Don’t feed the Trolls“.

Some discussion about language: coding, hacks etc. Cool? probably not.

Amy likes mothership.hackermoms.org.  Need something like that in the UK.

Hard to capture all the discussion but it was all good.  Respect for Amy ;-)

My talk: See here.  How did it go? I don’t know – ask the audience ;-)
Comments: Accommodate the geeks; Polling is sometimes good.  Worry about critical conditions such as fire alarms.  All taken on board.
Adrian’s talk: Who knows about IoT?  All present.
History lesson: Networks past.  Even email started out closed.  Compuserve was a perfect
example.

WAP. aaragh. set back the mobile web by a decade. Thank goodness that we now have phones, tablets and desktops all more or less compatible.

Ethernet is nice for IoT but cables are a pain. Wi-Fi’s ok but power hungry etc.  Lots of other alternatives that support the likes of Zwave, Zigbee etc. Companies have *the* one solution.  There are many of them to choose from.

Electric Imp – nice and easy to configure but ties you in to their service. Risky in terms of longevity of the tech.

Berg cloud – nice and flexible but ties you into Berg Cloud.

We have a tower of babel.  iThings next?

One Direction? No. By which he means that there is not proprietary architecture that will dominate the IoT.  I could not agree more.

IP everywhere? 6lowPAN? He’s worrying me. I think I was over-reacting.

Need pragmatic approaches based on existing internet standards. Ok I’m more comfortable now.

Melanie: how do we get around the commercial pressure? You can’t completely.

Paul: focus on “outside the building” where internet protocols should be de-rigeur.  Inside we can tolerate more variations.  Important to facilitate continuing innovation.

Shay Moradi’s talk:  I was rather tired after a nice lunch. May have been the 5.3 mile steep uphill walk too.

Nick Weldin’s Robot talk

Willow Garage Open CV; Robot OS (ROS) Open Source (OSRF)

These elements used by many Unis to make projects feasible

URDF models. nodes on any m/c on network. pub/sub

Moveit! demos on video, featuring expensive PR-2 bot.

ROS demo; visualiser, graphing tool.  Great tools.

Demo of Rumba base + Kinect – based ‘bot. The kit needs a box (like a laptop) with a full USB implementation (required by Kinect). About 1K for the setup demonstrated.  Other options tend to come with ROS nodes. After a brief tense moment … it worked!

Upcoming event @ Middx Uni. London meetup as well.

James Pallister’s measurement talk:

My typing fingers getting tired so this is from memory.  In their work at Embecosm they need fine-grain power and energy measurement to be able to deliver low power solutions around their compiler technology.

James showed a measurement board that I would like to get my hands on.  I had earlier mentioned the power topic in choosing protocols for IoT but my measurements were crude.  This approach solves that problem.  It’s a digital approach, sampling at up to 500 points per sec.  Resolution is about 10uA.  Being digital makes it easy to properly integrate with tests.

Day 2:

Another walk, this time a loop on footpaths around Heptonstall.  More serious inclines but a little shorter than yesterday. Woke me up a treat.

hebden bridge 130915
path round heptonstall
Got down to the venue in plenty of time to cable up and see what the network looked like.

My MQTT workshop

It started with firing up mosquito server on a RPi. This was ok except for issues with access from machines that had been allocated other IPs. With a little help from friends the Pi was configured with an additional fixed IP that everyone could see.

People had a variety of platforms: Arduino/ jeenode, MBED, Java and node.js with MQTT.js. All these soon spoke MQTT and were sending and receiving messages. @knolleary’s library for Arduino.

Various sensors were attached as well as other data sources. “Actuators” included colour switchable LEDs, a matrix display and a mains switch.

Once the sensors were publishing and the actuators subscribing via MQTT we needed to apply a rules engine to make the connections and apply some logic such as “turn the light red if the temperature falls below x degrees”.

I had brought a rules engine that I’m using for the ecoHome project mentioned in my talk. However, this, although powerfull, does take some setting up. @knolleary had presented node-RED on the previous day and I had played with it a little. I decided that this was the best rules engine for the workshop as it facilitates setup very well indeed with an excellent GUI. Logic and state can be implemented by writing javascript functions. This is fine if the logic is simple. There are also test tools such as logging element (elements are called “nodes” – whoops), a console display and an “inject” function.

node-RED is awesome – I rarely use that word. It makes the wiring of a system solution very simple and intuitive. Several of us were downloading and using it with minimum effort.

Bottom line: we got stuff done with a diverse range of platforms, sensors etc. MQTT just works and the libraries seem on the whole to be robust. node-RED makes it easy to hook things together.

We did have some issues with node-serialport. These are known but very irritating. In many cases you fortunately don’t need this and, if you do, it seems to work OK on a RPi.

Due to lack of concentration and my poor typing I’d like to see the following in enhancements in node-RED. Hopefully Nick will concur:

1. When you use inject to create a json object it would be nice if inject did the encoding and would not save unless the json was lint-free. A check-box option I think.

2. Similarly, functions should not save unless the javascript therein is lint-free.

I should post these as issues on node-RED’s github. In addition I’d like a couple of tools that I can create myself outside node-RED and hook through the socket “node”.

3. Browser-based input data source. This will allow data to be changed without having to edit injects and deploy. This could have a few sliders and switches.

4. Browser-based data sink. This could show multiple outputs in separate scrolling areas. This is less essential as you can have multiple debug elements in node-RED. The issue is that they are interlaced in the console and that can be inconvenient.

Well that’s about it folks.  Many thx to the organisers, especially @9600, to the presenters for the talks I went to and to @knolleary for help with node-RED etc.

Great location, great crowd, great content, great venue.  Inevitably, with such a lot of content and parallel sessions I missed stuff that I wanted to see.  I’m looking forward to the videos.

Wuthering Bytes was a great success.  Hope to be there again next year.

Webinos event and thoughts arising

Webinos is a platform for IoT integration with a number of interesting characteristics. It is being created in a large EU project in such a way that it can become a W3C standard at some point in the future.  See the workshop background for a little detail.

I attended a “mashup” event on webinos in Oxford this week. This consisted of overview sessions and demos. It was well-organised and held at a venue within the CS department.

My take-aways included:

  • Webinos is directly aimed at the very interesting challenge of horizontal integration of diverse devices across different environments.
  • The architecture address the need to discover and control access to devices by users who are not the device owner
  • Both access control and device discovery are distributed with no single point of failure.
  • The implementations (incl. RPi and Android) are based on node.js. A smaller c-based version is under development.
  • There is quite a lot of overhead in the above so the model allows a single instance of the platform to manage a number of lower power devices via custom drivers.
  • Driver-writing seems to be a fairly ad-hoc process at the moment.
  • The demos I saw did not really showcase the heterogeneity that the architecture promises – but these are early days.
  • PS. (How could I forget?) I did not hear anything about semantic standards.  Yes there are common APIs and something for device naming but this did not feel complete. Apologies if I missed something.

I hope to get to further events to be able to better understand how this could be applied to real applications.

They are open to “affiliate” membership with few requirements other than meeting W3C criteria.

Amongst other things I did not discover is the relationship to the Compose project, also creating a relevant platform.

It would be great to be able to assemble a feature comparison for all the platforms aspiring to (horizontally) integrate the Internet of Things including this and likes of:

Anyone think of a way to get some resources onto this?

Watch this space.

Open Source Junction at Oxford, March 2013

OSJ is an annual event run by OSSWatch, based at Oxford University

I attended for the first time this year following an invitation on the OSHUG mailing list.  These are brief notes on the content of this two day presentation-based event.

Intro: Mark Johnson and Scott Wilson of OSSWatch http://www.oss-watch.ac.uk

Paul Tanner: Overview of Open HW vs. SW. All kinds of OSHUG plugs

I ended on discussion of what’s broken about IoT. Mostly about software not hardware but I’m always happy to discuss and looking for supporters. www.slideshare.net/paul_tanner

Intros: 1 minute per person – useful as these don’t happen often. Maybe we should do this at OSHUG or have a membership list with links. Maybe a linkedin group?

Andy Piper: Gave a talk about the work of the Eclipse M2M group. http://m2m.eclipse.org Some useful contributions towards IoT standardisation are going on there. See Eclipse PAHO.

Richard Hughes: http://www.hughski.com Colorhug. An interesting story about commercialising his own-designed Colourimeter.

Paolo Di Prodi http://www.panstamp.com Panstamp. A very interesting OS HW product with DIL form factor including an Atmel processor and an 868MHz radio using the TI chipset. They also have very interesting software for a Linux-based gateway such as RPi.

Andrew Katz reprised his recent talk at OSHUG in more detail. Fuller discussion of licenses for Open Hardware. Examples included:

  • river simple http//riversimple.org
  • protei sailing drone http://protei.org
  • open relief drone http://openrelief.org

Kevin Safford. Personal project to create care package for his mother; candidate for an Extreme Blue project.  Can use help on this, especially technical.

Richard Melville. Nice small box running Mint Linux. Can run on batteries.

Adam Cooper: Excitable media w. cellular automata. Small boards in array. Battery driven

Scott Wilson: Funding options. Some discussion ensued.

Andy Piper: Education should embrace computers again. Mentioned Shrimping.it, Quicktowire.

Mark Johnson: Developing an OSH Community.

Url for slides etc. http://www.oss-watch.ac.uk/events/2013-03-14_Open_Source_Junction_4/programme

All in all well worth attending and I’ll try to go next year.

IoT Discussion at BCS

Notes from meeting 8th Feb 2103.  I have been attending all sorts of IoT meetings about interoperability after getting revved up by discussions at the TSB and particpation in a bid for their ecosystem demonstrator.  Now BCS are forming a group.

Judging by the length of the attendee list vs. the number of people in the room I would judge the level of interest to be no more than moderate. I was hoping for more Q&A but, as usual, the presentations overran. Of the two, the one from ARM was about what we already know. It’s a big opportunity. That said, he did mention the problem of too much vertical integration at the end but, sadly, put very little emphasis on it. The second, from independent Chris Yapp was about the issues and this is what I had come for.

My own perspective going in was that we need to get on with solving the silo problem or someone else will and we may not like the outcome. Chris reinforced that on 2 levels. One, the lack of a basis for wide-ranging apps as opposed to vertically integrated silos. The other, the numerous risks of all this data flying around in an infrastructure with poor network coverage, uncertainty of power supplies (as a lot of existing provision gets switched off) and concerns about privacy and resistance to attack.

I asked: “Should the emphasis of BCS be on bring the market forward in the UK or should we slow it down while we address the risks? The answer is that we probably need to do both in parallel.

Other questions tended either to emphasise the risks or to trivialise the challenges, e.g. IPv6 is the solution (which, of course, it’s not).

The BCS group is closed at the moment while they write a paper. Fair enough, so long as they open it up ASAP. My hope is that there was at least one work stream associated with the horizontal integration challenges such as semantics, naming and data formats. I think this will best be done on a sectoral basic to start with. Ideally several sectors in parallel and plenty of information exchange between them to pull out the common factors.

More on this to follow, especially after we find out what happened to our TSB bid.

IoT Interoperability, SHABA etc.

It’s been that sort of a week.  We put in an EoI in the TSB call for an IoT Ecosystem Demonstrator.  We think it’s good but the competition will be strong and there will be very few winners.

The TSB call was of special interest because it covers the area of IoT interoperability.  Right now many IoT systems are being built and each is presumably complete in itself.  However, they are built with little or no reference to each other and do not interoperate.  We assert that this not good for the growth of the IoT market.

I also attended the launch of the Smart Home and Business Association SHABA.  This initiative, an evolution of  The Automated Home Initiative (TAHI) is setting itself up in a big way to make all the systems around the home and office interoperate.  There seems to be plenty of emphasis on Internet of Things i.e. sensors, actuators and processing.

Then, as if I hadn’t had enough for one day, I attended the London IoT meet up.  This featured the usual cast of characters.  For me, a relaxing affair, catching up on what some interesting people are currently up to.  Another nice wireless gateway, Blinkhub, and a talk on the Little Printer story that I certainly found interesting.  In conversations, it seemed that everyone had put in a TSB bid.

Back to IoT Interoperability.  We need a shorter name for this.

Those of us who have been involved with standards for a long time (but have tried to minimise the amount of time we have spent in dark, smoke-filled rooms) still believe ourselves to be surprisingly sane.  We’ve also learned a thing or two about where successful, *practical* standards come from.

In a nutshell, the standards that count are the ones manifested in quality products you can actually buy.  Take TCP/IP, probably my favourite standard.  A large number of products implement this standard and they interoperate.  How did this happen?  How can we “clone” this kind of standards success story in IoT?

If we go back a few years, numerous implementations of TCP/IP existed and they were more or less interoperable.  The standard was well documented and testing and certification processes came into existence.  Wonderful as these standards, test systems and certification processes were, these did not guarantee success.  The phenomenon that made the real difference was procurement, particularly large-scale public procurements by the likes of the US Department of Defense.

In these procurements, standards compliance was mandatory and it had to be proven.  This created the business case for the otherwise expensive luxury of provable standards conformance.  The rest is history.  When we go to our computer store to buy a laptop or a router we are standing on the shoulders of the giants to procurement.

It may not be possible any time soon to bring this level of support for interoperability standards in the IoT world.  After all, it would not be reasonable to procure against a nascent standard.  However, if we want to shorten the cycle from innovation to interoperability, standards making needs from the outset to involve:

  • real use cases backed by buying power
  • real products from suppliers who are prepared to invest in compliance testing and certification
  • real applications that bridge the use cases to the products

In this sense the plans laid out by SHABA are cogent and promising.  The question is:  who is going to participate?  SHABA would be well-advised to recruit a balanced constituency comprising the above kinds of player and I believe they appreciate that.  My concern is that I’m not sure that any business case for participation will be forthcoming.

So what is a possible business model for IoT standardisation leading to interoperability?  Looking back at how servers became standardised in the early 90s, we saw Microsoft going alone and all the others lining up behind POSIX.  The first stage was the endeavour by Bull, ICL, Siemens, Olivetti and Nixorf followed quite quickly by Sun, DEC, IBM and the rest joining in.  This was later cemented by testing, certification and major procurements.  The interesting part of this is the first stage business case: 2nd rank players worked together to help them take on the 1st rank players.

Will history repeat itself or are we condemned to indefinite IoT chaos?