Just a quick note to with all our fantastic customers a Merry Christmas and Happy New Year. Also to let you all know our holiday operating times for the 2012 holiday season.

We are a family business and think it's important to spend the holidays with family. Our office will be closed from this Friday 21st of December, the website will of course still be accepting orders but dispatch will be delayed until we reopen on Monday 7th January.

If you have any urgent requirements feel free to email. I (Hadley) will be sporadically checking emails and may be able to respond during the holidays.

All the best to you and yours for the holidays, enjoy yourselves, stay safe, and try not to eat too much!

Cheers!

I (Hadley) do a little work with solar powered installations. Lately I've had a few people ask how to work out what size solar panel they need to run some electronics so I thought I would take the time to note down how to calculate it here. Solar dimensioning is pretty straight forward once you know what equations you need to work out. One thing you'll probably notice is that you need a lot bigger solar panels and batteries than you think, especially if you want to run something 24 hours a day.

First for this theoretical example we'll make a few assumptions.

• The load we want to run is 10W
• We want to run the load 24 hours a day
• We get an average of 4 hours of peak sun each day.
• We want to size the system large enough to handle four rainy/cloudy days without sun.
• We'll be using lead acid (car) batteries.

Now to the actual calculations you need. To start with we work out what sized batteries we need and then what size solar panels we need to charge them.

Lets work out the Watt-Hours we'll be using, our load is 10W and it's running all day and night so: 24 hours 10 x 24 = 240 Watt-Hours

Once we have the Watt-Hours and the type of battery we're using we can work out the Amp-Hours, 240 Watt-Hours divided by 12 Volts: 240 / 12 = 20 Amp-Hours. That's only for one day though and we wanted to withstand four days of bad weather (autonomy). Let's multiply: 20 x 4 = 80 Amp-Hours

With a lead acid battery you really only want to discharge the battery to 50% at the most, any more and the battery will wear out quickly. So double the Amp-Hours needed and we get a battery size of 160 Amp-Hours - quite a lot bigger than you would think, also that's quite a big battery, it will be about 30kg!

Now that we have our battery size we can move on to working out what size solar panel we need to charge it. Remember from our first calculation three paragraphs above our daily use is 240 Watt-Hours. Our assumed daily sunshine is 4 hours. To recharge the battery for one days worth of usage in one day charging, we need a solar panel that is: 240 Watt-Hours / 4 hours = 60 Watts.

The charging system isn't 100% efficient, a good rule of thumb is to allow for 20% losses. You might also want to add some solar panel capacity to allow for a quicker recovery from extended periods of bad weather, perhaps another 20%. So your panel choice may by up to: 60 Watts x 140% = 84 Watts. A standard panel sizes are 60W and 90W, depending on your exact usage and the level of autonomy you want somewhere between those would be a good choice.

I hope that gives some insight into how you go about sizing up a solar and battery system. There are some web based solar calculators out there which may do some of this work for you. Have a search around the web. Just beware that a lot of them aren't fantastic quality and it's not all that difficult to do the calculations yourself on a plain old calculator.

To calculate the actual sun hours for places around New Zealand, including the differences between summer and winter, check out SolarView from the good folks at NIWA

While we don't sell large solar system components talked about here we do have a range of small solar modules and components which you might like to check out. If you've got any neat projects you're doing please do let us know in the comments below. Cheers!

Last week some guy came around and switched out our old meters for new ones. Not "smart" meters, just new dumb meters, which is fine as the current crop of "smart" meters don't seem to benefit the customer, rather just the company.

A couple years back we used to have a Currentcost device which I had hacked with an Arduino to put data on the network but I always had issues with phantom loads so the transmitter stopped working I never did anything about sorting it out.

Anyway, the new meters have a red LED impulse output that flashes 1600 times per kWh used. These are just about the perfect way to hack into your meter - no dangerous (and potentially illegal) connections required and super easy to do. It should also be very accurate since the meters are certified correct.

Here's a photo of the meter box showing the new meters and the sensors (with black tape over them). The two meters are on the outside and the ripple control in the middle. The Arduino and enclosure are just outside the photo to the right mounted on the wall, I thought it best to keep "odd looking things" out of way of the power company.

For the controller I used a Freetronics EtherTen which is an Arduino Uno compatible with built in Ethernet, these are great boards that we use a lot of here. The sensor is just a Photocell on the end of a small twin core wire connected back to a Prototyping Shield with a resistor.

The sensors are covered in black duct tape to keep out ambient light and connected up to the two interrupt digital input pins on the Arduino to make counting the pulses really easy (see the code below).

I already use MQTT (which is a simple network publish/subscribe system, great for machine to machine (M2M) communication) for some home automation around the house so publishing the electricity usage there made perfect sense. The EtherTen publishes the data on the network and any number of clients can subscribe to this and receive updates. Currently there's just a Python server which logs the data into a redis db for historic graphing. Here's an example graphs;

