Just a quick one to say I’ve made an update to the Arduino MQTT PubSubClient to fix a compile error with the latest version of the arduino software (0016).
As ever, get the updated MQTT Arduino client from here.
As I had hoped, Saturday’s Makers & Hackers event was a lot of fun. After a kick off by Alex from Tinker.it, we split up into four teams vying for the two £50 prizes up for grabs.
I was in a team with jewellery maker Kali and advertising designer Andrew. After some time spent staring at our pile of arduinos, leds, beads and felt we set out to do something around interactive jewellery; something that could react to events around you and notify you of things. Cue five hours of prototyping, coding, soldering, beading, making and hacking.
Our finished piece was a bracelet with 5 leds surrounding a central one, hidden by Kali’s great bead work, with a button to allow the wearer to interact with it. The concept was that the central led would alert the wearer to some event, such as they have new messages. The outer ring of leds could then be used to indicate the extent of the event, such as the number of new messages.
Now, clearly you have to ignore the tail of wires running off the piece connecting it to an arduino. They don’t make it very practical to wear – but there is no reason why the arduino couldn’t have become a feature of a second piece that could be worn as well – particularly if we had a Lilypad to hand. We started talking about having a jewellery ‘hub’ where each piece you wear connects together into their own network. Slightly more than we could have practically achieved on the day.
The teams were:
- Creatorz of Crazyness, who made a tactile clock that allows you to feel if it is time to get up in the morning,
- Nigel and the Craft Girls, who made a set of RFID’d robot plushies that each triggered a unique MIDI effect generated by the arduino,
- Two Guys and Five Legs, who made a rotary encoder out of an office chair, some magnets and reed switches. This could be used to count how many times some spins around in their chair.
- Fragile, which was our team.
After a quick show’n'tell to everyone we got to vote for our favourite. Nigel and the Craft Girls came out on top of the public vote and my team got the experts choice, as voted for by the tinker.it guys there on the day.
Tinker.it will be taking both of our pieces with them to the UK Maker Faire in a couple weeks, so we’ve got a bit of time to tidy and polish before they get shown off.
You can see the rest of my photos from the day here and there is also the wider pool with photos from everyone else here.
Makers and Hackers is a one day competition open to makers of all kinds run by Folksy and Tinker.it! Show up in Sheffield or London on Feb 28th, and make a “Household items of the future” in 8 hours with the people around you!
Tickets are free, but you do have to book – check out the site for details; it should be a lot of fun.
I got an LCD shield along with a second Arduino a couple weeks ago but what with Christmas and finishing off the Orb I hadn’t had much of a chance to play with it. Until tonight.
/************************************************
* Draws a rotating 3D cube on the LCD Shield
* from Nuelectronics.
*
* Nicholas O'Leary
* http://knolleary.net
************************************************/
#include "Nokia_lcd.h"
#include <avr/pgmspace.h>
float sin_d[] = { 0,0.17,0.34,0.5,0.64,0.77,0.87,0.94,0.98,1,0.98,0.94,
0.87,0.77,0.64,0.5,0.34,0.17,0,-0.17,-0.34,-0.5,-0.64,
-0.77,-0.87,-0.94,-0.98,-1,-0.98,-0.94,-0.87,-0.77,
-0.64,-0.5,-0.34,-0.17 };
float cos_d[] = { 1,0.98,0.94,0.87,0.77,0.64,0.5,0.34,0.17,0,-0.17,-0.34,
-0.5,-0.64,-0.77,-0.87,-0.94,-0.98,-1,-0.98,-0.94,-0.87,
-0.77,-0.64,-0.5,-0.34,-0.17,0,0.17,0.34,0.5,0.64,0.77,
0.87,0.94,0.98};
float d = 10;
float px[] = { -d, d, d, -d, -d, d, d, -d };
float py[] = { -d, -d, d, d, -d, -d, d, d };
float pz[] = { -d, -d, -d, -d, d, d, d, d };
float p2x[] = {0,0,0,0,0,0,0,0};
float p2y[] = {0,0,0,0,0,0,0,0};
int r[] = {0,0,0};
Nokia_lcd lcd=Nokia_lcd();
void setup(void){
DDRB=0x2F;
LCD_BACKLIGHT(1);
lcd.cLCD_Init();
lcd.cLCD_Box(0,0,131,131,FILL,BLACK);
}
void loop(void)
{
r[0]=r[0]+1;
r[1]=r[1]+1;
if (r[0] == 36) r[0] = 0;
if (r[1] == 36) r[1] = 0;
if (r[2] == 36) r[2] = 0;
for (int i=0;i<8;i++)
{
float px2 = px[i];
float py2 = cos_d[r[0]]*py[i] - sin_d[r[0]]*pz[i];
float pz2 = sin_d[r[0]]*py[i] + cos_d[r[0]]*pz[i];
float px3 = cos_d[r[1]]*px2 + sin_d[r[1]]*pz2;
float py3 = py2;
float pz3 = -sin_d[r[1]]*px2 + cos_d[r[1]]*pz2;
float ax = cos_d[r[2]]*px3 - sin_d[r[2]]*py3;
float ay = sin_d[r[2]]*px3 + cos_d[r[2]]*py3;
float az = pz3-150;
p2x[i] = 65+ax*500/az;
p2y[i] = 65+ay*500/az;
}
lcd.cLCD_Box(0,0,131,131,FILL,BLACK);
for (int i=0;i<3;i++) {
lcd.cLCD_Line(p2x[i],p2y[i],p2x[i+1],p2y[i+1],RED);
lcd.cLCD_Line(p2x[i+4],p2y[i+4],p2x[i+5],p2y[i+5],RED);
lcd.cLCD_Line(p2x[i],p2y[i],p2x[i+4],p2y[i+4],RED);
}
lcd.cLCD_Line(p2x[3],p2y[3],p2x[0],p2y[0],RED);
lcd.cLCD_Line(p2x[7],p2y[7],p2x[4],p2y[4],RED);
lcd.cLCD_Line(p2x[3],p2y[3],p2x[7],p2y[7],RED);
delay(5);
}
I spoke at Homecamp recently about how an ambient orb could be used to monitor home energy usage. I’ve finally gotten around to putting some of it into practice so thought I would share some of the details of the setup as well as some more of my thoughts on the subject.
There are three key pieces of hardware in use. The Viglen MPC-L is the heart of the system. As I’ve mentioned previously, this is a low powered linux box running Ubuntu. The CurrentCost meter is connected to the MPC over USB-serial and my trusty arduino acts as an integration point for homebrew toys – including my ambient orb.
The MPC is running a Really Small Message Broker (RSMB). This is a small-footprint pub-sub message broker that talks MQTT. Each time the CurrentCost sends out a update, a piece of perl (“cc_pub.pl“) parses the data, sticks it into an RRDTool database for graphing and also publishes it to the home/cc/power and home/cc/temp topics.
Another piece of perl (“orbcontrol.pl“) is subscribed to the house/orb topic. When messages arrive on that topic, they are passed over serial to the arduino.
The sketch on the arduino currently listens on its serial port for commands that are then passed to the BlinkM in the orb. The format of the commands is identical to those in the BlinkMTester sketch that comes with the BlinkM. In the future this will do more as more things are attached to the arduino.
So far I have described how the orb is controlled and how the power data gets into the system. The next piece is how the two are plumbed together. Unsurprisingly, yet another perl script is running the on the MPC that provides the glue for this mixed metaphor.
orblogic.pl is subscribed to the home/cc/power topic so it receives all of the updates from the CurrentCost. It then makes a decision as to what colour the orb should be and then publishes the appropriate command to the house/orb topic.
That is pretty much it – simple eh? Well, I did skip over the most interesting part – how to decide what colour the orb should be.
There are two key philosophies that come into play here:
- Alert the unusual – have the ‘default’ state be the least obtrusive, such as ‘off’
- Band the data – don’t react to single-point changes in the value. For example, when monitoring temperature, nothing is worse than constantly saying “its 19°C, its 18°C, its 19°C…”
These points should be applied whenever thinking about how to turn a raw stream of data into a useful stream of information.
I currently have a very simple piece of logic controlling the orb:
- If
power< 400, turn the orb off - If
powerbetween 400 and 1000, turn the orb orange - If
power> 1000, turn the orb red
When we’re sat in the living room watching TV, we typically use under 400 watts, so the orb will only show anything if we’re over this value. It is very unusual to go over 1 kw unless we’re cooking, which is why that gets a stronger alert.
Despite its simplicity, this has already had the effect of making us more aware of when lights have been left on or when the kettle has finished boiling.
But as with all things, it could get much smarter. Having said we typically use under 400 watts watching TV, I also made the caveat ‘unless we’re cooking’. Given the system has a history of our power usage, it could feasibly determine suitable bands dynamically – so going over 1 kw between 6pm and 7pm isn’t necessarily a bad thing. Also, it chould only go red if the value goes over 1 kw for more than the time it takes to boil the kettle.
It all comes back to determining what is ‘unusual’.
