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 findery. 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 fxstat 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 givology.org 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?

OSHCamp 2012

OSHCamp 2012, arranged single-handedly by @9600, was a significant jump forward from the first Open Source Hardware Camp in 2011.  Part of the secret was holding it in the beautiful Pennine town of Hebden Bridge.  This meant that, if you were in, you were in for a proper 2 days; no sloping off home. Andrew’s blog gives a good overview.   See also Rain’s blog and the twitter hashtag.  I’m sure others are being written as I write.

I won’t try to do an overview here – see the above – but I will make some observations about the parts of the event in which I participated.

My contributions related to Android Accessory Development.  This was easier to talk about than do as I had not installed Eclipse on a PC before and that was one of the first things we needed to do.  Next time I’ll try to make sure we have the answer to that one.  Of course it builds fine on Eclipse on my Mac but that was cold comfort in the circumstances.

A rather more successful contribution was Omer Kilic’s talk and workshop on interfacing to Raspberry Pi.  I regretted not attending this (hard to do when running another workshop) as I have got my Pi now and, naturally, I want to interface it to stuff.  Fortunately, I was able to get hold of a kit from sponsor SK groupspaces Pang and some demo code.  See his website for a more complete kit and the code. Jeremy B kindly cut my SD Card with the recommended Black Raspberry distro (much appreciated since I’m a Mac user and probably don’t have the necessary tools installed).

With this kit, workshop participants were able to led LEDs flashing and read an analogue voltage and a calibrated 3-wire temperature sensor.

Since the event I was able to grab a few hours to replicate the workshop I had missed.   The code and diagrams mentioned above were a great help.

I also downloaded and compiled node.js (server-side javascript platform), my prototyping system of choice. This took several hours on the pi while I got on with other work.  Node runs OK but I/O libraries are limited to GPIO at present.  I will see if I can find or develop libraries for I2C and SPI.

Thanks again to the organiser, speakers, sponsors and all participants for a great event.

And don’t forget to join us for monthly OSHUG meetups.

Leaf Test Drive

I had the opportunity to test drive a Nissan Leaf EV over the recent 3-day weekend. As an energy-head, I’ve been interested in the possibility of an EV ever since they became comparable with traditional motors. However, there were a lot of things I wasn’t sure about.

Comfort-wise this car is fine. I was advised, however, that I might not want use the ACU as it does drain the battery a little faster.

Appearance is, er, typical for Nissan. Not my cup of tea but neither are most modern designs, apart from top class marques. This should not be a deciding factor.

Range is, of course, the big issue with EVs. The LEAF has a nominal range of 99 miles. Your actual achievement, of course, depends on your driving style and, presumably, the age of your battery. On our 66 mile journey I was initially careful to keep acceleration down. Towards the end of the journey I was less careful and as a result reached home with only 6 miles worth of remaining battery capacity. Recharging took 7 hours. This presents the user with a challenge to get their planning right. My dear lady wife thinks journeys of any length constitute a reckless gamble and I have to concede that.

Economy of EVs is good apart from capital costs and depreciation etc. I clocked the energy used on the supplied charger at 3.4 pence per mile (based on my normal home electricity rate). This is pretty good compared to the petrol I use in my current 2 litre car at around 18p/ mile. This would save me some £840/ year, more if I charged during the day when I have solar to spare.

Emissions are correspondingly better than a fossil-fueled car, especially if charged during the day using solar. Embedded carbon in the car itself is hard to assess. I don’t know if such data is obtainable at all. I have asked AMEE about this – they’re pretty expert in carbon calculations – but they have not done cars and do not currently plan to do so.

The crucial point about deciding weather to buy a car like this is the overall economy including depreciation and servicing costs. This is a hard calculation and I will eventually do it and report back here. I would be surprised if a conventional car can be beaten on overall economy but who knows? One thought is that leasing may be a good option, especially if this manages the risk of having to replace the battery. The other thought, as for any car, is to buy nearly-new, avoiding the worst of the depreciation curve.