You can see that our house and its young family has a long way to go with saving energy. The blue graph is the standard meter and the red graph is the water heater circuit. This graph is actually higher than normal, it was a cold day but not cold enough to have the log burner on which heats up the entire house. You can see overnight the electric heaters in the children's bedrooms cycling on and off and at 6am the heat pump (air conditioner) ramping up to heat up the living area.

Of course you could also add any other network device and have it subscribe to the electricity usage MQTT topic. Perhaps I'll build a little RGB LCD display and have it show the current usage with a colour that reflects how well (or badly) we're doing at saving energy.

Here's the code I've been playing around with, suitable for Arduino 1.0+ and the not quite latest Arduino MQTT client (there was an update released this weekend which I has a small API change - easy fix).

/*
* By Hadley Rich 
* Released under the MIT license.
* Some ideas taken from arduino.cc example code.
*/

#include <stdio.h>
#include <SPI.h>
#include <Ethernet.h>
#include <PubSubClient.h>

byte mac[6] = { 0x90, 0xA2, 0xDA, 0x44, 0x34, 0x28 };
char macstr[18];

const int chan1_pin = 2;
const int chan2_pin = 3;
const float w_per_pulse = 0.625;
const unsigned long ms_per_hour = 3600000UL;

unsigned int chan1_count = 0;
unsigned int chan2_count = 0;
unsigned long report_time = 0;
unsigned long chan1_first_pulse = 0;
unsigned long chan1_last_pulse = 0;
volatile byte chan1_pulse = 0;
unsigned long chan2_first_pulse = 0;
unsigned long chan2_last_pulse = 0;
volatile byte chan2_pulse = 0;

PubSubClient client("sodium.nice.net.nz", 1883, callback);

void callback(char* topic, byte* payload, unsigned int length) {
}

void chan1_isr() {
  chan1_pulse = 1;
}

void chan2_isr() {
  chan2_pulse = 1;
}

boolean connect_mqtt() {
  Serial.print("MQTT...");
  if (client.connect(macstr)) {
    Serial.println("connected");
    char topic[35];
    snprintf(topic, 35, "house/node/%s/state", macstr);
    client.publish(topic, "start");
    return true;
  }
  Serial.println("Failed.");
  return false;
}

void setup() {
  pinMode(chan1_pin, INPUT);
  pinMode(chan2_pin, INPUT);
  attachInterrupt(0, chan1_isr, RISING);
  attachInterrupt(1, chan2_isr, RISING);
  Serial.begin(9600);
  delay(1000);
  snprintf(macstr, 18, "x:x:x:x:x:x",
    mac[0], mac[1], mac[2], mac[3], mac[4], mac[5]);
  Serial.print("DHCP (");
  Serial.print(macstr);
  Serial.print(")...");
  if (Ethernet.begin(mac) == 0) {
    Serial.println("Failed.");
    while(true);
  }
  Serial.println(Ethernet.localIP());
}

void loop() {
  char topic[35];
  char value[6];
  static unsigned int chan1_watts;
  unsigned long chan1_delta; // Time since last pulse
  static unsigned int chan2_watts;
  unsigned long chan2_delta; // Time since last pulse

  if (!client.connected() && !connect_mqtt()) {
    return;
  }
  client.loop();

  if (millis() - chan1_last_pulse > 60000) {
    chan1_watts = 0;
  }
  if (millis() - chan2_last_pulse > 60000) {
    chan2_watts = 0;
  }

  if (millis() - report_time > 5000) {
    chan1_delta = chan1_last_pulse - chan1_first_pulse;
    if (chan1_delta && chan1_count) {
      chan1_watts = (chan1_count - 1) * w_per_pulse * ms_per_hour / chan1_delta;
      chan1_count = 0;
    }
    chan2_delta = chan2_last_pulse - chan2_first_pulse;
    if (chan2_delta && chan2_count) {
      chan2_watts = (chan2_count - 1) * w_per_pulse * ms_per_hour / chan2_delta;
      chan2_count = 0;
    }
    if (!(report_time == 0 && chan1_watts == 0 && chan2_watts == 0)) {
      snprintf(topic, 35, "house/power/meter/1/current");
      snprintf(value, 6, "%d", chan1_watts);
      client.publish(topic, value);
      snprintf(topic, 35, "house/power/meter/2/current");
      snprintf(value, 6, "%d", chan2_watts);
      client.publish(topic, value);
      Serial.print("Chan1 ");
      Serial.println(chan1_watts);
      Serial.print("Chan2 ");
      Serial.println(chan2_watts);
      report_time = millis();
    }
  }

  if (chan1_pulse == 1) {
    chan1_count++;
    chan1_pulse = 0;

    chan1_last_pulse = millis();
    if (chan1_count == 1) { // was reset
      chan1_first_pulse = chan1_last_pulse;
    }

    snprintf(topic, 35, "house/power/meter/1/usage");
    client.publish(topic, "0.625");
  }
  if (chan2_pulse == 1) {
    chan2_count++;
    chan2_pulse = 0;

    chan2_last_pulse = millis();
    if (chan2_count == 1) { // was reset
      chan2_first_pulse = chan2_last_pulse;
    }

    snprintf(topic, 35, "house/power/meter/2/usage");
    dtostrf(w_per_pulse, 4, 1, value);
    client.publish(topic, "0.625");
  }

  int dhcp_status = Ethernet.maintain();
  /*
    returns:
    0: nothing happened
    1: renew failed
    2: renew success
    3: rebind fail
    4: rebind success
  */
  if (dhcp_status) {
    long now = millis();
    Serial.println("DHCP Lease");
  }
}

