Building an “Ambient Orb” for IoT Apps

This is going to be a long-running project as there are so many ways to do this. The objective is to provide an unobtrusive yet effective way to communicate with people around a home or office. The idea is not new and you can buy one of these from Ambient Devices. However, this one is quite different in the way it gets its information. Specifically, I wanted it to be pachube-compatible so it can be used in numerous types of projects where people have full control over the back-end processing and several choices of communication medium.

The specification(s):

  • low-cost components
  • on-board processing possibilities
  • wired or wireless options
  • standards-based connectivity
  • option to run on battery power
  • brightness control

I made one to evaluate the idea:

  • glass dome (IKEA or B&Q)
  • base unit (painted wood for prototype)
  • Microcontroller (MCU) and comms board stored in base
  • Power LEDs (RGB), drivers and heatsink (yes, even LEDs get hot)

Output devices/ actuators should not poll as this just chews up power; feels wasteful and is. I chose the TCP Socket protocol provided by pachube. This features a publish and subscribe mechanism so the MCU does not have to keep polling for data. Instead, it is alerted when the data changes.

The candidate MCUs were AVR (Arduino) and MBED, the latter being chosen for the first version because the socket libraries were available and there’s plenty of RAM allowing for communication in JSON format. This one uses wired Ethernet. Another version will most likely be built with a Nanode. This will allow a cost saving at the expense of more work on the software. One interesting option would be to use a low-cost wireless receiver instead of wired Ethernet. I also made a version based on a Seeeduino ADK board that communicates via an Android phone. I’m going to try that with an old Android I know longer use. Also with an old USB dongle if I can figure out how to drive that. I was pleasantly surprised to be able to use the Android phone as a gateway although this needs two background async processes – a bit complicated.

BTW. Many thx to @dcuartielles or getting me off base with ADK and to the guys at #londroid for pushing eclipse as the way to go for Android dev.

The LEDs were a tricolor power LED module (LX1610RGBW/A) and the driver was in a quad DIL package (DS3658). For simplicity, the first version limited the current to the LEDs so was not very bright. Subsequent versions will have a larger heatsink and, optionally, be able to run these LEDs at full power. A current-control circuit will probably be needed to do this safely, given the risk of doing everything through software and accidentally over-driving the LEDs.

The firmware is made simpler by using the MCUs pulse-width-modulated (PWM) outputs to control the relative power to each LED. Most of the work is in setting up the connection to the server and dealing with data as it arrives. As firmware is easily loaded from PC or Mac we made a version that cycles the colour values while testing.

In order to control this while testing we made a web page with a colour table selector that sends colour settings to pachube.

colours table

In real applications one would take sensor data and process it before sending an appropriate colour to the orb.

Watch this space for future versions and applications.

How smart will your smart meter really be?

I had been thinking about this and was spurred into action by this item from Horizon Digital Economy Research. I have commented on a lot of articles about smart meters and decided it was time to set down some thoughts. As I was putting pen to paper another article arrived from the Guardian with a number of interesting points.

Smart meters are coming our way, despite any objections such as those being raised in the US (they are really worried about radio – or is it political?). In the medium term the data derived from this will not only reduce meter reading costs and improve billing but will become the lifeblood of a new smart grid.

For reasons best known to the utilities, the chosen data transmission system is to use the GSM (mobile) netwrork and send data at low (30 minute) resolution. Consumer access to this data is not guaranteed and there are suggestions that, at best, it will be available in some digested form on utility company websites. There is an obligation for them to provide in-home energy monitors but these are unlikely to be any more effective that those currently in use. (Initial interest quickly wanes, as do the savings.)

This may make the utilities comfortable but it does not provide a basis for ordinary, non-fanatical, consumers to save significant amounts of energy. Given the enormous cost of the meter rollout, this is at best a massive missed opportunity.

I say this after two years’ study of the home energy-saving challenge in which I and a colleague have achieved savings of 25-30%. This is the kind of saving that is and will continue to be only available to enthusiasts who are prepared to sink a lot of time into the challenge.

To enable the majority to achieve similar savings we believe that the following is necessary:

1. Data must be available instantaneously and must have a resolution in the order of 20 seconds or better.

2. Data capture must be fully automatic and accurate (unless the consumer is super-fanatical enough to do it manually)

3. Data must be available to consumers for their own use or to release to third parties at their discretion.

4. Social tools are needed to help people to support their peers on their journeys to home energy efficiency.

The social tools will come (from 3rd party sources) as and when the data are available to drive them.

The above are blindingly obvious to anyone who has made a serious effort to understand their energy consumption. We hear a lot of complaints about tariff complexity but that’s nothing compared to the problem of figuring out whether your boiler or freezer are delivering reasonable efficiency. The most important devices to understand are those for heating and cooling that normally control themselves.

This is where frequently-updated data comes into its own. Measuring the daily consumption of a boiler or a freezer tells you that it’s consuming too much but not why. However, with more detailed information such as precise on and off times you can decide what to do about it.

Not only does the current plan (a spec would be nice) seem to meet none of 1 to 3 above, it will also further exacerbate the already severe congestion of the GSM network and do nothing to advance the need for ubiquitous, fast (wired/ cabled) broadband in this country. It’s hard to get to the bottom of the decision to use GSM. Is it data security paranoia on the part of the suppliers or is it fear that incompetent installers would mess up anything not wireless?

This looks like yet another episode in the sad saga of government-led projects that either over-run financially, fail to meet their objectives, get cancelled or all three.

.. and they call this Smart?