Emacs Light Switches

Tellstick Duo

Telldus launched a new version of their nifty USB-based “home automation” thingy a couple of months ago.  It’s mostly the same as the last version, but this one can receive signals as well as send signals.

This means that you can buy stuff like this switch, glue it onto a wall somewhere, and control your lights more like a normal person.  Instead of having to use computer-ey interface.  Like an animal!

It works pretty well.  As before, the USB interface exposes a serial interface. To get it working under Linux, you need to tell it about the serial numbers, because this devices is brand new:

[larsi@quimbies ~]$ cat /etc/modprobe.d/tellstick.conf
options ftdi_sio vendor=0x1781 product=0x0c31

After doing that, the device shows up as /dev/ttyUSB0, and if it receives something, it spits out data like

Wireless Wall Switch Sticky-Taped On To The Wall

+Wprotocol:arctech;model:codeswitch;data:0xE47;

So you basically just stick lots of switches on the wall, and then create rules to respond to these strings.

I’ve updated the Emacs code.

It seems to work pretty well.  There range is OK — it kinda goes through one wall, and kinda works over 7 meters.  But it’s not 100%, which is annoying.  I’ve bought two devices, so far, to get coverage over the flat, but I think I might need one more.

Anything that’s wireless sucks, but being able to just glue switches anywhere is pretty awesome.

Oh, Brando

I bought some USB3->SATA adapters from Brando.  They came with US->Euro plug adapters.  (Yes, the adapters had adapters with adapters.  Geez.)

See if you can spot the problem.

In addition, the speed I get when ripping CDs via these adapters is, as they say, teh sux.

Oh, well.  It’s not as if I actually expected something bought from Brando to work, but it was worth a shot.

The Curious Case of the Box Fan

I bought an ESATA box to replace the crappy Synology RAID thing. It’s a very simple external enclosure with no brains whatsoever, so I can just string four ESATA cables out of the computer in the cupboard to the enclosure, and run standard Linux soft raid.

I installed four 5900RPM Seagate Green disks into the box, which has the snappy name “RaidSonic Stardom ST5610-4S-S2”.

It seems to be working fine.  It’s much snappier than the Synology box, especially when traversing large directories and displaying small pictures, which is something that my music browser does a lot.

But the design of the cooling system is rather odd.

A Box!

There’s a nice and big fan at the back. But it’s rather noisy, so I unscrewed the back cover and removed the fan to see what was going on.  It turns out that the fan blows straight onto that red backplane there.  There are three holes in the backplane, but they are completely covered up by the disks on the other side of the backplane.

It’s rather puzzling.  As far as I can tell, there’s virtually no cooling of the disks themselves with this “design”.  I could detect no draft from the front while the fan was working like crazy at the back.

Oh well.  I guess that this means that the fan is non-functional, so I just unplugged it.  That means that the box is quite silent, which is nice.  And that the disks will die a lot sooner, which isn’t.

All hardware sucks.

More Input Devices

Targus Wireless Presenter and Emacs Volume Control

Finding wireless input devices (for controlling the stereo) that are

1) not too ugly and
2) works reliably and
3) has a range over a few meters

isn’t trivial.  I’ve experimented with a few thingamabobs, and one device I’m pretty satisfied with is the Targus …  er…  I can’t find any model name here.  AMP02EU?  Anyway, it’s a “wireless presenter” (with a laser pointer, so I could entertain a cat if I had a cat, but I don’t *sob*), so, of course, it isn’t really geared towards music playing.  But since, these days, all input devices show up as input devices in Linux, you can use it for whatever you want, with a bit of configuration.

The first thing to do is to put the following in /etc/udev/rules.d/90-itron.rules. It has to be “late” in the udev chain so that other rules don’t overwrite the name we want.

KERNEL==”event*”, BUS==”usb”, SYSFS{idVendor}==”195d”, SYSFS{idProduct}==”7777″, MODE=”0666″, NAME=”input/itron%n”

I chose the name “itron” since that’s what lsusb claims that this device is:

rocket-sam:/etc# lsusb
Bus 002 Device 018: ID 195d:7777 Itron Technology iONE Scorpius wireless keyboard

Now that we know where the device will show up (i.e., /dev/input/itron*), we can route events to the commands we want to execute.  I googled around for a while before deciding to use evrouter, which gives us pretty simple access to all events.

“Itron Powerful Receiver” “” any rel/1/1  “Shell/emacsclient –server-file=rocket-sam –eval ‘(jukebox-decrease-volume)'”
“Itron Powerful Receiver” “” any rel/1/-1  “Shell/emacsclient –server-file=rocket-sam –eval ‘(jukebox-increase-volume)'”
“Itron Powerful Receiver” “” any key/272  “Shell/emacsclient –server-file=rocket-sam –eval ‘(jukebox-pause)'”
“Itron Powerful Receiver” “” any key/104  “Shell/lights 0”
“Itron Powerful Receiver” “” any key/109  “Shell/lights 1”

The first string is the name of the device (yes, that’s what it calls itself.  How masterful).  “rel” is the mouse.  “key” is, er, a key.

So this decreases volume when the mouse goes down, increases when the mouse goes up, pauses the music when I press the big button down, and switches the lights in the room off/on on two of the other buttons.

Which still leaves me with more unused buttons, but I haven’t found a use for them yet.

Then start the event routing in a startup script like so:

$ rm -f /tmp/.evrouter\:0.0
$ /usr/local/src/evrouter-0.4/src/evrouter -f /dev/input/itron*

(The first “rm” is needed because evrouter doesn’t seem to clean up after itself always…)

The only minor problem I now have is that although evrouter picks up the events, they still get passed on to X.  So when I increase the volume, the mouse cursor goes upwards.  I haven’t bothered trying to investigate how to make X ignore certain input units, but if anyone has a pointer to a conf example, please leave a note in the comments.

Digital Audio Extraction from Emacs

Triple Threat
SATA Multilane Connector

So my CD ripping situation is that I put a CD into the CD reading thing there (more about that in a thrilling later blog article), hit a key in Emacs, slap a CD cover onto the scanner, hit another key in Emacs to say that the format is (usually RET), and then inspect the CDDB data that Emacs presents me with, and then I `C-c C-c’, and then I repeat. Since I have three CD players, I can do three CDs in parallel.  The time to process one CD is about two minutes, but with the parallelism going on, I can usually process about twenty CDs in ten minutes.  (Unless the CDDB info is missing and I have to type stuff in.)

I started on this journey in 1997, when mp3s first became viable.  So over the years, I’ve ripped CDs as I bought them.  The earliest mp3-encoded albums started sounding pretty crappy to me, since the early mp3 encoders were pretty crappy.  By 2007, disks had gotten so cheap that it was viable to store the music in a lossless format, so I decided to re-rip them all and store the music in flac.

Now, I have around 4K CDs.  Ripping them all in the traditional, sequential way would just take too long.  I don’t really deal well with repetetive, boring, manual tasks.  And since I had ripped all these CDs before, all the data was already in freedb, so it would be a totally mindless manual job.

So I bought the Addonics cabinet seen above, which has a SATA multilane connector, and put three DVD readers into it.  The only problem in getting it to work reliably was that since all the readers were identical (I mean totally), and the SATA cabinet would bring them up in random order, the poor Linux udev system would name them /dev/scdX at random.  So I would never know how to address the top one until after trying 0, 1, 2.

Until I came up with the brilliant idea of uploading different versions of the available Optiarc firmware on each DVD reader.  They worked just as well with any firmware, but the firmware versions allowed me to create udev rules to differentiate.

scsi 7:0:0:0: CD-ROM            Optiarc  DVD RW AD-7170S  1.02 PQ: 0 ANSI: 5
scsi 5:0:0:0: CD-ROM            Optiarc  DVD RW AD-7170S  1.00 PQ: 0 ANSI: 5
scsi 6:0:0:0: CD-ROM            Optiarc  DVD RW AD-7170S  1.03 PQ: 0 ANSI: 5

With the 3-way parallel ripping setup I think I did all 4K over four nights, if I remember correctly.  While listening to music very loudly, and watching some tv series on DVD (Smallville?), and being totally shit-faced drunk.

Ah, fun times.  At least I think it was fun.  I can’t really remember, for some reason or other.

Anyway, here’s the source code for the Emacs parallel DAE interface.

Useful Consumer Review

I got a new phone today.  The Nokia E7.  And look!  It’s perfect!  It runs Gnus under ssh! Look how pretty Gnus is on the phone!

(The only thing that would have been perfecter would be if it actually ran Emacs on the phone itself, but I guess that’ll have to wait until somebody produces a useful Meego phone.)

I think I’ve got the appliance review thing down now.  This blog will be the next Engadget.

Sennheiser HDR 180

Headphones cradled on the charging cradle

Most hardware seems to have been created in a “will this do?” mind set.  They have a bit of technology, and they have some economic restraints, and then they rush it to market.  It makes perfect sense, and I can’t envision that it’ll ever change, but it’s somewhat depressing.

The hardware in question this week are the Sennheiser HDR 180 wireless headphones.  They use Klear wireless technology, and they sound really good.  There are no drop-outs, there is no buzzing — they just work, even if I walk to the far side of the apartment.  They’re, technically speaking, what you would call “ace”.

Cradle on/off button

But then there’s the User Experience details.

The headphones usually rest on the charger thingie you see up there.  It’s nice.  So when I start watching something on the “TV” and I want to use the headphones, I pick up the headphones and put them on my head?

Nope.

I pick up the headphones.  Then I hit the “on” button on the base station.  Then I hit the “on” button on the headphones themselves.  Then I put them on my head.

Headphone UX

Because, I mean, why would you assume that just because I’m picking them off the charging station, I want to use them?  Perhaps I want to do something completely different.  Perhaps I picked them off the charging station to hang them out to dry on the balcony?  Or perhaps I wanted to dance around with them, fondling them inappropriately?  I mean, that’s so much more likely than wanting to use them.

This is why I hate all hardware.  Hardware never works the way it should.

And I didn’t even want to go into the UX of the headphones themselves.  You see those five buttons on the headphones?  Yes, there’s volume up, on/off, and volume down buttons.  Fine.  But then, next to them, there’s two balance buttons.  So when I have the headphones on my head, which is usually where they are when I’m using them, I have to feel around, tentatively, for the volume buttons, because once you hit the balance buttons, you’ll never get the right balance back again.  There’s no “return the balance to the, er, balanced position” button. It’s like FAIL!!!1! And who the fuck wants to change the balance, anyway?

Oh, by Emacs.  I hate hardware.