All that's left to do now is tidy up the Ethernet cable... Any questions or comments please feel free to leave a comment below.

We've got a few Raspberry Pi accessories available in the store now and we've been doing a few things with the Rapsberry Pi ourselves too. Currently I (Hadley) am working on a solar powered remote webcam and weather monitor using 3G to upload data to the Internet.

Since we've got a few of the new 512MB Raspberry Pi units here I thought it would be fun to give one away too. All you need to do to enter is follow and mention us on twitter - use the #nicegear hashtag or if you don't do that Twitter thing post a comment on this blog entry.

A winner will be selected at random tomorrow (Friday 9th November) at around 4pm using random.org. Good luck!

A common question we get is the default web interface password for phones and other gear that we sell. Most people try admin/admin admin/password and various other common combinations. That won't get you very far with Polycom IP Phones, they chose the username "Polycom" and the default password "456". That password also works through the phone interface too.

Check out what the folks over at Clandestine Laboratories are up to with an Arduino, a stack of Freetronics Relay Driver Shields and a pile of relays controlling solenoid valves.

This is the third and final instalment in a series, part 1, the introduction, is here. This post will talk about the custom Arduino shield we designed and built, and the installation.

We left off last time having sent the second PCB revision to Hackvana for a prototype run of 10 boards. These arrived in good time. I built up one of the boards and took it down to the farm to test. Plugged it in to the 24V shed power supply to test the new regulator set up, wired it up and everything worked as expected. I then went ahead and ordered the full production run of 50 boards. With the prototype run that gave 60 boards total, we needed 54 so that left a margin of 6 spares.

While I was waiting for the production boards to arrive I assembled a couple of boards to get a head start. This is when the reality hit me of how long the build was going to take. I timed one of the builds and it took 20 minutes, some quick maths leads us to 55 x 20 minutes = 1100 minutes, or, 18 and a half hours! Second lesson learnt, do a time budget before you start. A multiplication factor of 50 makes even the smallest job much bigger than you think.

