Shortly after musync became practically usable, however, udoprog started hacking on it, and the current version is only loosely related to my old code (that was, for all I know, lost — for the better I believe). My current role in musync’s development is more or less reduced to finding bugs and hammering udo on IRC until he fixes them.

So, what musync does is it takes a number of music files (or folders if running in recursive mode) runs a specified command to add them to the file/folder structure according to a given rule, optionally filtering and/or replacing non-wanted characters in the process. The file-folder structure may for example be »artist/album/NN-title.ext«, and the add command could be simply copying the files.

But starting with recent musync versions, commands are Python lambda expressions, and can thus mean running several commands in sequence per file; I, for example, have my add command set to both copying the files to their calculated targets and then telling xmms2, my music player, to add them to its database. Here’s a code snippet for the relevant parts of musync.conf:

[site]
root:           "/var/storage/Musik"
xmms2_sync_lib: lambda file: m.execute("/usr/bin/nyxmms2", "server", "import", file)
add:            lambda src, dest: (sh.copy(src, dest), xmms2_sync_lib(dest))

To add newly ripped or downloaded music to my collection with musync, all I now need to do is running musync -c site add <files or directories>.

Other uses would include transferring music files (or directories) to a music player, optionally transcoding them to a format of choice in the process  (I keep my collection mostly in FLAC but transcode it to vorbis to save space when I put it on my DAP), maintaining multiple different directory structures of the same music files using (symbolic-) links or making a »shadow root« with sorted symbolic links to unsorted originals still left in the downloads/incoming directory.

Feel free to Flattr this post at flattr.com, if you like it.

I know my camera's horrible.

I spent New Year’s with my cousins (also known as The Swedish Shortsnouts), where I came in contact with a project of their father’s, a PIC-based temperature monitor/logger named Dobby. When I returned home, I felt rather inspired, and dug up my Arduino Duemilanove and a SHT15 sensor I bought earlier.

At this point, I’d like to mention I had some rather bad experiences with micro controllers (and don’t get me started on interrupts!) during my time at The RIOT, and I haven’t exactly been keen on hardware hacking since then. Low-level work never suited my short attention span. If I have to think about memory allocation or pin voltages I’m quickly loosing sight the big picture, and end up making luminous fish in stead. Or, to take an example from reality, researching the possibility of keeping pet jellyfish.

Fortunately, after a quick WWW search, I found both wiring shemes and a library for communication with the SHT15. The hard part turned out to be getting the code onto the Arduino, since the IDE is Java-based, and Swing is written by people who clearly know nothing about the X windowing system and since the command-line approach for code uploading is heavily based on a semi-official Makefile that was apparently dropped from the recent versions of the Arduino SDK because it didn’t really work and nobody bothered fixing it.

Thanks to wmname (Suckless to the rescue­­­ as usual!), recommended in a helpful dent, I got the official IDE working. It’s really nothing I’d like to spend much time in, but it works for loading code and communicating over the USB TTY, which was all I needed.

So now I’ve got some rather messy code to log temperatures from the Arduino and send them once every second to anything listening on the USB TTY. Which happens to be a small, also rather messy Python program that logs the temperature and humidity in a text file with a Unix time stamp. This file is then read by a second Python program, using mathplotlib. My error handling is horrible: I just let Python disregard any non-sane values (i.e. any where string->float conversion of the incoming data fails or where the values are clearly invalid), but it works. Rather well, I might add.

However, my goal is a much more stand-alone-ish logging device, so I’ve set up a project plan to try to keep my focus at least somewhat intact.

1. Try soldering the sensor, and connect it with network (RJ 45?) connectors. Make sure it’s working.
2. Add a RTC module and make sure it’s working. Have Winky time stamp its own messages, in stead of the PC doing it as it’s recieving them.
3. Implement an administrational interface for the USB serial console.
4. JSON-encode the data. Preferrably through some already existing library.
5. Fix persistent data storage somehow
   1. Find a suitable physical storage medium (probably SD or CF)
   2. Implement it. Probably without FAT or any other file system.
   3. Make sure space is being re-used, i.e. when the medium is full, the oldest stored entries are automatically replaced with the newest. Without messing up the output order, of course (possibly, this could be fixed by sorting on time stamps during print-out).
6. Buy or make an ethernet shield and get it to work. DHCP may be needed. Implement as much HTTP as required to hand over the logs in JSON, and not a single line of code more. Somewhat RESTful:y.
7. Buy a new or convert an old separate power supply.
8. Find a suitable box. An old hub, router or switch is probably perfect.
9. Make it work with a variable number of sensors.
   1. How are these supposed to be detected?
   2. Should I just try to initiate all sensors, and skip those that fail?
   3. What about plug-and-play? Writing code to continuously loop to see if there’s a new sensor attached isn’t really my idea of fun.
10. Write some cool client code, perhaps real-time graphing with Javascript? There’s probably a library for that. I hope. Or else I will have to rely on Udoprog writing me one for cookies.

Feel free to Flattr this post at flattr.com, if you like it.