Friday 16 March 2012


Now with added wireless

Unlike the jeenodes, arduinos don't usually come with an RFM12b wireless transmitter. But jeelabs sell a handy module.

The USB host port on the Mega ADK communicates using the SPI bus. So does the wireless module, but fortunately the bus can be shared. The three main bus signals (MOSI, MISO, SCK) can be connected to different clients, only the Slave Select (SS) needs to be separate. On top of that, the wireless module requires an interrupt line.

On the Mega board, I used pins 52, 51, 50  for SCK, SDI (MOSI) and SDO (MISO); pin 48 for SS (just because it was next to 50 and 52), and 19 for IRQ - plus of course 5V and GND.

I had to modify the jeelabs RF12 library a bit. The library expects to use either the default interrupt 0 (on pin 2), or a pin-change based interrupt on any other pin. On the Mega 2560 and ADK, four additional interrupt lines can be used. I didn't want to use IRQ 0 in case it is required for the USB host, so I used one of the additional interrupts - IRQ 4 on pin 19. To do that, I had to change the call to attach() and detach() to take an IRQ number other than 0. Pin 48 is on Port L.

Throughout RF12.cpp, I've renamed RFM_IRQ into RFM_IRQ_PIN, and then

#if defined(__AVR_ATmega2560__) || defined(__AVR_ATmega1280__)

#define RFM_IRQ 4
#define RFM_IRQ_PIN     19 // was 2
#define SS_DDR      DDRL
#define SS_PORT     PORTL
#define SS_BIT      1

#define SPI_SS      53    // PB0, pin 19
#define SPI_MOSI    51    // PB2, pin 21
#define SPI_MISO    50    // PB3, pin 22
#define SPI_SCK     52    // PB1, pin 20

 ...

#else
    if ((nodeid & NODE_ID) != 0)
        attachInterrupt(RFM_IRQ, rf12_interrupt, LOW);
    else
        detachInterrupt(RFM_IRQ);
#endif


This is successfully running the RF12demo and the pingPong demo. I still have to test how this works when both USB and wireless are active - once I can send commands from the tablet to a node connected via wireless, I've got the backbone working.



Thursday 15 March 2012

Bridged !

Finally, the tablet and the (new) kitchen node are talking. I say new kitchen node, as I've had to switch to a Arduino Mega ADK. It's not connected through ADK (we've already established that the tablet doesn't support that), but through something called Microbridge. Microbridge is a client to Android's ADB debugging interface - it can do a subset of the things the normal ADB client can do, including tunnelling TCP streams.

It didn't all go smoothly, both the Microbridge library and the example sketches need modifications before they work. I'll describe the changes that need to be done, and will link a zip of the modified files.

  • wiring.h The cpp files include wiring.h. This has been superseded by Android.h
  • Mega ADK hardware description:  max3421e.h has a section of definitions protected by #ifdef ADK_REF_BOARD. The contents of this section is correct for the board, but is not compiled. I don't know what the correct symbol for the board is, I just got rid of the #ifdef and corresponding #endif.
  • The board initialization in max3421e.cpp is not working correctly, it should look like this (change in the last line, see also this post):
     SPI.begin();
     pinMode(PIN_MAX_INT, INPUT);
     pinMode(PIN_MAX_GPX, INPUT);
     pinMode(PIN_MAX_SS, OUTPUT);
     DDRJ |= _BV (PJ2);
     
  • The examples use serial -> print, it should be serial -> write. Otherwise you get just random numbers.
  • The WriteFile example doesn't work for me, as the location used for creating the file  (/sdcard/hello) is mounted write-only. Since this example doesn't read back the result, you won't see an error message.
  •  The LogCat demo appears to be working fine (with the print/write change). You may have to unplug/replug your connection to the tablet to make sure it's in debug mode.
  • The Shell example has two problems. First, it checks the status of the connection before writing, but does not allow for ADB_RECEIVING. So it will incorrectly complain about the shell not being open.
  • The other Shell problem is that it does not send a carriage-return symbol at the end of a transmission. So you can type 'ls' into the serial monitor, but that never gets executed.
I still have to try the proper TCP transmission, but things look good so far.

Update: I've put a tar file of the modified microbridge library here. There's still something wrong with the LogCat example: you need to re-plug USB to get the tablet into USB debug mode, but that somehow immediately get cancelled again. If you first run the shell example and then the logcat example, it works. 

Monday 12 March 2012

Boiler Control

The laundry node won't just be a passive note-taker, it will also control the boiler.