The production boards and parts arrived, a few late nights and lots of solder later, this was the result (well most of it, I couldn't fit all 55 boards in the picture);

After my experience building that number of boards I've started working with surface mount components to allow for more automation in assembly.

Next up was the installation, despite never having worked with PCB manufacturing before, and learning a huge amount there, I think I learnt nearly as much from the installation.

To keep the cost down for the farmer we re-used an IP66 rated enclosure from part of the previous electronics. While the Arduino and shield fitted well in this, by the time all the cables (eight double insulated cables) were put through glands it was a very tight fit. Small lesson learnt - you need a much bigger enclosure than you think when you're dealing with more than a couple cables.

Partly due to the enclosure size but also just due to the general amount of work required the installation proved to take quite some time. I timed it at about 30 minutes per board. As this was going to be too much time for me alone I employed the help of another local consultant. He normally does residential and commercial audio visual installations so this was a bit of a change for him but he was well suited to the job - wiring is wiring.

Another one of the things I discovered while installing the boards was that screw terminals are stronger when they are all clipped together in a long row. Having them spaced apart (as you can see in the picture) doesn't give them all the torsional strength that they could have which leads to some movement when tightening down the screws. Not a big deal but something to consider for a new revision.

After installing a few of the boards we decided to switch things on for a test. This is where things went a bit wrong and I learnt my biggest lesson of the project - do better testing. Although we tested with the actual load (the vacuum solenoid valves), we didn't test for an extended period of time. Turns out that we had an error in the board which was causing the MOSFET to not switch completely on. This resulted in heating and eventually, the destruction of the board.

So at the end of the first day things didn't seem to be going very well, we were taking longer than we thought to install the boards and the ones we had installed were trying to catch on fire. After a bit of a stressful afternoon I discovered the problem and had a patch fix. One of the traces on the PCB was not quite going to the right place, this was causing the solenoid to look like a resistor which created a voltage divider, this in nturn lowered the voltage to the gate of the MOSFET so it didn't turn fully on. Cutting one of the PCB traces and soldering a resistor in its place fixed the issue.

Although I had a fix, at this point in time we didn't have enough time to create a new set of boards, wait for them to be delivered and build them up. Instead we patched all the boards and installed them as they were. Not completely ideal but the fix was solid and there really wasn't any other choice.

I'm pleased to say that the cowshed has been running perfectly for the last few months with no failures. The farmer is happy with his system, which is running better than it ever has, and saved a bunch of money too. If anyone has any questions feel free to ask in the comments below or get in touch through the contact page.

This is a follow up to part 1, the introduction. This post will talk about the electronics we designed and built. To the right you can see a picture of one of the air solenoids that we needed to drive.

First things first I built up a prototype controller. To get going as quickly as possible I used some off the shelf breakout boards from the store. Paired with a Freetronics Eleven I used a Prototyping shield, four Freetronics N-MOSFET Driver Modules, a couple of rectifier diodes and a birds nest of Hook Up Wire. I didn't get a picture of the set up but you're not missing much - it wasn't that pretty anyway.

I took the prototype electronics down to the dairy shed, plugged it in to a power supply, wired up a couple of buttons to act as inputs and wired up the vacuum solenoids to the MOSFETs. It worked - a good start! The next stage was back home, designing the actual PCB to use in the installation.

Although I am competent with basic electronics theory and know how to draw a circuit I've never designed or built a PCB before, so everything was a little new to me at this point. I opened up Eagle CAD - a PCB design program - and quickly decided that I was out of my depth. With no experience and a 2 month time frame for completion now was not the time to be learning how to design a PCB.

As I mentioned last time I enlisted the help of hairy.geek.nz, after he agreed to help I sent through a photo of a rough drawing I made with a pen and paper. Quickly I received back a picture of a PCB ready to be sent off to a board factory to be made. A couple of emails back and forth later and I did just that - sent the boards off to Mitch from hackvana.com.

There are loads of prototype PCB services out there to choose from but Mitch at Hackvana does a lot to support people creating open source hardware, his prices are great, and the turn around is good and quick. About 10 days after sending the design through to Hackvana I had a set of 5 prototype boards in my hand. I built a couple up and took them down to the farm (about 30 minutes drive).

When I got down to the farm ready to hook up my shiny new board I was quite excited. I pulled out my multimeter to check there was power before wiring things up to the shed's power supply and that is where I ran into the first issue - the shed runs on 24 volts, which the Arduino can't handle as a direct input. Originally when I talked to the farmer he had told me it was all 12 volts. First lesson learnt - don't rely on provided information, test things yourself.

We worked around that for the moment to see if the everything else with the electronics (basic program, inputs and MOSFET outputs) was working - which it was. So at the end of the day, some good points and some bad. Back home to work on a new board revision.

I talked to hairy.geek.nz again and decided that the best solution considering the time frame we had to work with was adding an off the shelf switching regulator to the existing design. It was rated to convert 24V to 9V, and then let the Arduino regulator convert the 9V to 5V as it normally does. He quickly sent through a new board layout which I sent through to Hackvana for another set of prototypes.

I think that's enough for this instalment so I'll leave it there. Next time I'll talk about the production of the boards which I didn't manage to get to this time and hopefully the installation. Any questions so far? Please feel free to ask in the comments.

Part 3 is available here.

I'm going to break this up into a couple of shorter posts, starting with a general introduction here. Please feel free to let me know in the comments if there is anything specific you would like me to cover.

Over the past couple of years I've been working with some local farmers building an automated calf feeder (that's a topic for another post). Over the winter one of the farmers involved in that project came to me asking if I could tackle another project, this time in his milking shed with grown up cows.

While his cowshed (a rotary with 54 milking bales/stalls) is only a few years old, the electronics in it were failing, and unfortunately the company who installed it were offering no support. A replacement system from one of the traditional dairy companies was going to run up to $50,000 or more, and the one he had his eye on wasn't ready to install for this season (marketing departments are often ahead of R&D).

The electronics in question are relatively simple, each milking bale has a few inputs - buttons and switches - and a few outputs - air solenoids for switching vacuum on and off. Sounds like something perfect for an Arduino to do, but remember as there's one for each bale anything we do we're going to need to do 54 times over.

Photo: Cgoodwin Wikipedia

The proposal he came to me with was to see whether we could come up with something low cost to use in the interim, to get him through a few seasons until he decides what he would like to do about a commercial solution. The kicker was that we only had a couple of months over winter to design and implement the solution, it needed to be ready for July when cows start to calve and need to be milked. No milk on a dairy farm is a big problem.

Some specifics about the electronics: There are 4 main digital inputs and outputs - easy for an Arduino to do, but the shed's electronics all run at 24 volts so dedicated drivers need to be switched from the Arduino logic for the outputs.

The four inputs are; 1) A button which starts and stops the milking process for each stall. 2) A switch which detects when the user lifts the cups and automatically starts the milking process. 3) A milk flow meter so we can tell when the cow has finished being milked. and 4) A voltage input to tell us that the plant is being washed. 1 and 2 are basic inputs, 3 and 4 come from an external voltage source so need to be isolated from the Arduino.

