I scheduled it to run once a day at midnight:

0 0 * * * sleep 30;php te923Status.php <notify email address>

The 30 second sleep is intended to offset the status check from the normal weather data check that happens exactly on the minute.

Debian out of the box doesn’t relay mail to external domains, so I had to do another tweak here. To enable forwarding, I reconfigured exim according to http://pkg-exim4.alioth.debian.org/README/README.Debian.etch.html.

It’s not really the proper way to create a real relay server, but since I’m behind a firewall and only using the server for this purpose, I didn’t feel it necessary to do more. But the email does look suspicious to the receiving mail system, so if you send to an address outside your domain (like gmail, for example), the mail is likely to be determined as spam. You’ll need to create whatever filters necessary at the recipient account to avoid this.

And that’s it so far. I expect I’ll delve into RRDTool and RRDWeather now to see if I can create graphs of readings Weather Underground does not (like humidity, for example).

@@ -138,7 +138,7 @@
     }

     else {
-        data->uv = bcd2int( buf[18] & 0x0F ) / 10.0 +
               bcd2int( buf[18] & 0xF0 ) +
               bcd2int( buf[19] & 0x0F ) * 10.0;
+        data->uv = bcd2int( buf[18] & 0x0F ) / 10.0 +
               bcd2int( ( buf[18] & 0xF0 ) >> 4 ) +
               bcd2int( buf[19] & 0x0F ) * 10.0;
         data->_uv = 0;
     }

The next thing to address is the permissions problem. To this point, the only way to get data from the station was to be root. Otherwise, you get this error:

[mcp:…/te923/te923] te923con -D
Error while setting configuration (-1).