Our boiler has a basic programmable timer built in, with a limited number of timing slots (which are cumbersome to change). That should be much easier with a tablet based gui, with schedules uploaded to the jeenode. The boiler provides contacts that are in series with the timer switch (by default bridged), meant for an external thermostat.  It's easy to just add a relay into the circuit, turn the built-in timer to 'always on', and have the node control the on-off times (just in case, I will add a manual switch parallel to the arduino-controlled relay, so that we can always fall back to the build-in control).

We can do more than just provide a better control of the schedules: optimized start up. Instead of pre-programming the startup time of the boiler in the morning, we can sense the external temperature over night, and then delay starting the heating to the last possible moment. The longer the house remains cool over night, the less heat we lose. There' a possible downside to this though: it could increase our consumption. After cold nights, we sometimes find it too cold for our taste in the kitchen - we've under-heated. With optimal startup, the kitchen should always be reasonably warm when we need it, but that might mean coming on earlier than we'd program it to.

Ideally, I'd want to control the temperature setting, but that would require a more invasive change to the boiler. It has a potentiometer for setting the heating circuit temperature. I'd have to either somehow connect a motor to turn the potentiometer, or replace the potentiometer with something like a switched resistor ladder. Varying the temperature throughout the day should improve the efficiency of the boiler, but that's something that may have to wait.

Update I've realized that I can find out something else: the flow through the heating circuit depends only on the state of the thermostats in the house. If most of them are closed, the pump will be able to pump less water. If very little water flows (only through the bathroom), I can consider turning off the heating (at least for a while).

Sunday 11 March 2012

Virtual Gasmeter

I mentioned yesterday that I've ordered two water flow meters. Despite measuring water flow, their main use will be to help me attribute our gas consumption.

First, the water flow meters will be cut into both the heating circuit and the domestic hot water output. Pairs of temperature sensors will go onto the incoming and outgoing pipes of both circuits. By measuring flow and temperature difference, I can work out exactly how much power the boiler is actually putting out. At the same time, I will measure the overall gas consumption at the house gas meter (luckily mine has an impulse at the lowest gear).

Most of the time (during winter) the gas will be used to heat the house - with brief periods for hot water, and for cooking in the evening. I know when we're using gas for hot water, because the flow in the heating circuit stops, and starts in the hot water circuit. But what about cooking?

That took some thinking (I considered a camera above the hob, or sensors on the cooker controls), but then I realized that I can learn a model of the efficiency of the boiler, probably dependent on outside temperature, maybe also return flow temperature. That model can be calibrated with data from times when I know I am not cooking (i.e. most of the day). Knowing the power output at any time, I can compare the gas consumption predicted by the model with that measured at the meter point - any additional gas used will have gone into cooking.

That way I can use inexpensive water meters to create virtual gas meters. And know exactly how much of our gas consumption went onto heating, hot water, and cooking.

(Virtual sensors and data driven modelling is my research area).

Saturday 10 March 2012

Shipping Charges

I want to move the project, so I've ordered more bits and pieces today.

First, since it doesn't look as if the tablet can be convinced to act in host mode, I need a USB host-capable kitchen node. There's a great new device out that could do this very well, and very cheaply - the Raspberry Pi has USB host, SPI, I2C and GPIO ports enough for what I need. But it looks as if even existing orders won't be fulfilled before April, current ones much later. I don't want to wait (though I might order one anyway). I can't use USB host shields (the SPI bus is needed for the wireless), so the only option is the Arduino Mega ADK. Overkill for what I need (with over 50 digital and 16 analog ports) expensive (certainly compared to a jeenode or a Pi, and even the tablet), and I still have to add an RMF21B wireless board; but it's a way forward. That's coming from the only UK shop I could find that actually has one in stock.

Then there's the wireless module, that comes from Jeelabs (as Seeed never did do the breakout board) in Holland.

I need some water flow sensors (also Seeed Studio) but the only place that has the 3/4 inch version that fits our heating circuit is a place in France.

And finally yet another (UK) place for some basic wires, resistors, LEDs, plugs etc.

I feel like I am paying more on postage than on parts...

Friday 9 March 2012

How green is your paper?

Last Monday, I went to Focus on Imaging at the NEC. It's great to have one of Europe's largest photo industry shows right at my doorstep.