The four outputs are air solenoids switching vacuum pressure. One controls the main vacuum for taking the milk from the cows udder back to the tank, two control the pulsators which actually milk the cow, and the final one controls an air ram which removes the cups once the cow is finished milking.

I looked for a while at off the shelf solutions, there are loads of Arduino Shields around these days and even some which offer similar functionality to what I needed, but nothing quite fitted perfectly. In the end I decided to go down the route of creating a custom shield - a big step considering it's not something I had done before. I enlisted the help of hairy.geek.nz, who I knew had experience designing PCBs as we sell one of his products. This worked out great and he was really helpful throughout the project.

That's all for this instalment, next time I'll go into the board and electronics and putting things together.

Part 2 is available here.

A good customer and now friend Mark Beckett has been doing great work passing on his experience with electronics and Arduino to some 10-12 year olds from Swannanoa School up north of Christchurch.

We (along with Ponoko and The Shed Magazine helped out with the hardware while Mark donated his own time and money to give the kids some great education during the holidays. The course was very well received and a majority of the students have now purchased their own kits to continue to experiment with.

Great work Mark! We're really pleased to be involved.

If you've got a project that you would like to chat about, feel free to drop us a line.

The Raspberry Pi $50 Linux computer has created quite a stir selling out the first shipment within minutes and having a huge demand worldwide. People have been waiting to get their hands on the little boards for quite some time and they are just now becoming more available.

Thanks to our distributor arrangement with the fantastic Adafruit we've managed to get our hands on some great accessories so people can properly play with their little Raspberry Pi computers. The following are currently available;

• Adafruit Prototyping Pi Plate Kit for Raspberry Pi
• GPIO Ribbon Cable for Raspberry Pi
• Adafruit Pi Cobbler Breakout Kit for Raspberry Pi
• Adafruit Pi Box - a beautiful clear perspex enclosure (very limited supply right now).

If you want your own Raspberry Pi to go with these fantastic acccessories head on over to Element14 or RS Componenets who are the exclusive distributors - we don't have any sorry, no one else has.

For a recent, yet to be blogged about project I had to program 55 Arduino boards. I don't really mind repetitive jobs but you still want to make things as simple as possible. There's no point doing something that takes one minute 55 times if you can write a script in 5 minutes and then take 10 seconds to do the job 55 times. That's a saving of at least half an hour, or a lot more if you have to do the job more than once!

In this particular instance, as you can see from the picture above, we chose the Seeeduino v3.0 from Seeed Studio. There were a couple of reasons for this; one was cost, they are a large enough amount cheaper than the alternatives that when you multiply it by 55 the saving certainly adds up. Two was the low profile nature of the Atmega chip, power jack and USB connector, with the shield we stacked on top this was useful.

So if I stop beating around the bush, this is the part you want to know. Using the excellent command line Arduino toolkit, Ino and a tiny script I wrote, all you need to do is plug and un-plug an Arduino and watch the screen. That's it. This is the script;

#!/bin/bash

if [ -z $1 ]; then
    echo 'Usage: '$0' /dev/tty...'
    exit 1
fi

DEVICE=$1
NEW=true

echo 'Ready to program Arduino on '$DEVICE
while true; do
    if [ -c $DEVICE ]; then
        if $NEW; then
            ino upload
            NEW=false
            echo 'Next please...'
        fi
    else
        NEW=true
    fi
    sleep 0.2
done

For those who are after more info on the project itself I've got some more info to come which I'll be posting on the blog. Any questions in the mean time feel free to comment below.

Some guys at Trade Me got in touch the other day about an office challenge they were having. They wanted to create something like this, WiFi light painting.

Using an Arduino Mega 2560 and a bunch of super bright LEDs they created their own version. Check out the super-cool picture of the result;

This is a follow up post to my previous post from back in 2008. Andrew nicely sent me an email the other day saying that he had translated the regular expression based dial plan I created into the snom XML dialplan format. Here's what he cam up with below, thanks Andrew!

<?xml version="1.0" encoding="utf-8"?>
<dialplan>
 <TEMPLATE MATCH="3.." Timeout="1" User="Phone"/> 

 <!-- Emergency Services -->
 <TEMPLATE MATCH="1,1.." Timeout="1" User="Phone"/> 

 <!-- Local and national calling to landlines -->
 <TEMPLATE MATCH="1,[2-9]......" Timeout="1" User="Phone"/> 
 <TEMPLATE MATCH="1,0[3-4][2-9]......" Timeout="1" User="Phone"/> 
 <TEMPLATE MATCH="1,0[6-7][2-9]......" Timeout="1" User="Phone"/> 
 <TEMPLATE MATCH="1,09[2-9]......" Timeout="1" User="Phone"/> 

 <!-- Free calling (0800, 0508) and expensive (0900) services -->
 <TEMPLATE MATCH="1,0800......" Timeout="1" User="Phone"/> 
 <TEMPLATE MATCH="1,0508......" Timeout="1" User="Phone"/> 
 <TEMPLATE MATCH="1,0900....." Timeout="1" User="Phone"/> 

 <!-- Vodafone (021) -->
 <TEMPLATE MATCH="1,02102......" Timeout="1" User="Phone"/> 
 <TEMPLATE MATCH="1,021[3-4]....." Timeout="1" User="Phone"/> 
 <TEMPLATE MATCH="1,021[6-9]....." Timeout="1" User="Phone"/> 
 <TEMPLATE MATCH="1,0210[0-1]....." Timeout="1" User="Phone"/> 
 <TEMPLATE MATCH="1,0210[3-9]....." Timeout="1" User="Phone"/> 
 <TEMPLATE MATCH="1,021[1-9]......" Timeout="1" User="Phone"/> 

 <!-- 2Talk VoIP mobile numbers -->
 <TEMPLATE MATCH="1,02889...." Timeout="1" User="Phone"/> 

 <!-- All other mobile numbers -->
 <TEMPLATE MATCH="1,024......." Timeout="1" User="Phone"/> 
 <TEMPLATE MATCH="1,027......." Timeout="1" User="Phone"/> 
 <TEMPLATE MATCH="1,029......." Timeout="1" User="Phone"/> 

 <!-- Paging services -->
 <TEMPLATE MATCH="1,0261....." Timeout="1" User="Phone"/> 
 <TEMPLATE MATCH="1,0262......" Timeout="1" User="Phone"/> 

 <!-- Default -->
 <TEMPLATE MATCH="*" Timeout="15"/> 
</dialplan>

A couple of years ago we had a selection of Laptops with no Windows or operating system installed. These were mostly for people who use Linux or other Free/Open Source software. Unfortunately we haven't been able to source Laptops without Windows through the "normal" suppliers for quite a while now.

Today though, things have changed. We still can't get them, but, great news! Zareason has set up a store in New Zealand selling Laptops built from the ground up to run Linux. They are great people and if you're looking for a new laptop you must head on over there to check out their great products.

By the way we aren't related to Zareason at all, except for the fact that we both love open source. So you can take this as an impartial recommendation.

The latest Arduino creation from Italy has been released and we're now allowed to talk about it - the Arduino Leonardo. We've got a limited amount in stock now! on order which have left Italy and are winging there way to us as we speak. They should be here in around a week or 10 days.

The interesting thing about the Leonardo is that rather than having a separate chip/controller to talk USB to the computer it's all based on one micro-controller - the ATmega32u4. This keeps the price down and also allows some really neat things, like acting as a USB keyboard/mouse amongst many others. The Arduino Leonardo getting started guide is a great read and will fill you in on all the details along with a few tricks.

Along with the Arduino Leonardo comes a new maintenance release of the Arduino Development Environment (IDE) - 1.0.1 - here's the official announcement.

The main features of the Arduino 1.0.1 release are support for the Leonardo and some new translations. Apart from that there are a bunch of bug fixes so it's a recommend upgrade for everyone. Here are a couple of the bug fixes that are interesting for our usage here;

• Issue 716: DHCP lease handling - this is a big one if you work with DHCP environments and want to start using the built in DHCP support of the Ethernet library from 1.0+
• Issue 454: Add Stream.readString() and Stream.readStringUntil() that return String instances - the String objects are a time saving and convenient features so it's good to see more options for using them.
• Issue 728: Core support for ATmega1284P - the ATmega1284P (and Atmega644P) are great chips which deserve to be included in the main distribution.

Thanks for reading and keeping us here running around mad trying to keep up with everything!

The Polycom SoundStation Duo is a new product from Polycom, the de-facto standard for conferencing phones. Previously you had to choose between one of the traditional analogue conference phones or their new VoIP conference phones. Now with the new SoundStation Duo you get the best of both worlds and all at a very good price. Stock on order now and due in June.

At the end of 2010 I made a post with browser and operating stats. This is a follow up to that to see what's changed.

You'll see the graphs are a little different this time around, for a while now we've been using Piwik, open source web analytics instead of Google Analytics to give our users the option of privacy possible.

To the actual statistics. Browsers; Last year it was Firefox, IE and Webkit (Chrome/Safari) in first second and third, this year it's Webkit, Firefox and IE so a bit of a switch around.

Operating systems haven't changed too significantly, Mac and Linux are similar, Windows has lost ground to "Others". Just to mention again, our site isn't typical due to the product focus and technical audience.

I've been working on a few networked projects with Arduino lately as well as looking into combining the various home automation hacks into a more cohesive system. MQTT has kept popping up on my radar for a while now and is perfect for building my centralised home automation system. Basically MQTT is a lightweigt publish/subscribe messaging protocol, every message has a topic and an optional payload.

I have had the Open Source Mosquitto MQTT Broker set up on our server for a while now. Added a basic Python script doing some logic and some Arduino clients using the Arduino MQTT library to send button presses and flash LEDs etc.

As a proof of concept it's working fantastically, but to go further I need some sort of defined schema for home automation using MQTT. I thought I would publish this in the hopes that someone else has thought about this before and has feedback/suggestions/criticism on it.

Below is what I've come up with so far - really just a brain dump. The left side of the = being the topic and the right side being the various payload options (separated by a forward slash or a range shown by a dash). 00:00:00:00:00:00 is an example MAC address of an input or output node. $PERSON represents a unique person id.

General environmental;

/home/all/time = sunrise/sunset
/home/all/alarm = security/fire/earthquake/flood

Some meta messages designed to be sent on startup of the node, notifying the server of start and the various inputs or outputs that are available.

/home/00:00:00:00:00:00/meta/start
/home/00:00:00:00:00:00/meta/output/0 = digital/fader
/home/00:00:00:00:00:00/meta/input/0 = button/motion/light

Some environmental data, temperature etc. The beginnings of prescence to facilitate actions on peoples movements;

/home/00:00:00:00:00:00/event/env/temperature = 18.2
/home/00:00:00:00:00:00/event/env/humidity = 50
/home/00:00:00:00:00:00/event/env/light = 0-100
/home/00:00:00:00:00:00/event/presence/$PERSON = enter/exit

And the guts of it, inputs and outputs, this is the part I'm struggling with the most currently - whether to breakout the events into buttons, motion, timers etc. or stick with just input/output;

/home/00:00:00:00:00:00/input/0 = press/hold/release/motion/no-motion
/home/00:00:00:00:00:00/input/0/feedback = ?
/home/00:00:00:00:00:00/output/0 = on/off/blink/fade=0-100/timer=10

The inputs/outpus may well be on different nodes, an Arduino lightswitch, an Arduino Mega or Beaglebone inside a switching box etc.

There's other things to consider, for starters; the input/output id (on the end of the topic) will need to be translated on the node.

If anyone has any suggestions on the general schema, language used, or anything I would welcome it. Please let me know, either in the comments below or by email.

This is a follow up to our post from a couple of days on the same subject.

Whilst I still often use the code from our previous post without any issues, it was pointed out that the way it generates random addresses isn't random (the standard Arduino random functions aren't really random). This isn't an issue for most people's usage as it's not overly common to have loads (20+) of Arduino devices on the same local network.

