Content analysis details:   (5.9 points, 3.8 required)                          
                                                                                
 pts rule name              description                                         
---- ---------------------- --------------------------------------------------  
 1.0 NO_REAL_NAME           From: does not include a real name                  
 1.0 HTML_MESSAGE           BODY: HTML included in message                      
 0.0 BAYES_50               BODY: Bayesian spam probability is 40 to 60%        
                            [score: 0.4956]                                     
 1.4 HTML_10_20             BODY: Message is 10% to 20% HTML                    
 1.5 MIME_HTML_ONLY         BODY: Message only has text/html MIME parts         
 1.1 HTML_MIME_NO_HTML_TAG  HTML-only message, but there is no HTML tag         

That's the registration verification email from the National Do Not Call Registry.

We're now the proud owners of a Wii.

Sarah was discharged today. I decided to scrap trying to go to work, as I'd just have to leave at some point to pick her up. The hospital had to ensure that the nurse from Critical Care Systems was able to come to our home before they could discharge her, so that the IV antibiotics could be continued.

We left the hospital at about 11:30am, and he got to our place just after 1pm.

He whizzed through the whole process, as she was due for more antibiotics at midday and he wanted to get the IV started. She's on a four hourly course. Fortunately, that doesn't mean we have to change the IV every four hours.

The way it works is the bag has enough antibiotics in a (presumably saline) solution to last six infusions on a four hourly frequency, and it's hooked up to a pump (that'll cost us $5000 if we don't give it back at the end), which takes care of everything.

So once a day at around noon, Sarah has to disconnect the old bag, flush the line with saline, do something with some Heparin to prevent clots in the line, and hook up a new bag. The bag and the pump fit into a carry bag that can be worn like a bum bag or slung from her shoulder and looped through a belt. It'll be her permanent companion for the next (hopefully only) two weeks.

The PICC has two ports (and I don't think that's the correct term) on it, and the IV is only hooked up to one, so the other one should be flushed and "Heparinised" regularly as well. The nurse comes back in a week with more supplies and to do some maintenance on site where the PICC line enters her arm.

Critical Care Systems seems pretty impressive. They provide all the gear, fill the prescription, and bring it all out to you (by a nurse). They provide a 24 hour hotline to call if there's any problems, questions or concerns, and can dispatch somebody to us if necessary. We've got syringes preloaded with saline and Heparinised saline, more alcohol swabs than you can poke a stick at, and the fridge is full of IV bags.

It's awesome that medical technology has progressed to this point, where Sarah can go about her business almost as normal, instead of being stuck in a hospital for another two weeks just because she has to have a tube in her arm.

To prove this, the little trooper was back at her CNA course this evening, and starts clinical training tomorrow night.

It's been a somewhat long day...

I got up at 6:30am for a 7am ankle physical therapy session.

I went to the hospital after that. When I got there, a sonographer was doing the echocardiogram on her heart to check the valves. I missed the doctors. Sarah didn't feel any more knowledgeable about her condition even though they'd been through.

The patient Sarah was sharing with had a bad night, caused her to have a bad night's sleep also, and she always deals with all of this crap much worse when she's got a sleep debt.

Dinner stayed down, but breakfast did not.

The sonographer seemed fairly confident about her heart condition. Usually they don't make any comments on what they're seeing and leave that to the doctors, so we took some comfort from that.

I managed to corner the physician's assistant who had been following Sarah in her office, and quizzed her on what was going on.

It turns out a PICC line had been ordered, and they get installed by specalised PICC nurses and that's all they do all day. The PA implied that it might not happen until tomorrow. The gall stones were definitely unrelated, and something to follow up with her primary care physician. Incidentally, Wikipedia has some wicked pictures of gall stones. Talk about freaky.

I think I hung around until 10am, and then headed into the office to try and get some work done, with the intent to come back after work.