Lots of great new kit (Canon's new flagship 5dMIII, new Nikons (but no Nikon charity raffle this year), the beautiful Fuji X-Pro 1), good talks, beautiful models, even minor celebrities (James and Ola from Strictly). And what excited me most? Paper.

Yes, the wonderful range of inkjet photo paper from a number of manufacturers. There's so much beautiful paper out there, both matt and glossy. I own an Epson 2880 printer, and I love printing and framing my own pictures. There is something special about making the physical artefact, at least a tiny bit back to the film and darkroom days of photography (I used to have a B&W darkroom as a teenager).

The next day we went to Stirchley Market where we sold a decent number of my postcards. That started me thinking: could I print the postcards myself?

At the moment, we have the photos printed by CEWE in Germany, and mount them onto recycled card stock . Commercial photo printers still use a chemical process onto modern photo paper (plastic), and produce chemical waste. Printing myself, apart from being a rewarding process, could be a lot more environmentally friendly. It might also be less labour intensive, and hopefully not much more expensive?

So, I started to find out about the environmental background of different papers. I asked the guys at www.on-linepaper.co.uk, and Simon Redgrove was very helpful, suggesting I look at Innova. I did, and asked them and some other suppliers about their environmental policy. This is what I found out so far - and it looks surprisingly positive:

Hahnemühle have a clear environmental policy (though I'd like that to be a bit more explicit) and support ecological projects. I love Hahnemühle's Bamboo paper - as the name implies, it's made from Bamboo, so potentially a green source. But it's a matt paper, so not ideal for postcards, and quite expensive.

Innova have a very clear environmental policy. They confirmed by email that all their stock is FSC sourced, though because the coating they put on the paper, the paper itself does not carry the FSC logo.

Similarly, St. Cuthberts Mill (also makers of Somerset papers) have a very clear environmental statement, claiming their stock is from 'sustainable sources'.

To my surprise, Permajet also claim that all their raw material is FSC certified. There's nothing about that on their web site, but they've promised to send me a statement from their mill. Permajet's paper is more budget-friendly, so I am really hoping they can document that claim (also, I want to switch to their continuous ink system).

Rag (cotton) paper is an interesting case - cotton production often has a negative impact (water use, pesticides, GM crop), but the material used is the outer husks, which are a by-product of the cotton industry. For that reason, this very good review of photographic paper argues that cotton paper is the best choice as long as you don't have certified FSC stock.

I haven't had a reply yet from Fotospeed, and there are a few more manufacturers I might contact.

In terms of costs, it turns out that the whole enterprise is a lot more difficult. Ink cost is just about OK when using a CIS (about 17p per A5 print, compared to 68p with Epson inks...). The paper however can quickly cost 1£ or more for an A4 sheet (to fold to A5). It looks like the only way to do it is to print onto 4x6 inkjet paper (about 12p) and stick that onto the recycled card stock...

Sunday 4 March 2012

Call that progress?

A friendly user from the tabletrepublic forum pointed out that I was using the wrong version of the google accessory API: the com.android.future.usb.accessory API is only used on pre-gingerbread versions of the OS. Anyone else should use android.hardware.usb instead.

With that fixed, the app can be loaded onto the tablet. The device correctly switches to accessory mode, and usbManager even logs that as an event in logcat. But as in my host mode attempts, mUsbManager.getAccessoryList() always returns an empty list. The intent I registered is never called either.

Still not there.

Watching logcat while the tablet is running is quite scary, btw: so many exceptions thrown and signals not caught...

Saturday 3 March 2012

Time for plan C?

Plan B was to run the tablet in client mode, using the Android Accessory API. As it turns out, that API is also not supported by Ainol. There is a /dev/usb_accessory, which might imply that kernel support is present. But library support isn't, when I upload some test code, I get I get requires unavailable shared library com.android.future.usb.accessory. 


It also turns out that using one of the USB host shields with the Jeenode wouldn't be ideal. The reason is that the shields communicate with the host using SPI. There is a hardware SPI bus on the Jeenode, but it's already used by the radio module, and sharing is tricky. It's possible to implement SPI on some of the general purpose pins in software, but I'd rather not go that route.

So, time to rethink. What's plan C? Replace the tablet? My chances would be slightly better with an ARM based device, but it's difficult to know what APIs are implemented without testing. As it is, the Ainol Paladin is pretty awful for this purpose.


Thursday 1 March 2012

USB blues

As it turns out, power is not the only problem I have with the tablet.

First, a bit about the tablet. It's an Ainol Novo Paladin - currently the cheapest tablet running ICS, with a capacitive screen, and not using a VIA CPU.  It's nice enough, and after upgrading it to 4.0.3 with an unofficial build, and getting rid of all the pre-installed Chinese apps, you're left with a responsive tablet with many of the basic apps working. This includes youtube, but not for example a working BBC iplayer.

It's Achilles Heel is the processor - unlike nearly all android systems out there, it's not an ARM  based processor, but a MIPS processor. While pure java apps work OK (and something I wrote for a phone in 2.2 worked immediately on the tablet, save a few scaling issues), any app that uses native compiled code won't work. And that excludes a lot of the apps on the Android market. That wouldn't be a problem, I thought, as I was going to write my own code, in java.

First I had to get a working adaptor cable. The tablet has a mini-B type OTG socket. 'Normal' USB connectors always have one type of connector for the host ('A' type, e.g. the flat one in full-sized plugs) and one for the client ('B' type, the square plug) - to make sure that it's not possible to create host-host or client-client connection. For USB OTG, the same socket on the device can be used as host or client, so the shape of the socket needs to accept plugs intended for either clients or hosts. To tell the device to switch (think of connecting two phones, one will need to become host), there must be something different in one of the two plugs. The difference is the 'X' or 'ID' pin (pin 4) - for clients, it is left floating; on the host side this pin is connected to ground. And, as I already found out, to tell the device that it is host, but allowed to charge of VBUS, that pin is connected to ground through a 124k resistor (but don't take my word on this, read the spec, and make sure your device actually implements this).

So you can't just make your own OTG cable by cutting off a connector from an old USB cable and soldering it onto another one, as the ID pin will be left unconnected. Instead, I bought a solderable Mini-USB plug (the only one I could find in the UK). But what you can't see in the photo is that the ID pin is trimmed off - instead of a solder pad, it only has a stub less than 1mm square! The nice people at hobbytronics confirmed that yes, all the plugs are like that.

But it is possible to solder a wire to it, with a bit of care (and two attempts in my case). The tablet reacts as expected - with the other end of the wire unconnected, it remains in client mode; with the wire touching ground, the tablet goes into host mode and powers the device (e.g. a keyboard works). Connected devices also show in /proc/bus/USB/devices.

That's where it stops. Unfortunately, it appears that Ainol did not bother to support Android's USB host  API. When I call UsbManager.getDeviceList(), the result is always empty. I am not the only one with this problem, apparently some tablets do, some don't, implement USB host.

What alternatives are there? FTDI, the makers of the serial/USB chip on my jeenodes, actually provide a nice Android library. Looks ideal, but it uses a native library, and that's only available for ARM. Compiling an FTDI driver into the kernel won't work for a similar reason - there is no source release for ICS that works for MIPS.

It now looks as if I need to change my hardware. Either sell the tablet and find one that does support the host mode API (and runs ARM), or turn the jeenode into a USB host instead. The USB host mini shield  seems the cheapest way to do that; the Arduino Mega ADK is a lot more expensive and would need an RFM12b module added. With the tablet running as client, I should be able to use the Android Accessory Protocol mode - running as client would also solve the power problem. That's assuming the AAP API is implemented, but I can (and will) test that.


Saturday 25 February 2012

Now we're talking

I soldered up the second jeenode today (the USB node came ready assembled), good fun, haven't done that for a while. I then compiled the RF demo from jeelabs (make sure to get the jeelib library from https://github.com/jcw/jeelib#readme, and not the RF12 and Port libraries), loaded both nodes up, et voilá, I can send packages from one to the other.

They don't work too well when close together, but I took one downstairs and the communication was very good. I will need to carefully design my protocol though, to ensure that while packets are lost, no data is lost.

Friday 24 February 2012

The first 'gotcha'

The tablet arrived, and so have the parts from jeenode!

The tablet is nice, especially after I did some updates on it  - more about that some other time.

I got the arduino development tools to work, too. If you're using a jeenode USB, the instructions given on JeeNode Tips are a bit out-of-date: if you get arduino programmer is not responding errors, you need to change the device type to Uno (I think the bootloader has been updated). Then you can just take one of the example sketches, go to 'upload' - and see it working (with small changes - the 'blink' sketch assumes an LED on pin 13 - it's on pin 9 on the jeenode).