Regardless, here's an updated version which is more random. It uses the TrueRandom library from tinkerit. The TrueRandom library generates random numbers by using a complicated algorithm, described by the authors themselves;

It is hard to get a truly random number from Arduino. TrueRandom does it by setting up a noisy voltage on Analog pin 0, measuring it, and then discarding all but the least significant bit of the measured value. However, that isn't noisy enough, so a von Neumann whitening algorithm gathers enough entropy from multiple readings to ensure a fair distribution of 1s and 0s.

The TrueRandom library does include a function to generate a MAC address for you, however it generates random bytes for all six octets of the address. This can cause issues as the first three octets are important and some network devices - such as your DHCP server - will ignore invalid addresses.

The first three octets are the "Organizationally Unique Identifier" or OUI, these are assigned to companies. I've use the OUI from GHEO Sa, which is the correct one for Arduino Ethernet. Then the rest of the MAC address or the last three octets is randomly generated.

Here's the code;

#include <SPI.h>
#include <Ethernet.h>
#include <EEPROM.h>
#include <TrueRandom.h>

byte mac[6] = { 0x90, 0xA2, 0xDA, 0x00, 0x00, 0x00 };
char macstr[18];

void setup() {
  Serial.begin(9600);
  // Store MAC address in EEPROM
  if (EEPROM.read(1) == '#') {
    for (int i = 3; i < 6; i++) {
      mac[i] = EEPROM.read(i);
    }
  } else {
    for (int i = 3; i < 6; i++) {
      mac[i] = TrueRandom.randomByte();
      EEPROM.write(i, mac[i]);
    }
    EEPROM.write(1, '#');
  }
  snprintf(macstr, 18, "x:x:x:x:x:x", mac[0], mac[1], mac[2], mac[3], mac[4], mac[5]);

  // Start up networking
  Serial.print("DHCP (");
  Serial.print(macstr);
  Serial.print(")...");
  Ethernet.begin(mac);
  Serial.print("success: ");
  Serial.println(Ethernet.localIP());
}

