Background

Back in 2008 Martin Woodward did a post on using a Nabaztag as a build monitor for TFS, ‘Brian the build bunny’. I did a bit more work on this idea and wired into our internal build monitoring system. We ended up with a system where a build definition could be tagged so that it’s success or failure caused the Nabaztag to say a message.

image

This all worked well until the company that made Nabaztag went out of business, the problem being all communication with your rabbit was via their web servers. At the time we did nothing about this, so just stopped using this feature of our build monitors.

Getting it going again

When the company that made Nabaztag went out of business a few replacements for their servers appeared. I choose to look at the PHP based one OpenNab, my longer plan being to use a Raspberry PI as a ‘backpack’ server for the Nabaztag.

Setting up your Apache/PHP server

I decided to start with a Ubuntu 12.04 LT VM to check out the PHP based server, it was easier to fiddle with whilst travelling as I did not want to carry around all the hardware.

Firstly I installed Apache 2 and PHP 5, using the command

sudo apt-get install apache2
sudo apt-get install php5
sudo apt-get install libapache2-mod-php5
sudo /etc/init.d/apache2 restart

I then downloaded the OpenNab files and unzipped them into /var/www/vl

Next I tried started to work through the instructions on the http://localhost/vl/check_install.html I instantly got problems.

The first test is to check is that if you ask for a page that does not exist (a 404 error) it should redirect to the bc.php page. The need for this is that the Nabaztag will make a call to bc.jsp, this cannot be altered so we need to redirect the call. The problem is this is mean to be handled by a .htaccess file in the /var/www/vl folder that contains

ErrorDocument 404 /vl/bc.php

I could not get this to work. In the end I edited the Apache /etc/apache2/httpd.conf  and put the same text in this file. I am not expert on Apache but the notes I read seemed to infer that httpd.conf was being favoured over .htaccess, so it might be a version issue.

Once this change was made I got the expected redirections, asking for an invalid folder or page caused the bc.php file to be loaded (it showing a special 404 message – watch out for this the text in the message it is important, I had thought mine was working before as I saw 404, but it was Apache reporting the error not the bc.php page)

Next I checked the http://localhost/vl/tests to run all the PHP tests. Most passed but I did see a couple of failures and loads of exceptions. The fixes were

  • Failure of ’testFileGetContents’ – this is down to whether Apache returns compressed content or not. You need to disable this feature by running the command

sudo a2dismod deflate

  • All the exceptions are because deprecated calls are being made (OpenNab is a few years old). I edited the /etc/php5/apache2/php.ini file and set the error reporting to not show deprecation warnings. Once this was done the PHP tests all passed

error_reporting = E_ALL & ~E_NOTICE & ~E_DEPRECATED

Next I could try a call to a dummy address and see that files ‘burrows’ folder and I got some gibberish message returned. This proved the redirect worked and I had all the tools wired up

Note: Some people have had permission problems, you might need to grant to write permissions to folder as temporary files are created, but this was not something I needed to alter.

It is a good idea to make sure you have not firewall issues by accessing the test pages from another PC/VM

Getting the Rabbit on the LAN

Note: I needed to know the IP address of my PHP server. Usually you would use DNS and maybe DHCP leases to manage this. For my test I just hard coded it. The main reason was that Ubuntu cannot use Wifi based DHCP on a Hyper-V

The first thing to note is that the Nabaztag Version 2 I am using does not support WPA2 for WIFI security. It only supports WPA, so I had to dig out a base station for it to use as I did not want to downgrade my WIFI security.

Note: The Nabaztag Version 1 only does WEP, if you have one of them you need to set your security appropriately.

To setup the Nabaztag

  • Hold down the button on the top and switch it on, the nose should go purple
  • On a PC look for new WIFI base stations, connect to the one with a name like Nabaztag1D
  • In a browser connect to 192.168.0.1 and set the Nabaztag to connect to your WIFI base station

image

  • In the advance options, you also need to set the IP address or DNS name of your new OpenNab server

image

  • When you save the unit should reboot
  • Look to see that a new entry in the /vl/burrows folder on your OpenNab server

So at this point I thought it was working, but the Nabaztag kept rebooting, I saw three tummy LEDs go green but the nose was flashing orange/green then a reboot.

After much fiddling I think I worked out the problem. The OpenNab software is a proxy. It still, by default, calls to the old Nabaztag site. Part of the boot process is to pull a bootcode.bin file down from the server to allow the unit to boot. This was failing.

To fix this I did the following

  • Edited the /vl/opennab.ini file
    • Set the LogLevel = 4 so I got as much logging as possible in the /vl/logs folder
    • Set the ServerMode = standalone so that it does not try to talk to the original Nabaztag  site
    • I saw that the entry BootCode = /vl/plugin/saveboot/files/bootcode.bin, a file I did not have. The only place I could find a copy was on the volk Nabaztag tools site
  • Once all these changes were made my Nabaztag booted OK, I got four green LEDs, the ears rotated

When you power up the Nabaztag, it runs through a start-up sequence with orange and green lights. Use this to check where there’s a problem:

  • First belly light is the connection to your network - green is good
  • Second belly light is that the bunny has got an IP address on your network - green is good
  • Third belly light means that the bunny can resolve the server web address - green is good
  • The nose light confirms whether the server is responding to the rabbit’s requests - green is good

A pulsing purple light underneath the rabbit means that the Nabaztag is connected and working OK.

Sending Messages to the Rabbit on the LAN

Now I could try sending messages via the API demo pages. The messages seemed to be sent OK, but nothing happened on the Rabbit. I was unsure of it had booted OK or even if the bootcode.bin file was correct.

At this point I got to thinking, the main reason I wanted this working again was the text to speech (TTS) system. This is not part of the OpenNab server, this function is passed off to the original Nabaztag service. So was all this work going to get me what I wanted?

I was at the point I had learnt loads about getting Apache, PHP and OpenNab going but was frankly I was not nearer what I was after.

A Practical Solution

At this point I went back to look at the other replacement servers. I decided to give Nabaztaglives.com a go, and it just worked. Just follow their setup page. They provide TTS using the Google API, so just what I needed.

Ok it is not a Raspberry PI backpack, not a completely standalone solution,  but I do have the option to use the Nabaztag in the same manner as I used to as a means to signal build problems