IoT Platform Options

Now that we are well into the growth phase of IoT we have a lot of platforms and tools to choose from.  The are many databases for time-series data, many hardware device platforms and bunch of choices for device gateways.  In this post I’m looking at device platforms now that the arrival of the Arduino Yun and Intel Edison have reawakened my interest in the subject.

Looking at what others are saying I found some useful posts:

  • Sparkfun wrote a comparison of the Raspberrry Pi vs. the Edison in which they show how different the platforms are and that both have their merits.
  • Readwrite wrote another that included an Arduino, similarly defending the Edison’s price.
  • Adafruit wrote yet another that included the Arduino Yun (and Gallileo rather than Edison).
  • Documents on the Yun seem do indicate that the two processors can operate independently.
  • An old VMware article on Edison suggests that the two cores can operate independently
  • Another article from LinuxGizmos on Edison suggests that the two cores may be treated separately but introduces a lot of confusion about different versions of Edison.
  • Since then Seeed Studio with Mediatek have released the LinkIT One and (with their marketing) another comparison in which they also included the Beaglebone Black. Seeed’s new platform looks impressive and I plan to review it as soon as I can get hold of one.
  • [add others here when found]

To my mind the most interesting generic feature that has emerged is the ability to support two development environments – arduino-like and linux-like – on the same platform.  This could be very useful in educational situations where fluency in both models is an objective. Importantly, I think that the value of this model extends beyond education into helping to compartmentalise functionalities that have different needs within the same system.

For example, we might have a very low-powered peripheral device that needs to be controlled by bit-level operations.  This could of course be done in a multi-tasking environment with cleverly written drivers.  However a nicer solution would sometimes be to have a small but dedicated real-time process just for this.

So far I have seen demonstrated on Edison:

  • A simple Arduino program using the linux side to do various kinds of networking by means of Arduino library calls.
  • A multi-threaded linux program using Arduino-style buffered I/O via drivers native to the linux environment.

These models are useful but limited by a master-slave relationship.  What if the two sides could cooperate through some form of message passing yet run independently of each other?  I have read hints that such capabilities may be available via libraries for these platforms in the near future.  There are many hints to this in the above references.

As to the Yun and the LinkIT One, I have yet to evaluate.  Anyone else have?

Interim conclusions: this diversity is all good and the right choice will always depend on overall system/ application requirements.  However, if we can have the third model that would greatly increase the practical possibilities.

Watch this space.

Edison Introductory Hack Day

I have been interested in Intel Edison since hearing of it a year ago.  The integration of Linux and Arduino is something we’ve done before but this approach to packaging is intriguing.

I’m not sure about the market for this product – only time will tell – but I can see that it trumps the Pi as an educational tool in that it provides both environments in a convenient package.  Buffered I/O will make for fewer mishaps when hooking up sensors etc. The dual environment will also be helpful in prototyping.

My particular interest was how the two environments would cooperate in a system solution.  I was not disappointed.  More on that below.

The event itself was very well organised and all kit needed for the demos was provided (this is rare and even the power cabling was adequate).  A github repo contained the necessary instructions and software.  As a result, I got the sense that everyone got through most of the exercises and could go off piste in the afternoon session.

I should admit to not having read the instructions for applying patches carefully enough. Doing this in the github distro would be useful next time.  It should also be mentioned that the demo board should be powered by a separate supply or, failing that, via both usb ports.

The exercise material provided, being Arduino-flavoured, did not cover my desired explorations of how the two environments would work together but there were folks on hand who knew what to do.  I decided to write an app in node.js on the Linux side, have it use the Bluetooth LE port and do some I/O on the Arduino side.

To do this we needed to install a bunch of stuff to enable the bluetooth port and noble.js to make this accessible by my node app.  A library called mraa was also needed to allow the node program to do Arduino-style I/O.  Once this was done it was quick to adapt the demo for a TI sensorTag and make it read from bluetooth and write to the provided LCD on the Arduino side.

Developing on the linux side with the standard command line environment is much easier for the likes of me. That said, I had to remember the necessary command [screen /dev/cu.usbserial-xxxxxxx 115200 -L] and put up with some glitches.  Next time I’ll set up a direct connection via a terminal and use git to post source changes.

PS.  When I did this I found that journals had filled all the available space for installing stuff.  After cleaning that up I installed git, providing a good way to develop from machines on the same network.  Going forward I can also use a tunnel to access the device remotely. Note to self: shift /var/log to another storage device.

All in all a satisfying day.  Many thanks the organising team, especially the triple-A – Alex, Ana and Adrian ;-) and the folks from Intel.  Oh, and thanks for the kit :-)

Further thoughts on Edison and alternatives to follow.

Meanwhile some niggles [add links when I get answers]:

  • We need a good solution to above journal problem – maybe a micro usb for /var/log?
  • We need to know how to use the host USB with nodes.  Install says libusb missing

 

Airsome with added BLE

A year after we showed a hack version of Airsome at OTA2013 we have still not got serious funding to make a product of this.  A number of other takes on the idea of mobile AQ monitoring have hit the streets but, so far, they don’t float our boat.

We have an ongoing conversation with others interested in the project, amongst whom is the maker of some sensors with respectable accuracy.  This was worth waiting for as the cheap sensors are inadequate for most serious purposes. We just got a sample of one of these sensors and integrated it using BLE.

In this blog I’m going to cover the next steps involved in rebuilding the app to connect to sensors via Bluetooth LE, a.k. Bluetooth Smart.  I won’t go into BLE here as there are numerous posts out there.  However, amongst its many great features it promises to become a universal peripheral interface – sort of a wireless USB.

2014-11-18 15.20.44The above is the “Blend Micro” from Red bear Labs. This is a combination of a Atmel processor and a Nordic Semi BLE chip.  It can be programmed with various IDEs, including the standard Arduino one.

2014-11-22 16.59.29

Firing up the app again, with help from Cordova and the BluetoothLE plugin from @randdusing we see the familiar heat map from the original demo.  I don’t think we’re converting the data correctly but you can nevertheless see effect of speed (slow is red).  Next step is to calibrate the sensors properly and produce something a little more meaningful.

To be continued …

What’s-a-Watt Bike Generator Display

Julian and I have been working on a fairground attraction we’ve called What’s-a-Watt.

The idea is to show people how much effort it takes to generate a unit of power or energy. It involves a bike with an attached generator.  We thought it would be helpful in promoting Low Carbon Chilterns and Community Energy in general.

Prototype 1 got an airing at Pann Mill on Saturday.  We only had my old road bike so we could not roll this out for kids.  However, we achieved a basic proof of concept.  Julian documented this as part of his educational video series.

Next step: We plan to make this into a game where different contestants can compete for super-hero status.

Watch this space for updates on the attraction itself and follow @LCChilternsC on twitter.

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.