void loop() {
}

As it includes an external library it's a little more annoying if you want to distribute your sketch and it also adds a little size to your program. For most situations you can use either solution and be completely fine, I've added this post for completeness.

Thanks for Mike for the prompt, if anyone else has any comments please feel free to add them below.

Most of the Arduino projects we create here are network connected using Ethernet. Probably the most annoying thing about Arduino Ethernet shields is that they don't each have a unique MAC address. This means that if you're deploying a number (any number more than one, actually) on a local network then you're going to run into trouble.

Update: Here's a post showing an alternative, more random option.

A lot of people and most examples on the Internet hard-code the MAC address into the sketch. This is fine but soon becomes a hindrance if you're deploying a few boards or store your code in a version control system.

Generating a random MAC address is useful and quite simple but ideally we don't what the MAC address of each node to change each time it boots, this can cause issues with DHCP and also having a persistent MAC address is useful for sending with messages over the network to uniquely identify which node it came from.

Here's a simple example sketch which generates a random MAC address and stores it in EEPROM (non-volatile memory, the Arduino has a small amount). The random MAC address is generated on first boot, on each subsequent boot after that it is read back out of EEPROM to ensure it stays the same.

#include <SPI.h>
#include <Ethernet.h>
#include <EEPROM.h>

byte mac[6] = { 0xBE, 0xEF, 0x00, 0x00, 0x00, 0x00 };
char macstr[18];