In eclipse, I went with this Arduino plugin - a fork from the official WinAVR plugin. It appears to work, though Eclipse is throwing java.lang.UnsatisfiedLinkError: no spawner in java.library.path in the path configuration - so I had to configure all the paths by hand. By default, the executables are all in /usr/bin, the header files in /usr/lib/avr/include, the IDE path is /usr/share/arduino, and I have no idea where the Atmel part description files are (or what they are, for that matter). I wonder if the problem is cause by setting the java library path in eclipse.ini for subclipse (see yesterdays post), but removing that entry doesn't seem to help.

That wasn't the 'gotcha', unfortunately. The gotcha is that the tablet only has one USB OTG mini-b socket, and no external power connection. In the OTG standard, the host device (the tablet in my setup) provides the power. When the battery is empty, I have to unplug it and charge - but that won't do if the tablet is the user interface for the whole system.

Fortunately, it looks as if there is a provision for exactly this in the USB OTG standard (thank you Wikipedia for linking to it). The USB Accessory Charger Adapter is a three-way connection between host, client, and charger. Has anyone ever come across a device actually implementing this? (don't confuse this with the USB splitter cable that's plugged into two ports on the host, to double the current). From reading the spec, since I am only interested in a single use case, it looks like a resistor in the plug at the tablet might be enough to tell it that, while it's the host, it is allowed to draw charge.