To be continued …

GDG Chrome Day 25th August

I was lucky to win a Chromebook at a recent hackathon and was then invited to a day at Google to learn about Chrome.  I have long been interested in thin client and this is a great take on that concept.  Basically it’s a machine with the Chrome O/S which is little more than a browser.  However, that browser is Chrome and this has the interesting ability to load and run apps from the Chrome store.

For those who create HTML5 apps for IOS and Android, a Chrome App is much the same kind of thing but with a big screen and it’s own appstore.  I wanted to develop one of these on the Chromebook, push it to the store, pull it down and run it.  Should be straightforward, right?

However, a lot of things we do in development lend themselves to having a Mac with developer tools downloaded and running locally.  In this test we were trying to do the whole process on a machine that does not run any of the usual tools.  That said, there are tools for Chrome books including HTML editors and image manipulation programs.  In this case we had the developer of ShiftEdit on hand, giving a talk about it and answering questions all afternoon.  This is a good HTML/ css/ js editor if you are working on a Chromebook.  Could be good for hacks and small changes to existing code.

As usual, my trial app was Energy-related. It’s called “OWL Guage” and is on the app store.  It allows those of us with an OWL monitor and a local microcomputer to see our (electrical) energy consumption in real-time.

Needless to say with technology page as new as this there are a few issues:

  • Documentation is confusing, especially between “Packaged apps” and browser extensions.  I found myself googling in circles looking for essential information.
  • The Content Security Policy relating to Packaged apps is quite anal.  This is actually “a good thing” but it does mean that you can’t just take a hack that worked on a normal browser and upload and run it in the app store.  Furthermore, you do not see any violations when testing normally, only when they execute from the app store.
  • The Chromebook I have is underpowered.  This made it tedious to go round the development loop.  So I did not complete the exercise and had to finish it up on a Mac the following day.
  • There seems to be no app for pushing the app to the app store.  The missing piece is a zip tool.  It could be that this will appear in ShiftEdit before long.

The bottom line is that I did get my app working.  Must now put up some documentation and open sources the other bits people will need before they can get any use out of it.

Londroid Hackathon 18-19 August (incl. yoyo)

a.k.a “Smart Interconnected Devices Hackathon”

This session over the weekend, organised by @novodakm, was a very unusual #londroid event but none the worse for it.  Kevin explained that this was going to be very unstructured and apologised for lack of sponsorship/ prizes.  No apology was needed; this was a very interesting event that identified people interested in hardware issues.

I heartily agree with the sentiment of both Kevin and Dan that there can be a lot more to mobile devices than (increasingly similar) rectangular screens.

I decided that 24 hours was not enough to hack anything useful, especially given the temperature (hottest day of 2012 so far) and the stuff I had already done @ota2011 and ota2012.  This left plenty of time to meet people and find out what their interests were.

One of the items I was able to mention was the upcoming OSHCamp in Hebden Bridge on 15-16 September when I’ll be talking about  Android Accessory Development Kit (ADK).  Here are some notes that are part of my prep for that.

I realised that I have been focused on the use of the ADK Arduino Mega board while the IOIO (pron.  yoyo) provides an interesting alternative.  I should look into that and maybe include it in my talk.  I have since investigated IOIO and it certainly does look like a great alternative for many types of project, though not all.