void setup() {
  Serial.begin(9600);
  // Random MAC address stored in EEPROM
  if (EEPROM.read(1) == '#') {
    for (int i = 2; i < 6; i++) {
      mac[i] = EEPROM.read(i);
    }
  } else {
    randomSeed(analogRead(0));
    for (int i = 2; i < 6; i++) {
      mac[i] = random(0, 255);
      EEPROM.write(i, mac[i]);
    }
    EEPROM.write(1, '#');
  }
  snprintf(macstr, 18, "x:x:x:x:x:x", mac[0], mac[1], mac[2], mac[3], mac[4], mac[5]);

  // Start up networking
  Serial.print("DHCP (");
  Serial.print(macstr);
  Serial.print(")...");
  Ethernet.begin(mac);
  Serial.print("success: ");
  Serial.println(Ethernet.localIP());
}

void loop() {
}

Feel free to use this example code for whatever you wish. The only thing to watch out for is if you are using EEPROM elsewhere in your sketch that you don't clobber the values. You can remove the macstr variable and associated print lines to save on program space and RAM (memory) if you need it.

We bank with ASB Bank. They recently (yesterday) started processing incoming and outgoing funds transfers hourly throughout the day. This means that where before you would have to use a credit card to ensure your payment was cleared by us on the same day, you can now use a direct credit.

You can see the full announcement with details on processing times etc. over on the ASB website.

A few weeks back I posted here that we were looking forward to selling the Raspberry Pi. Well we're still looking forward to it but not quite as much as we won't be selling it (for now, at least).

We were talking with The foundation over email for quite a while and had lined up to distribute the Raspberry Pi here in New Zealand, things were looking good. Then unfortunately sometime in February we stopped getting email replies. Not too long afterwards we found out along with everyone else that the foundation had chosen Farnell and RS Componenets as their worldwide distributors.

Although it's great news that the Raspberry Pi boards will be easily available to everyone worldwide, it's a little disappointing finding out the way that we did. To to all our customers who were looking forward to purchasing one from us, sorry we can't help you now, perhaps in the future or with another product.

I just came across a post on the official Arduino blog about a new piece of software similar to Digi's X-CTU but cross platform for all those people who don't use Windows.

Italian company "moltosenso" has released a free, cross-platform software that allows you to configure all the parameters of your XBee modules. moltosenso Network Manager IRON is the cross-platform answer for the users of Digi International® X-CTU.

We've been waiting patiently for the Rapsberry Pi to become available as we're going to be distributing this in New Zealand and there is a lot of interest.

One thing that has concerned myself and others is the binary blobs and closed source libraries being used on the Raspberry Pi. While discussing this on the NZ Linux Users Group mailing list this morning one of the users mentioned the Allwinner A10 by Rhombus-Tech, a GPL compatible, more powerful, and cheaper ($15!) board. Now that's something to get excited about. Click through to Free Software Magazine to read more below;

You have have seen the Motorola HTPC Remote control that we got into stock late last year.

Unfortunately Pulse-Eight (through no fault of their own) ran into a bit of trouble with the quality control from Motorola's factory. After learning about this I (Hadley) personally went through the entire shipment and hand tested them for two issues;

• Left arrow button being a little hard to press
• Severe range degradation

The left arrow issue is a hardware fault and the range issue appears to be some sort of incompatibility between the dongle and certain PC motherboards USB systems.

As it turns out, a reasonable percentage of the first shipment we received turned out to be faulty in one way or another. As far as I'm aware we have now replaced all of the faulty units that were sent out before we tested the entire batch - if you still have a unit which is exhibiting any faults, let us know and we will sort it out.

Pulse-Eight have come to the party to sort everything out and have arranged replacements for all the faulty units. We're just waiting on the new hardware revision to be built and get stock shipped over to us here. Hopefully they will be arriving with us in late February.