Of course, that depends on if the tablet actually implements OTG, including that part of the spec. It's not clear, as some other tablets come with a dongle that adds a second port and ethernet adapter - that would suggest it's connecting to a hub, which OTG can't do (I think?). Maybe there is another way of switching from client to host role without following the OTG standard.

I don't actually have a cable yet that goes from USB mini male to USB A female, so I can't try what happens if you plug in a hub.

Thursday 23 February 2012

Eclipse with Android and Subversion

In preparation for the coding, I spent some time updating eclipse for Android and Subversion.

To get the Android eclipse development environment to work, I ended up re-installing eclipse from scratch - it told me it had conflicting requirements between ADT and java-EE, and refused to budge. I had to install the 'proper' sun jvm too, no luck with the openjdk version. After that, installing adt as described in google's page worked fine. I still had an old SDK installation, it was happy to update that to the current state (btw: there are no 'close' buttons on the eclipse android configuration pages: use 'escape' to close).

Subversion was a bit more tricky. Debian installs svnserve with the basic svn package, but no startup scripts. This page describes how to set up the '/etc/init.d/svnserve' script that starts up svn - just change the path to the location of the repository. The repository needs to be created with 'svnadmin create path/to/rep' (it creates a few files and directories at that location), and I needed to set up permissions. See Tony's helpful page for how to.

I didn't import an existing directory (as Tony does), instead I installed RapidSVN - an SVN Gui - and used that to create a new directory within the repository (modify -> make directory). This directory will be the root for all parts of this project - android and arduino based. The URN for the svnserve server, if installed on your local machine with default settings, should be svn://localhost:3690 (svnserve doesn't support http based browsing).

The subclipse plugin caused another eclipse problem. On a windows machine recently it was straighforward.  On linux you have to install JavaHL individually - and while it's available as libsvn-java, neither debian nor ubuntu currently have version 1.7 of this library which is required for the 1.8 subclipse plugin. However, as this post notes, debian and other packages for javaHL 1.7 can be found at this repository. I just added
deb http://opensource.wandisco.com/debian squeeze svn17
into my /etc/apt/sources.list, added the signature to my key ring, and updated libsvn-java.

I am a bit jealous of the tortoiseSVN windows client, which is very nice, mainly for browsing and organizing the repository. I am now trying RabbitVCS, maybe that's similar (Debian is 2 versions behind though, as it is not using Nautilus 3 yet).

Update while debian's libsvn-java puts the javaHL libraries into /usr/lib/i386-linux-gnu/jni, the version from wandisco is stored at /usr/lib/jni. The correct path needs to be added to the eclipse.ini file (' -Djava.library.path=/usr/lib/jni')

Wednesday 22 February 2012

The other kitchen node: arduino takes the tablet

The kitchen node I described in the previous post has a USB port. Why?

Because the kitchen will also house the user interface. As I mentioned before, I initially looked at the Raspberry Pi. But I wanted a nice touch screen to go with it, and they aren't cheap. And then I realized that by the time I add wifi, sound (for alarms, if nothing else), and power, I might as well get one of those cheap Chinese Android tablets. I'll save all the hassle of connecting the display and touch screen, and have a powerful environment to program the UI.

So, somewhere mounted on the kitchen cupboards, we will have a nice 7in tablet, talking to the Jeenode using USB. The one I've ordered (Ainol Paladin) is not the cheapest available, but it's the cheapest running Android 4.0 (so I can play with the newest Android version), has a capacitive screen, and it's not one of the (reportedly) underpowered VIA 8650 based systems.  Apparently, the VIA chip is on its way out, to be replaced by something faster. I would have liked an Allwinner 10 based device, but they are more expensive.