Not long after, Sarah called me up all beside herself about the PICC line (she doesn't deal well with the idea of getting jabbed at the best of times, and being tired put her over the edge), so I scrapped work, and went back to the hospital for the remainder of the day.

I decided to hunt down her cardiologist to see if the PICC line was absolutely necessary, and I managed to get the exact low down on her condition.

• the infection is staphylococcus aureus, not one of the other staph strains that I can't remember, which are considered less serious. The one Sarah has/had is the "bad enough" one, a.k.a. "golden staph". Fortunately it's sensitive to antibiotics, unlike MRSA, which is the really bad news one to have. So my heart skipped a beat when he said it was aureus, but I recovered when he said it was sensitive. I could have sworn the staph infection she had last year wasn't aureus, but he seemed to think that it was.
• when she presented at the ER on I guess Sunday morning, this staph was found in the blood sample they took. What is unclear is whether this is because of contamination from the skin when they took the sample (staph is present on the skin, it's only a problem when it gets internal), or it was indeed in her blood, whereas with the infection she had last year, it was never present in her blood.
• because of her aortic root replacement/graft and the risk of endocarditis destroying her heart valves, they didn't want to take any chances. Hence the PICC line and the two weeks of intravenous antibiotics. Two weeks is really a compromise. He said if they'd wanted to get all paranoid on her, it'd be a six week course, and they'd have done a transesophageal echocardiogram to boot.

So armed with the facts, I headed back to tell Sarah the news that she really should have the PICC line installed, and that she was getting off fairly lightly, relatively speaking.

The PICC nurse had a cancellation, so she was able to do the installation today. It was totally less traumatic than I think either of us were expecting.

It took about 45 minutes to install, and it was done at her bedside. Sarah was very brave and I don't think it really hurt her all that much. I watched the whole thing, and it was very interesting. It was particularly interesting because there was another nurse observing, so the PICC nurse was explaining everything as she went. She was also really nice and good at what she did (she'd been doing it for 14 years) so I think all of that helped.

So Sarah's now got two IV ports strapped to the inside of her upper left arm (attached to the PICC line), and no other IV lines in. She should get discharged tomorrow after they sort out whether she's going to receive IV antibiotics on a 4 or 8 hourly schedule at home, and exactly how all of that's going to work. I think they send someone out to our place to give us some training, and someone comes out once a week to do a bit of maintenance on the PICC line itself. I presume I'll be her personal nurse again. All it involves is a bit of plumbing.

Her cardiologist seems to think she should be able to still do her CNA clinical training with the PICC line in. She may just have some problems with lifting duties. I guess we'll just see how all of that pans out.

So that was the excitement for today. Sarah had her appetite back at dinner time, and was generally in much better spirits when I left her this evening than she was this morning. I could go into much more detail about the ins and outs of the PICC line installation, but I don't really have the energy.

And I thought the recovery from original heart surgery was a bit rocky...

Let me try and gather my thoughts...

Yes, Sarah's got gall stones, no, they're not the problem.

Yes, she's definitely got a staph infection, no, it's apparently (again, fortunately) not the bad type, but unlike last time, it is in the blood.

Apparently that makes endocarditis a bigger concern, the consequences of which are rather scary to put it mildly. I'm guessing this is why they're pumping her full of IV antibiotics.

The doctor(s) that is/are looking after her only do their rounds in the morning, so we've only got all of this information out of band from the cardiologist who popped in to see her this afternoon and sneaked a peek at her chart. So the exact course of action is unclear. He mentioned the possibility of getting a PICC line, which can stay in for up to a month, so they can continue giving her IV antibiotics for a while. We don't know if that means they could or would then discharge her. They want to do an ultrasound of her heart tomorrow to make sure everything's still okay there.

Pain-wise, she's doing better. She hasn't had any more IV pain medication since this morning (just oral stuff), but she hasn't got much of an appetite since throwing up last night. She did eat some dinner though. Nausea has been coming and going throughout the day.

Despite all of this, she's in fairly good spirits and is fairly mobile.

I'm going back to the hospital tomorrow morning to try and catch the doctor(s) when they do their morning rounds.

Somewhat ironically, this hospitalisation is now buggering up her attendance at the Certified Nursing Assistant course she's doing in the evenings. She was due to start clinical training this week. Somehow, even if she were to be discharged tomorrow, I don't see how working in an aged care facility with a PICC line, an open (albeit packed and covered) chest wound and a staph infection is going to be a good idea for anyone involved.

Seriously, every time Sarah has surgery, it all goes pear shaped.

The bottom (last time it was towards the top) of Sarah's incision from her recent wire removal surgery was looking a bit red, swollen and hard on Friday, so she went in to the clinic at got them to take a look at it.

They decided that a knot in the sutures was trying to work its way out, and causing inflammation or something, so just like last time, they decided to reopen the incision a bit. They did that, and cut the knot out, and rather than packing with gauze, they just taped the small opening closed with some steristrips and covered it with gauze and sent her on her way.

Somewhat fortunately (for me) Sarah went into the clinic during the day while I was at work, so I missed participating in the fun and games. They didn't use any local anaesthetic, but Sarah said it didn't hurt too much.

That night, though, she was in a reasonable amount of pain, again, similar to last time, except it was a band across her upper abdomen, below her breasts, instead of chest pain.

Mindful of the staph infection disaster from last time, we trotted off to the ER on Saturday afternoon, hoping to nip this in the bud. They did some blood work, which came back clear, and gave her some IV pain medication, which didn't seem to do much, and were generally scratching their heads as to the cause of the pain.

Fortunately, one of the surgeons involved with Sarah's wire removal from 2.5 weeks previously happened to be on call, so he got called in. He had a bit of a poke around the opening with a long cotton bud, and declared that it was possibly infected, because there was a bit of cloudy fluid discharged when he poked it in. Oh, and the cotton bud disappeared a good centimetre or more under the skin further up the incision, which indicated an abscess was forming.

So, for the second time, I got to watch my wife being cut open with a scalpel. I think the local anaesthetic injections were the most painful part for her. He opened the incision up a bit further, and packed it with some Betadine-soaked gauze, and we got sent home with the same instructions as last time this happened: I had to repack the wound with saline-soaked gauze two to three times a day and let it heal from the bottom up. She was also prescribed some antibiotics. She's got about a 2cm incision just below her breasts. It looks a lot deeper than the hole from last year's incision.

So we got home about 6pm last night, and went to bed around 11pm. Sarah lasted a couple of hours before she woke up in even more pain than before. She called up the hospital and had the same surgeon paged, and he advised her to come in to the ER again. So at I think about 2am, we headed back.

They took some more blood, did a CT scan, which came back clear, and decided to admit her. They're giving her IV antibiotics and pain medication. Initially she didn't want to have any more IV pain medication because it didn't seem to be working, and it tends to make her nauseous. She wasn't keen on dealing with throwing up with the amount of pain she was having. It hurt to move as it was.

With a mixture of IV anti-nausea drugs and the IV pain medication, the pain has finally come under control though. She did have one bought of vomiting this evening, which didn't seem to cause her too much discomfort, and she's getting in and out of bed more comfortably. They're going to keep her in overnight. She has a post-operative followup tomorrow in the clinic, so I expect they'll keep her in the hospital until at least then, depending on how things go.

Her cardiologist, intimately familiar with last year's debacle, dropped in this afternoon. He's wondering, given how this has happened twice now, if Sarah has some sort of allergy to the type of absorbable suture they've used. Apparently there are different types of sutures, so if she ever has any other surgery, we'll have to get them to try a different type

It'll be interesting to see how she goes tonight, as the pain seems to get worse overnight. She hasn't had any IV pain medication since about 1pm, and she wanted to see how she goes without it, because if she gets discharged tomorrow, she'll have to rely on oral stuff anyway.

I think it definitely gets harder for her to manage her pain when the pain is causing her to lose sleep. She can only deal with having a couple of night's worth of bad sleep before it all gets too much. So I'm really hoping she gets a good night's sleep tonight. Not that hospitals are renowned for that...

The project that I'm responsible for got a very tiny mention in this bio of Mark Shuttleworth in the New York Times.

Continuing with my mission to control the power to some dumb USB-powered lights...

Dann Frazier confirmed my theory that a USB hub would indeed do the job. I'd already found the hub-ctrl.c program he mentioned, but couldn't get it to work with my built-in USB ports of my laptop.

It seems it all depends on whether the hub will support per-port power switching or not. (lsusb -v will tell you).

So off to the mighty institution that is Fry's Electronics I went.

The first two attempts failed, as did a borrowed hub. It seems most (at least the cheap one) use a Genesys Logic chipset, which does not support per-port power control. Fortunately I chose products that weren't in blister packs, so I was able to return them to Fry's in as-new condition and try again.

Now that I knew USB hubs would do the trick, I did some more targeted searching, and found this thread where someone had been messing around with hubs to do what sounded like what I wanted. (Incidentally, this email in the thread also provided a nice looking Python program. I'm going to look at refitting it to use the "real" Python USB module.)

I emailed the poster to ask him what brand of hub he was using. The answer was the Linksys 4-port hub

So I managed to track down one of them last night. Yes, it works, but the downside is the hub itself requires external power, which is a bit unfortunate. Not only do I need to use a hub to make these lights software controllable, I have to plug the hub into a power outlet. Bleh.

Wouter's post prompted me to write this...

I find it particularly strange to have a single filesystem for everything, especially so on a laptop. I worked with a guy once who had the single filesystem (I think it was ext2 or ext3), and his laptop crashed, and the filesystem was trashed so badly from the crash (I remember: it was a PowerBook, so I don't know if that had anything to do with it) that it was a write-off.

One of the reasons I use multiple filesystems apply just as much to a laptop as to anywhere else: loss/damage compartmentalisation. If one of my filesystems decides to eat itself, odds are I can still get the others back.

Wherever I go, I tend to have a root filesystem, one for /usr, one for /var, one for /tmp and one for /home. If it's a server, I may have a separate one for /srv as well. I always use LVM, and with ext3 supporting online resizing these days (well online enlarging at least), it's not a big problem to leave some logical extents unallocated, and just grow whichever filesystem needs it as it needs it.

It's a new year, so why not a new hackergotchi I say?

Brandon and Robin came around on Thursday night, and where there's Brandon, there's his camera, so he got a decent enough mugshot to convert into a less crap hackergotchi (after I spent a few hours fighting with the GIMP today)

Sarah brought The Story of Stuff to my attention today. It's well worth 20 minutes of your time, irrespective of where you live.

...and there was a distinct feeling of deja vu. At least the procedure itself was nowhere near as long (under 2 hours).

On Thursday, Sarah had some day-surgery to have her sternal wires removed. The top one was causing her some discomfort because the skin there was the thinnest (whether that in itself was related to any of the previous incision complications remains uncertain).

The surgical team popped in to pre-op to autograph their work (seriously, they initialled her chest) before they started, and asked if she wanted just the top wire removed, or all of them. We consulted the Magic Eight Ball application on my phone, and it gave a resoundingly affirmative response, so she got them all removed.

Despite removing them all being a bit more surgically invasive, I think this is for the best. It means none of the other wires can cause any problems down the track requiring yet another trip to the operating room.

They also did some scar revision on the top part of the scar, where it was a bit stretched (from the previous complications), so incisionally speaking, she's had almost as much incision work done as the original heart surgery.

Ironically, this made the plastic surgery (laser treatment and steroid injections) she had late last year largely redundant.

She took the dressing off the incision this morning, and we had our first look at it. It certainly looks a lot better than before, so fingers crossed it won't get infected this time, and the overall long-term result will look better.

I received a SanDisk Sansa e260 (v2) for my birthday. It was one of those presents that acquired for myself on behalf of someone else because it worked out easier that way. I bought it for cheap from Woot!

I thought I'd use it to play podcasts while I'm at the gym. We've been listening to NPR for a while now, and there's lots of excellent programming, and it's all available in download for as well. Since I don't spend all that much time in the car, I'm not listening to much of it.

The first mission was to upgrade the firmware. Getting the player into MSC (instead of MTP) mode with the original firmware was a little tricky, but I got there in the end. Then I had to locate the firmware in a Linux-installable format. I think I ended up resorted to using Windows, but I later found the raw firmware image without needing an installer.

I'm using Rhythmbox at the moment to download the podcasts. I thought I'd try out its MTP support, just because it actually had it, but either Linux 2.6.26 has a problem with MTP, or the player is particularly flaky doing it with Linux, because I just seemed to get a pile of USB errors when connecting the device in this mode, so I'm sticking with MSC for now.

Oh, and I had to put a .is_audio_player file in the root of the device to make it show up in Rhythmbox. I later discovered that it worked most optimally if I put

audio_folders=MUSIC/
folder_depth=2

in the file.

I'm still trying to come up with an optimal way of managing the audio I want to listen to. It seems somewhat tedious to drag and drop all of the podcasts from Rhythmbox to the device. I kind of want some sort of plug and play auto-sync method. It seems I can't use a connection-triggered rsync, because some of the podcasts seem to get downloaded with non-FAT-filesystem-friendly filenames. Rhythmbox seems to take care of this by doing some sort of automagical renaming at transfer time. That said, not everything is showing up in the music list with sane names. There's a few things that have an unknown artist I think. That may be a deficiency in the ID3 tags of the MP3s themselves though...

What I really want some way of getting home, hooking up the player and just getting what's new, without expending too much effort (at the time of hooking up the player, anyway. I'm happy to expend some effort getting to that point)

The next weird thing is that the device wants to talk USB 1.1. I'm not sure what is at fault here, but I can, allegedly at least, make the device reconnect at USB 2.0 by removing and reloading the ehci-hcd module after connecting it.

Here we have the device initially attached:

apollock@icarus:~$ lsusb -t
Bus#  5
`-Dev#   1 Vendor 0x1d6b Product 0x0002
Bus#  4
`-Dev#   1 Vendor 0x1d6b Product 0x0001
Bus#  3
`-Dev#   1 Vendor 0x1d6b Product 0x0001
  `-Dev#   9 Vendor 0x0781 Product 0x7423
Bus#  2
`-Dev#   1 Vendor 0x1d6b Product 0x0001
  `-Dev#   6 Vendor 0x413c Product 0x8103
Bus#  1
`-Dev#   1 Vendor 0x1d6b Product 0x0001

lsusb says that bus #3 is ID 1d6b:0001 Linux Foundation 1.1 root hub

Then if I do a spot of presto-changeo...

apollock@icarus:~$ sudo modprobe -r ehci-hcd
apollock@icarus:~$ sudo modprobe ehci-hcd
apollock@icarus:~$ lsusb -t
Bus#  5
`-Dev#   1 Vendor 0x1d6b Product 0x0002
  `-Dev#   3 Vendor 0x0781 Product 0x7423
Bus#  4
`-Dev#   1 Vendor 0x1d6b Product 0x0001
Bus#  3
`-Dev#   1 Vendor 0x1d6b Product 0x0001
Bus#  2
`-Dev#   1 Vendor 0x1d6b Product 0x0001
  `-Dev#   7 Vendor 0x413c Product 0x8103
Bus#  1
`-Dev#   1 Vendor 0x1d6b Product 0x0001

Bam! It's moved over to bus #5, which lsusb says is 1d6b:0002 Linux Foundation 2.0 root hub

Weird.

I wonder if I should try running Rockbox on it? Seems not, it's only for v1 players. Oh well.

(or echo "blosxom hold" | sudo dpkg --set-selections)

A few people had pointed out to me that my blog was appearing weirdly in Google Reader. I myself read my blog via Planet Debian and Planet Linux Australia, where it appears fine, so I hadn't noticed the problem first hand.

I did some digging tonight with the Feed Validator, and I think I've figured it out.

Funnily enough, it all started with a previous session with the Feed Validator...

I wanted my blog to be UTF-8, with it being the new hotness and all. Blosxom was spitting it out as ISO-8859-1. I've just learned from this evening's debugging, that this is the behaviour of CGI.pm's header() function if not provided with the -charset parameter.

I'd previously worked around this by defining my own content_type for the RSS and HTML flavours. In this file, I just put text/xml; charset=utf-8and text/html; charset=utf-8, respectively.

Unfortunately, this then breaks Blosxom's internal HTML-escaping-for-RSS-feed code, which is conditional on the content type being XML:

if ($content_type =~ m{\Wxml$}) {
        # Escape <, >, and &amp;, and to produce valid RSS
        my %escape = ('<'=>'&lt;', '>'=>'&gt;', '&'=&gt;'&', '"'=>'&quot;');  
        my $escape_re  = join '|' => keys %escape;
        $title =~ s/($escape_re)/$escape{$1}/g;
        $body =~ s/($escape_re)/$escape{$1}/g;
      }

This block of code was being ignored because the regex was anchored. "text/xml; charset=utf-8" didn't match "\Wxml$". Whenever I last had an attempt to make my blog's feed pass the Feed Validator, I must have edited the Blosxom source code to make this regex not be anchored.

Then on November 11, 2008, I updated my Blosxom package to 2.0-14+etch1, to address CVE-2008-2236 (incidentally, there doesn't appear to be a Debian Security Advisory for this?), and my local modification got clobbered. That'll teach me to make local modifications and not put the package on hold. Blah.

It seems I'm screwed, there's no way to have a well-formed UTF-8 RSS feed without requiring a source-code modification to Blosxom. I've either got to change the way the header() function is being called, or I've got to change the regex to allow me to specify a charset in the flavour file, and not disable HTML escaping.

Speaking of screwed, Blosxom seems incapable of making a well-formed RSS 0.91 feed anyway. It wants to put the <pubDate> tag inside an <item>, which is a violation of the DTD. There's supposed to be one for the whole <channel>, not one per item (or "story" in Blosxom-flavour-speak). You can't just move that from the story flavour file to the head flavour file, because a pile of variables that you'd otherwise use seem to only get set on a per-story basis. Double blah.

I'm starting to feel like Blosxom is outliving its usefulness, but I really do not feel like embarking on a wholesale move to a new blogging platform, I'm fairly entrenched.

(this is something I've had "in production" for many months now, I just haven't had the time or energy to do a proper write up about what I did)

We have a cat water bowl, it looks like this:

Under "normal" circumstances, it usually lasts about seven days. So when our weekly routine is happening, we'll refill it on a Saturday whilst doing house chores, and it'll last until the following Saturday when it gets refilled.

Unfortunately, sometimes our routine gets disrupted, and we forget. Sometimes, we travel and have a house-sitter, who may not pay as close attention to such things as ourselves.

Once, one of our cats was licking the condensation off a chilled bottle of soft drink that was on the kitchen counter one evening, before we realised the water bowl needed refilling. Naturally, we felt like terrible pet owners.

So I think it was some time around the 2008 Maker Faire, that I hatched the idea of having some sort of water sensor on the cat bowl, which would communicate to one of the various computers in house. At the Maker Faire, I bought a copy of Making things talk, and an Arduino starter kit, which consisted of a Diecimila board and a make-it-yourself proto shield. I also bought a little electronics starter kit, which consisted of a breadboard and various components, and a USB-TTL cable.

I decided to use Bluetooth to communicate with the board, as I already had my MythTV setup using a Bluetooth keyboard and mouse, and it was within range of the water bowl. I decided against using Zigbee, because I didn't know anything about it, and I didn't want to add (or learn about) yet another wireless infrastructure just for this project.

I should point out that I know very little about electronics. I'd never owned (or really used) a soldering iron until I embarked on this project. I took a basic soldering class at the Tech Shop, but I'd already assembled the proto shield by the time I took the class, so I'd pretty much figured it out.

I had a very naive vision that I could just basically shove two wires in some water and it'd close a circuit and that would be my water sensor. Of course this didn't work, so I started hunting around on the Internet for a circuit that would do this. I happened upon a circuit (I don't seem to have retained the URL, so I can't link to it), which just consisted of a couple of transistors and some resistors. So I headed off to Fry's to try and buy the transistors I needed.

I quickly discovered that I didn't have sufficient information to identify the transistors that I wanted, but I did happen to stumble upon a cheap assemble-it-yourself water alarm. It consisted of a PCB, and a transistor and some resistors and a buzzer. I bought a couple of these instead.

Between studying the PCB and the circuit diagram that came with the alarm, I was able to reproduce it on my breadboard instead of on the PCB. Sure enough, placing the two probes in water closed the circuit. I replaced the buzzer with an LED so I could see what was going on.

I attached the circuit to the Arduino proto shield, and had it feed into one of the digital I/O ports. I wrote some quick and dirty Wiring code so that when water not present (i.e. the circuit was open and no current was detected on that I/O port) the LED was switched on. Really at this point, I didn't need a microcontroller, I could have presumably achieved the same thing with a NOT gate.

At this point, I wanted to make the sensor remotely queryable. I bought a BlueSMiRF Silver Bluetooth modem, which I attached to the TX and RX lines of the board (I first configured it by attaching the USB-TTL cable to it and using Minicom on my laptop). I extended the Wiring code to provide a rudimentary prompt, and accept a command to check if water was present.

I think around this time it also dawned on me that I could use the digital I/O pins as a switch. When they're "high" they provide power. So rather than constantly running a current through the water, I only needed to briefly power up the water detection circuit, see if the circuit closed or not, and then report if water was present if it did.

I much preferred this, as at the time, I was endeavouring to power the whole sensor off a 9 volt battery. I figured I'd get much better battery life if I wasn't running a current through the water the entire time. I should point out that I did some "tongue tests" in a glass of water while the circuit was powered up, and couldn't detect a difference between when the circuit was on or off. The last thing I wanted to be doing was zapping the cats!

At this point, the Wiring and Arduino work was pretty much complete. I setup ser2net on the MythTV server, so that I could just connect to port 4000, and be connected to the water sensor.

apollock@icarus:~$ telnet teevee 4000
Trying 172.16.0.9...
Connected to teevee.andrew.net.au.
Escape character is '^]'.

ser2net port 4000 device /dev/rfcomm0 [9600 N81] (Debian GNU/Linux)


waterbowl> s
Water is present
waterbowl>
telnet> q
Connection closed.
apollock@icarus:~$

The Wiring code running on the Arduino board is checked in here.

Next, I wanted to monitor this with Nagios. One thing I found with the Bluetooth connection was that it wasn't all that reliable. Not every connection to port 4000 resulted in a connection with the water sensor. I elected to write some standalone code that submitted results to Nagios by way of a passive check, rather than having Nagios try to actively monitor it. Again, trying to conserve energy, I decided to only check the sensor once every 8 hours.

So I wrote a Python daemon, which tried to be as robust as possible. If at first it doesn't make a connection on its 8 hourly schedule, it keeps trying until it does. Nagios itself has some freshness detection for this monitor, so if no passive result is submitted within 8 hours and one minute, Nagios alerts that something is possibly wrong with the sensor itself. (The original intent was to deal with the situation where the battery went flat)

This is the Nagios service definition I've got. Some of it may be unnecessary or redundant:

define service {
        host_name                       teevee
        service_description             Cat water bowl
        check_command                   check_stale!2!"Check water bowl monitor is on and reachable"
        normal_check_interval           480
        notification_interval           240
        active_checks_enabled           0
        check_freshness                 1
        freshness_threshold             28860
        max_check_attempts              1
        check_period                    24x7
        use                             generic-service
        stalking_options                o,w,c
        contact_groups                  everyone
}

The code for the Python daemon is checked in here.

So everything was going swimmingly, apart from I couldn't get even 24 hours of monitoring on my conservative 3 times a day schedule, and the Bluetooth modem configured for all of its power saving options, and the water sensor itself only being powered on when it was performing a check. There wasn't much more I could do to try and reduce power consumption, at least with my limited electronics knowledge. Perhaps using Zigbee instead of Bluetooth would have helped, but I still think I'd have been going through 9 volt batteries more quickly than I'd have liked.

I also had a brief foray into solar powering the board. I thought maybe the lighting in the house would be sufficient to power the board. Of course this didn't work out. I'd also have needed to make the code running on the board more self-sufficient, and have it just provide a water status indication whenever it had enough power to do so, instead of being a fairly dumb device like it currently is. This all felt a whole level more complicated, and out of my league, and I wasn't interested in attempting this sort of remote-sensing exercise at this time.

The Arduino board can also be powered by USB, so as I already had some long USB type A to type B cables (that had funky lights in them to boot), I decided to just get a wall wart that had a USB type A receptacle, and powered the Arduino board that way. So much for being completely "wireless". (I could have also gotten a general purpose DC power supply that was capable of spitting out 9 volts, but I doubted I'd get one with a sufficiently long cable, which is why I went for the USB-powered option, as I already had a cable long enough)

Speaking of wires, the most challenging part was the probes for the water sensor. As they were going to be permanently in the cats' drinking water, I didn't want to contaminate the water with them. I figured plain untinned copper wire would be okay, since water pipes are copper. Finding untinned, unstranded copper wire was a real challenge. I started out using some FM antenna cable, but that was stranded, and the shielding was a nightmare to strip. It was also reasonably difficult to make go where I wanted it.

What I really wanted was something more solid, that would flex and stay where I put it. I cannibalised a spare IEC power cable, but it was also stranded copper wire. I finally managed to obtain some solid-core CAT-5 cable from a hardware store, and this has worked exactly as I wanted.

I haven't done any further work on the setup since getting the CAT-5 cable for the probe. Further improvements that I'd like to do at some point:

• transfer the circuitry from the breadboard to a breadboardless proto shield, and generally try to house the sensor better
• find a better way of connecting the probe wires to the circuit, so it's easier to remove the monitor when refilling the water tank (currently the CAT-5 wires are just shoved into the breadboard). The whole thing is barely spouse-approved as it currently is, let alone being easy enough for an untrained house-sitter to try and negotiate
• integrate with Asterisk so a house-sitter gets a telephone call when the water bowl needs refilling

I had a lot of fun with this project. I had a real sense of achievement, being able to go from concept to completion, and learn a few things about electronics along the way. I'm normally not a fan of messing around with hardware.

Some photos of the project are here.

This is pretty cool.

I think the craziest dependency map for a package I maintain is the one for argus-server.

(Discovered via LWN)

OMG OMG OMG!!!

I just discovered the connect-a-desk

I had a crazy idea for something exactly like this a couple of years ago, when I was in Las Vegas for Christmas, in a line for a buffet on Christmas Day, and on call. I was trying to juggle a laptop and deal with something I'd been paged about whilst still standing in line.

I'm so buying one. I could work on a treadmill!

I bought these USB powered lights from Woot! recently, with grand plans of using them with a continuous build/test/install rig to provide visual notification of when a build/test/install completed or failed or something.

Somewhat to be expected for the price, they merely draw power from the USB port, and have a physical switch on each light. I want something software controlled though.

There's something in /sys/bus/usb/devices/*/power/level that looked promising, but seems to be a red-herring (at least for non-devices. I was able to turn off a USB mouse and a Bluetooth adapter this way)

What I'd like (and it probably exists, I just have to find it), is a USB device that presents itself to the operating system, and its sole purpose is providing pass-through power to a USB A-type receptacle on itself. This would then be manageable by the operating system.

What I'm possibly trying to say here is a small, specialised, one port USB hub. Hmm... I'll have to see if I can borrow a USB hub from someone to test this theory. I've never had a need to own one.