Tag Archives: sensors

Winter is here – getting the heating just right…

Got home yesterday evening and found the living room on the chilly side! Fortunately I can tell if it is just me 🙂 or if the room is actually getting colder (maybe the lads living in the apartment below turned off the heat).

Over the last two days, a definite drop in the average temperature:
temp-48-201411107 day chart shows it a bit cleaner so time to dial the storage heaters up a notch or two!

temp-168-20141211

Internet of Things – Potential Architectures & Drawbacks

The Internet-of-Things or IoT (terrible name since everyone knows that IoT stands for Inter-operability Testing) seems to be quite the buzzword around lately – replacing the previous version which of course was Machine-to-Machine [M2M]. Nest and other home telemetry/automation tools seem to be quite the cliche-du-jour for the digirati.

Consider what Nest actually does – local (in house) temperature compared with external (nearest location/airport) temperature and a few interesting algorithms to handle temperature differentials, learn preferences, awareness of presence and away type scenarios. Of course  given that it seems to automatically download updates, I’m sure it’s logging and submitting lots of information ‘to improve the product’

Likewise, we have hubs finally coming onstream to try and manage all the possible combinations of hardware and software for home sensors and everything else (or so they promise).

Think home sensors/lightbulbs/whatever – currently we have a plethora of specs to choose from for household comms and telemetry: X10, Zigbee, Z-Wave, Lightwave RF. Telldus, etc. Currently each manufacturer has their own choice of spec, controller software, etc.

Fortunately the Open Source/Open Hardware groups are are already experimenting with options to handle this – a good example is the Home Automation Hub (HAH) project which sets out to turn an Orange Livebox router into a home automation server, with an extra bit of hardware that – like the TellStick – allows it to control a range of gadgetry, and even keep an eye on energy consumption too. Likewise the dovado routers I’ve raved about before have the beginnings of some interesting Home Automation features with integration with Telldus sticks and the use of GPS to determine sunrise and sunset times for the location.

Open Source Open Hardware Hub

Home Hub - Internet of ThingsKey features as I see them are:

  • Compact
  • Reliable
  • Minimum Downtime
  • Low power
  • Open

Publish & Subscribe

So, assuming that we can get all these sensors talking to our hub, and that data recording (and potentially taking local actions based on that – heating, lighting, etc.) what do we do with it.

The hobbiest answer is to put it up on a website for your own entertainment. The more interesting options are open to the hub provider, and I see a few possible approaches here:

  1. Act as a relationship broker: making partnerships with different consumers of the telemetry e.g. allow the hub to submit information of the users choice to projects of their interest e.g. SmartCities, utility providers, etc.
  2. Act as a centralised clearing house: store all users data, sell it in bulk (users are the product) and plan to be bought at some point by Google/IBM/whoever
  3. Act as a centralised broker – grouping your users according to, for example, energy usage patterns and negotiating (optional) bulk deals from utility providers. For example, contacting the Power company and saying here is aggregate usage data for 30k ‘night owls’ – can we get a special deal, since they are offsetting the base load cost, but not adding to peak loads.

 

Providers/Website subscribing to the date

Sensitive Sensors

As I finally got my Arduino reading the temperature sensor, and sending the values to this page consistently I noticed that the values were quite ‘jittery’ – the issue being that I was basically grabbing a single read from the sensor every 60 seconds, and then firing it on. Since this was a single read any issues affecting the sensor at the instant of the read could throw off the value significantly.

temperature_jitterAs you can see in the above chart we can have massive changes in the read temperature without any major changes (that I could tell) in the the actual physical environment – anything between 5 and 20 degrees between samples.

I decided that a better approach would be to average the sensor values over a time and use that as the value sent to the server. The code below shows how I’ve done that:

float readTempAvg(){
  static float buff[12];
  static int index = 0;
  static float sum = 0;
  static int count = 0;

  sum -= buff[index];
  buff[index] = (analogRead(A0) / 9.31);
  sum += buff[index];

  index = ( (index + 1) % 12 );

  if( count < 12 ){
    count++;
  }

  return( sum / count);
}

The sum-=buff[index] has the value that is about to be overwritten in the buffer removed from the sum. This means that sum is always kept up to date. Small improvement to this code would be to define a buffer size at the start and replace all the ‘magic’ const 12 that is in the code.

Following this change I’m getting much smoother temperature readings – generally +/-1 degree or less every 60 seconds.

temperature_newAlgorithmNext step is to try and sort out the Ethernet Shield crashes.