There remains the question how to connect the tablet to the jeenode. One option I found is a low-level debug mode based connection as used in the IoIo. That's supposed to work on most devices, but the ioio is a bit more expensive, and since it's not actually an arduino-type node (more of a dumb direct io extension of the android device), driving an rfm12b wireless node off it is not straightforward.

The other option is based on Android's new Open Accessory Development Kit. Not all devices support this mode, and because the USB host in this case is the arduino, it needs a more powerful (and expensive) mega based node.

But don't tablets support USB host mode? After all, most of them come with external dongles with ethernet and additional USB ports? That wouldn't make sense if they only could work as USB clients.

Indeed they do, and as this great post describes, it is possible to connect Arduinos as simple serial clients. Perfect.

At least, that's the theory. The tablet will come tomorrow (and there's always a worry about quality with cheap Chinese devices), and the jeenode parts have shipped from Holland as well. We'll find out.


Tuesday 21 February 2012

The Kitchen Node

In the kitchen, we currently have an ageing X10 based system to switch three light circuits. When we moved in, all three lights were on the same circuit, so the kitchen was either dark or blazing. I couldn't reach all the wires to put in a new threeway switch, so I had to fit a remote system. It's not terribly robust, there is a noticeable delay between pressing the button and the light switching, and the switch itself is not very intuitive (I keep pressing the wrong buttons). 

The first task for the new system will therefore be to replace the X10 relays. The controller will be a USB jeenode. After looking at many different arduino based systems, my conclusion is that jeenodes offer the best design for my home system - they are very cheap, have radio built in, convenient connectors, and offer a small form factor.

I initially planned to use two Relay plugs for the three lights, but in the end decided to go for three relay nodes from a different supplier (Ciseco). My budget is very tight, and this option is a bit cheaper - they'll be wired straight to the jeenode's pins (using up two of the four connectors). I've also dropped the jeenode's carrier board and box - I'm sure I can find two plastic boxes, one for the node, and one for the relays to keep the high voltage bits separate.

On one of the remaining connectors, I'll connect a temperature sensor. The room board would be nice, but had to go for now;I can add that later when there's a bit more money.


Monday 20 February 2012

The Background Picture

Snowdrops in the orchard of Cotteridge Park, taken 29/01/2012.

Home Energy Controller

And this is my big new project: building a system that makes it easy to control and monitor the energy we use at home.

I have a strong interest in environmental conservation, and in energy use. I took part in Nesta/UKERC's Carbon Crucible program, and I had EPSRC funding for a feasibility study in analysis of energy monitoring data. The UK is trailing behind many other EU nations when it comes to real, implemented CO reductions (they just keep announcing things and then not realizing them). Taking action locally seems the only way to achieve at least some level of improvement.

The other reason for this project is that I want to build up some experience in embedded devices, play a bit more with Android, and after a long break get back to tinkering with electronics.

It all started with the Raspberry Pi excitement - $25 for a small but powerful Linux based computer - so many things one can do with it. Initially I was thinking about connecting to the systems in our car (I am currently working with an automotive engineering company),  but then I found the Open Energy Monitor page - offering open hardware and software for home energy monitoring. That seemed a much more useful project - and one where I could justify (to myself and the rest of the family) spending the time and money.

The current plan calls for three nodes: one in the kitchen, providing the user interface and replacing the ageing X10 based light control; one in the laundry controlling and metering the boiler, and one in the lobby metering gas, electricity, and quite a few temperatures indoors and outside. The overall bill of parts should hopefully stay bellow £250.



Sunday 19 February 2012

Why I started this blog

A while ago, I had to dismantle the front hub on my bicycle. It's a generator hub, powering the lights on the bike, so there are delicate electrical contacts to take care of. Luckily, some kind person had put a set of photos online, describing exactly how to disassemble (and, more importantly, reassemble) the hub.

It's not such a common hub, and I doubt that more than a dozen or two people would have benefited, but for me it was exactly the information I needed.

Since then, I've had a number of occasions where, after spending hours working out how to solve a particular problem, I thought it would be good if I could just document it somewhere where other people could find it. It doesn't matter if no one actually reads the blog - as long as google indexes it.

The other reason is that I am embarking on a DIY project that I want to document. More about that in my next post.