Summarising the differences with a little help from IOIO developer @ytai, writings:

  • ADK and its clones only work on specific Android devices, while IOIO would work on almost any Android device since Android 1.5. That said, software is available to overcome this limitation.
  • With ADK you have to write both the Android-side (Java) and the Arduino-side (C++) software, and establish a communication protocol between them. You have to know both languages and two different IDEs and unless you’re doing something very trivial, it will take a significant amount of time to do this. With IOIO, you just write the Android side. You include a library called IOIOLib in your application, which provides an API that lets you control the IOIO pins and functions as if they were physically connected to your Android. You don’t need to care about the fact that there’s a separate processor here, communication protocols, etc.
  • With ADK you can control peripheral devices with strict timing requirements. For example, if you want to generate or decode a specific waveform you would need ADK. I use this to drive BBSB/ Homeasy sockets. IOIO cannot give you fine grain control of timing.
  • ADK boards are compatible with Arduino shields. If you want to use one in your application, IOIO will not be a good choice.
  • If you plug a Bluetooth dongle into IOIO instead of a USB cable to the Android, it will communicate wirelessly with the Android. The nice thing is that your application doesn’t need to care about it, and you can even switch back and forth while your app is running. This may well be possible with ADK but I don’t know who, if anyone, has tried this. Anyone?
  • If you want more info on IOIO, see @ytai’s github or Google “IOIO over OpenAcessory” (without quotes).

I plan to get my hands on a IOIO board and have a play. A different set of libraries is required but at first glance it seems to live up to the description of being significantly easier to implement than ADK.

As Kevin pointed out it gets expensive to have all the kit you need for this king of hacking. So be it :-(

Watch this space.

Google IO Extended hackathon June 2012

Google’s annual developerfest, “I/O”, now includes live screenings in numerous locations. Not having time to schlep over to Mountain View, I thought I should checkout the London event. This is essentially about sitting down and listening to presentations of announcements and updates.  These had a distinctly marketing flavour, although I did not sit through many of them. They were, of course, announcing some cool stuff including the new 7″ tablet and the “Q” home entertainment system.

Also featured was a 48 hour, international hackathon. In London the turnout was minimal but the 4 of us decided to be a team and hack something. (Maybe others were hacking in secret.) What we actually did is covered here. The idea is to make energy monitoring more interesting (ideally “fun”) by making it quick, easy and social.

What can you really do in 48 hours, especially when the 4 of you are not all working through? Well, we did get an Android app done (@kduzo did most of it) and a database, API and number cruncher that I did. Our 2 other team members, @JamesNocentini and František, helped us with important contributions. All this worked together. If only we had time to enter enough data to make it look convincing.

Next: we should productionise this as there are numerous volunteer groups tackling the same problem. A number of them are collecting and processing data *manually*. Can that be fun? Watch this space as we see if any of them are interested.

PS. We have since heard that we won a prize of a ChromeBook.  This duly arrived and certainly does what it says on the tin.  This is pretty close to the vision of thin clients that was touted all those years ago, much more so than a netbook. I hope soon to find time to develop an app or two for it.

Pi story begins

The thing about the Pi is not just that it’s a cheap volks-computer but that it’s already attracting a cult.  This was one reason why I wanted to attend the 1st London Pi Jam (meetup) last night.  I was also reading NESTA’s report on the impact of the BBC Micro on the way to town and back.

At the Jam the beginnings of an ecosystem were appearing including a port of the historic RiscOS and experimenters kits from @skpang_uk.  Organiser Alan O’Donohoe @teknoteacher did a splendid job of running the session in a style reminiscent of a preacher – highly appropriate.  Great that teachers including @pegleggen were presenting and kids were there (not enough but it’s a start).  Update on #youngrewiredstate given by @neilcford

Involving kids is crucial. I was no more than 8 when I starting making things.  You could not buy a computer then but you could try to make one.  The NESTA report addresses on this to good effect.  It’s how people get the inspiration to a career in science or engineering.

The icing on the Pi was a great venue provided by Mozilla (@bevangelist spoke of #summerofcode) and jam scones by @rslosek.  Perhaps even more satisfying was the happy coincidence of being allowed to place my order for Pi (9 weeks delivery) the very next morning.

Now I am thinking of what my first Pi project should be.  Obviously hardware will be involved.  Will be following #ciseco and @quicktowire who, among others, are also cooking up goodies to assist hardware projects around the PI.