This is a generic issue with USB devices, and I found an item on a wiki (http://wiki.openstreetmap.org/wiki/USB_Garmin_on_GNU/Linux#Fixing_Device_Permissions) about GPS units that got me going.

That page discusses how to set the group ownership on the device, as well as the permissions on the device. Long story short, I created the device rule set /etc/udev/rules.d/99-te923.rules (all on one line):

ATTRS{idVendor}=="1130", ATTRS{idProduct}=="6801",
                    MODE="0660", GROUP="plugdev"

idVendor and idProduct identify the TE923 weather station, mode tells the USB driver to give read/write permissions to the user and group that owns the device, and group tells the driver to assign group ownership to “plugdev”. My user on the machine is a member of that group so I should be OK.

Ask the system to reload the USB rulesets:

[mcp:.../te923/te923] sudo udevadm control --reload_rules

And now I can get valid data back from the unit without being root:

[mcp:.../cwanek/cronjobs] te923con
1273414489::::59:::::::::1003.1:5.0:3:0:9:0.4:0.0:11.7:215

Unfortunately, though, some readings (specifically current temp readings) are empty. Even wide-open permissions on the device don’t help. This doesn’t make sense to me, and I have not yet solved this issue, so I’m still stuck with being root to run te923con. I’d love to know why it would work only partially.

Still, I don’t really want to have root’s crontab running the script, so I configured sudo to skip the password prompt for the group plugdev for the te928con application. With visudo, add:

%plugdev ALL=NOPASSWD: /usr/local/bin/te923con

Moving on, the I was still not able to run te923con without removing the USB human interface device module (sudo rmmod usbhid). While removing it allows access to the te923 station, it would also cause any other HID like a mouse or keyboard to stop functioning. So the trick is to get the usbhid module to release just the weather station.

There are many sites that document how to get usbhid to unbind a device. I found http://lwn.net/Articles/143397/, which give me the following command:

sudo bash -c "echo -n 2-1:1.0 > /sys/bus/usb/drivers/usbhid/unbind"

bash -c is required so the shell redirection to unbind will succeed.

Digging deeper, I learned (http://reactivated.net/writing_udev_rules.html) that you can configure the unbind to happen immediately after the device is connected, by using the “RUN=” option in the device rules file (this is all on one line in /etc/udev/rules.d/99-te923.rules):

ATTRS{idVendor}=="1130", ATTRS{idProduct}=="6801",
    MODE="0660", GROUP="plugdev",
    RUN="/bin/sh -c 'echo -n $id:1.0 > /sys/bus/usb/drivers/usbhid/unbind'"

So now, apart from the missing data when running as a non-privileged user, the te923 weather station is coexisting with other USB devices, and I am able to schedule the upload script in my own user crontab.

There’s one last thing…

Sure, there are packages like RRD Weather that can do this too, but where’s the fun in that.

The te923con application returns most of the data included in the wunderground protocol directly, so it’s a simple matter of parsing it from the application output. Weather Underground wants imperial units, but maybe someday I’ll want proper metric units, so I made it a parse option.

The weather station apparently does not return a calculated dew point, which is part of the upload protocol. It turns out that calculating dew point is not straighforward. But many people have implemented calculators. A guy named Wolfgang Kühn implemented one in javascript that seemed very thorough, so I did a quick port of it to PHP.

The weather station also returns only the accumulated rainfall total since the station was started, so I implemented a simple array mechanism to retain historical data from the rain counter. I can then calculate the “rain in last hour” and “rain since midnight” values required by the WUnderground protocol.

From there, it’s a simple matter to build the URL string for data upload, and a file_get_contents call to upload and get the success or failure result.

I save the rain counters and the other weather data as PHP code in a cache file that is reloaded with a PHP include the next time the script runs.

WUnderground can accept data as fast as once a second, but the weather station does not update from its sensors with anywhere near that frequency, so I felt scheduling upload once a minute via cron was more than often enough. The script takes station id, password and cache file name on the command line (all on one line):

* * * * * php te923WunderUpload.php <station ID>
                       <wunderground password> <cache file name>

Because of the permissions issues with the USB device, for now this is scheduled in the root user’s crontab.

Now on to fixing the bugs…

The problem with this station, though, is that it’s a USB station, and Linux is not supported by the software that ships with it. But I figured I could find a way around that, and indeed I could, but it wasn’t so straightforward. Along the way I learned some arcane details about USB on Debian Linux. This series of posts is something of a blow-by-blow of the process.

The hardest part was already done for me by Sebastian John who created an application that reads the current raw data from the station. The source is available at http://te923.fukz.org/index. Building the source requires libusb, and the site links to it, but I was able to build with the vanilla libusb-dev installed by apt-get:

apt-get install libusb-dev

The build creates the executable te923con, which I then installed in /usr/local/bin.

The first time I tried to run it, I got the following error message:

[mcp:…/te923/te923] te923con -D
Error while setting configuration (-1).

This indicates insufficient privileges to access the USB device, so to get things going I ran the te923con application as root. That got me to the next error:

[mcp:.../te923/te923] sudo ./te923con -D
Error while setting configuration (-16).

The dmesg shows the following error (all on one line):

[24464516.452385] usb 2-1: usbfs: interface 0 claimed
                    by usbhid while 'te923con' sets config #1

It seems that the TE923 registers itself as a human interface device (HID) for some reason, so the OS tries to treat it a such. The author of a package of code that creates a web view for the TE923 has the solution on his blog, though without explanation of the problem or why: http://firewall.haringstad.com/TE923-Frontend/blog/TE923-Frontend-Info/TE923-Frontend%20Blog/B9EF42CC-F942-41DE-ABDF-461549FEFB46.html

He removes the usbhid kernel module:

sudo rmmod usbhid

And success:

[mcp:.../te923/te923] sudo ./te923con -D
[DEBUG] got |07|00|0a|0a|00|0a|0a|00|
[DEBUG] got |07|0a|0a|00|0a|30|00|af|
[DEBUG] got |07|3d|03|57|c0|28|00|35|
[DEBUG] got |05|00|0a|b2|00|66|00|35|
[DEBUG] got |01|5a|0a|b2|00|66|00|35|
[DEBUG] got |02|28|82|b2|00|66|00|35|
[DEBUG] got |07|37|64|c0|96|0a|00|0a|
[DEBUG] got |07|0a|00|0a|0a|00|0a|0a|
[DEBUG] got |07|00|0a|30|00|af|3d|03|
[DEBUG] got |07|57|c0|28|00|35|00|0a|
[DEBUG] got |03|b2|00|66|00|35|00|0a|
[DEBUG] TMP 0 BUF[00]=28 BUF[01]=82 BUF[02]=37
[DEBUG] TMP 1 BUF[03]=64 BUF[04]=c0 BUF[05]=96
[DEBUG] TMP 2 BUF[06]=0a BUF[07]=00 BUF[08]=0a
[DEBUG] TMP 3 BUF[09]=0a BUF[10]=00 BUF[11]=0a
[DEBUG] TMP 4 BUF[12]=0a BUF[13]=00 BUF[14]=0a
[DEBUG] TMP 5 BUF[15]=0a BUF[16]=00 BUF[17]=0a
[DEBUG] UVX   BUF[18]=30 BUF[19]=00
[DEBUG] PRESS BUF[20]=af BUF[21]=3d
[DEBUG] STAT  BUF[22]=03
[DEBUG] WCHIL BUF[23]=57 BUF[24]=c0
[DEBUG] WGUST BUF[25]=28 BUF[26]=00
[DEBUG] WSPEE BUF[27]=35 BUF[28]=00
[DEBUG] WDIR  BUF[29]=0a
[DEBUG] RAINC BUF[29]=00 BUF[30]=b2 BUF[31]=00
1272059734:22.80:37:6.40:96:::::::::986.9:3.0:3:0:10:1.6:1.3:5.7:178

Hooray! There are still a few problems to work out with the device interface, and there is a bug in the te923con application to fix, but now I have a working interface to my weather station. Next up, getting the weather data onto Weather Underground

Access was all that I had access (heh) to, and it had a “music collection” database template, so with slight modification to the template that’s what I used.

Well now, I no longer have access (heh) to Access, Access is a PITA, and I already have MySQL available on my home server, so I figured it was time to finally migrate.

I found a handy application called Navicat (fully functional trial), that will import directly from the Access .MDB file to a MySQL database.

While Navicat mostly worked, I was not quite done. The import did not properly get the auto_increment attribute on the tables’ ‘id’ column. Also, the Access database tables had spaces in their names which is kind of a drag. Fortunately both were easily solved by exporting from MySQL to text using mysqldump, editing the .sql file that resulted, and then reimporting to MySQL from the .sql file.

Sure it’s a ridiculous thing nobody in their right mind will ever have to do, but I’m not in my right mind.

My new Pike’s steerer tube has a cap in the bottom with a threaded hole the same size as a standard headset bolt (M6). Instead of pounding a star nut into the steerer, it’s exteremely easy use this cap as the bottom of a headset locker like the Azonic Headlock or USE Safe-T.

Required parts (in addition to headset, stem, spacers, etc.):
M6 threaded rod (shortest I could buy was 3 feet)
M6 coupler nut
Total cost about $5.

Insert the rod to measure the correct length. I threaded the rod through the bottom of the steerer tube until half an inch or so was protruding out the top of the tube. This took some time to thread the 10″ of rod through; I could have done an initial cut to an estimation of length to save myself some time, I suppose.

Add coupler nut, headset cap and original stem bolt. Thread the nut on the rod first, headset cap on original stem bolt, and then stem bolt into the coupler nut as well.

Tighten down the headset cap so there is no play or extra space in the steerer stack. Mark the point where the rod emerges from the bottom of the steerer tube. Take it all apart again, and cut the rod at the mark with a hacksaw.

Put it all together with the headset cap back on original bolt, coupler to original bolt, then threaded rod into coupler. You may want to use some removable threadlocker on the coupler to make it behave more like a single bolt when it’s in the steerer. Tighten the original stem bolt tightly into the coupler; it’ll butt up against the threaded rod.

Drop the whole thing into the steerer tube, thread it into the bottom cap, then tighten the bolt to the torque specs of your headset.

Naturally I had to see if it really was trivial, which in fact it turned out to be. @mrbalkytivo is busier than I am.

Put tweetTivo.php someplace to be called by cron.

class_tivo_xml.php is not written by me and is required. Google it up. Figuring out how to get the XML info from the TiVo is left as an exercise for the reader.

The script will tweet about any new recording that starts, including TiVo suggestions, which are not always reflective of my taste, but then again, neither are many of MrsBalky’s choices. I thought about enhancing the script to skip suggestions, but grew bored and drifted away.

TwitPic has an API, so I rolled my own simple uploader with cygwin and curl. There’s no doubt in my mind that I’ve reinvented the wheel here…

Standard disclaimer applies: this is quick n’ dirty(tm):

#!/bin/bash

# curl executable.  I'm a PC.
CURL=C:/cygwin/bin/curl

# The upload script that will accept the data
UPLOAD_URL=http://twitpic.com/api/uploadAndPost

# Snag stuff off the command line
TWITTER_USER=$1
TWITTER_PW=$2
PHOTO=`cygpath -m "$3"`
TWEET_MSG=$4

# Prompt for message if it's not given
if [ "$TWEET_MSG" = "" ]; then
   read -p "Tweet msg: " TWEET_MSG
fi

# Go
echo Uploading...
$CURL \
  --form username=$TWITTER_USER \
  --form password=$TWITTER_PW \
  --form media=@"$PHOTO" \
  --form message="$TWEET_MSG" $UPLOAD_URL

# Wait for user to read result message
echo
read -p "Press <enter> to continue" bogus

Create a desktop shortcut with uid and password:

C:\cygwin\bin\sh.exe ~/twitpic.sh --userid-- --password--

Now just drag and drop the photo onto the desktop shortcut.

Check out all that unused grey space:

The last straw for me today was to discover that they put chat in the navigation bar, and it was impossible to turn off. I found a groups forum thread where I could actually register my discontent, and found this little gem:

http://www.google.com/ig?hl=all

Add that “?hl=all” to the end of the URL, and hooray! Tabs on top again!

Hack together openlink, perl, sonosweb and iphone sonos:

I had to go through Perl dependency hell (Perl really is an abomination) to get sonosweb working on the linkstation, but it works pretty well now.

Throw in a little DD-WRT and ssh and you can really mess with your S.O. by changing the music at home from the office.

Now I need to write up how I got through the seven circles of dependency hell before I forget. It took more than a quarter to Charon.

Rebooting the computer fixes it, but this happens with such regularity I’d be rebooting several times a day.

But I discovered that if you disable the USB port/device, and then enable it again, the problem is also fixed. Going through the device management dialogs is incredibly cumbersome, so I wrote a script.

fixusb.bat:

@echo off
echo "disabling usb device..."
devcon disable "@USB\VID_0424&PID_2504\5&18F4DAC0&0&5"
echo.
echo "enabling usb device..."
devcon enable "@USB\VID_0424&PID_2504\5&18F4DAC0&0&5"
echo.
pause

The @USB\VID_... bit is the USB device ID. To get the device ID, you’ll have to go to the Device Manager dialog. Figure out which device the iPod is attached to (I don’t remember exactly how I did this; sorry). Then on the “Details” tab of the device “Properties” dialog you can get the “Device Instance Id”.

I have to use this all the time, so put a shortcut to it on the desktop.

So most bike tires these days have presta valves, which are not nearly so easy to deal with as schraeder valves like those on cars. There are adapters that sort of convert presta to schraeder, but they’re kind of a cumbersome, and I wanted something more convenient. Surfing around, I found a tool that does it commercially available for $50.

But since I already have a blower tool, and I’m terminally cheap, I decided to try build one for less.

Voila:

And just screwing around a little, I turned it into an Instructable.

Of course, everyone is doing it.

Todd has been admiring it for his blog for some time, but the poor fellow only had Series 3 TiVos, which had networking features turned off so he couldn’t do the same. Now that TiVo has seen fit to turn that feature on in the S3s, I found I had to clean up the code so he could use it over on his blog.

As Todd says, sometimes you have to build things just because you can.

Along the way, I mentioned Steep & Cheap, which is basically like the woot of outdoor gear. They have single deal after single deal, about every 20 minutes or so, all day long. It’s fine for me because I work at a computer all day long and can see each deal as soon as it is posted. But Larry is not at a computer, though he does have access to one.

What Larry does have, though, is a pager with an email address. It got me to thinking, so I hacked together a little PHP code, mixed it gently with cygwin cron, to poll the SAC deal feed. If the deal changes, the application will send him a page.

So far, he’s not tired of the constant buzzing on his hip.

Here it is. Standard disclaimer applies: this is quick n’ dirty(tm):

<?
// Requires PEAR::Mail
require_once( 'Mail.php' );

$sac_rss = "http://www.steepandcheap.com/steepcheap/rss.xml";
$item_element = "ITEM";
$have_item = FALSE;
$in_item = FALSE;
$current_element = "";
$message = "";
$statusFile = "sacdeal.txt";

$to_list = array( "pager_email_address" );

$from = 'SAC Alert <sacalert@my.hosting.company>';
$subject = 'SAC deal alert';

$host = 'smtp.server.name';
$username = 'smtp.userid';
$password = 'smtp.password';

$to = "";
foreach( $to_list as $emailaddy )
{
  $to .= "$emailaddy, ";
}
echo "$to\n";

function startElement( $parser, $name, $attrs )
{
  global $current_element, $have_item, $in_item, $item_element;
  $current_element = $name;
  if ( $name == $item_element )
    $in_item = TRUE;
}

function endElement( $parser, $name )
{
  global $current_element, $have_item, $in_item, $item_element;
  $current_element = "";
  if ( $name == $item_element )
  {
    $in_item = FALSE;
    $have_item = TRUE;
  }
}

function elementData( $parser, $text )
{
  global $current_element, $have_item, $in_item, $message;
  if ( $in_item && !$have_item )
  {
    // the message content is only the title or the price
    if ( $current_element == "TITLE" || $current_element == "SAC:PRICE" )
      $message .= "$text\n";
  }
}

$xml_parser = xml_parser_create();
xml_set_element_handler( $xml_parser, "startElement", "endElement" );
xml_set_character_data_handler( $xml_parser, "elementData" );

// fetch the feed content and parse it
$xml = file_get_contents( $sac_rss );
xml_parse( $xml_parser, $xml );
xml_parser_free($xml_parser);

// compare the current item in the feed to the last one we sent email about
$oldcontents = file_get_contents( $statusFile );
if ( $oldcontents != $message )
{
  $headers = array( 'From' => $from,
                    'To' => $to,
                    'Subject' => $subject );

  $smtpParams = array( 'host' => $host,
                       'auth' => true,
                       'username' => $username,
                       'password' => $password );

  $smtp = Mail::factory( 'smtp', $smtpParams );

  $mail = $smtp->send( $to, $headers, $message );

  echo $message;
  if (PEAR::isError($mail))
  {
    echo( $mail->getMessage() . "\n" );
  }
  else
  {
    echo( "Message successfully sent!\n" );
    file_put_contents( $statusFile, $message );
  }
}
else
{
  echo "same deal as last time\n";
}
?>