Pool coping project looming

Well, May starts tomorrow, and with it comes… the pool project. This is sure to be the topic of many entries over the next couple months.

Background: Late last summer I noticed a loose strip of waterline tile in the deep end of the pool. Further investigation revealed that all of the coping stones in the deep end had also popped loose. Long story short, I planned the repair for this spring. Basic plan is to:

  1. Sawcut the expansion joint (between deck and coping) so the deck doesn’t contact the pool shell;
  2. Rebed the loose coping;
  3. Recaulk the expansion joint.

I’m putting the waterline tile repair off till next year, as it’s mainly cosmetic and I’ve got other stuff to keep me busy this summer..

#1 and #2 are pretty straightforward; for #3, the common practice is to use a self-leveling polyurethane caulk. There’s a pool-specific product called Deck-O-Seal which is commonly used. Of course, being pool specific, it’s pricey. There are other equivalent products sold under different trade names, which are somewhat less expensive if you can find a decent supplier. The brand names I’ve run across include Vulkem, Sonneborn, and Sikaflex. My hope is to find a local supplier for this stuff; that way I avoid paying shipping, and if I need more, I can just run out and get some (possibly multiple times). Anyhow, the great news is, today I found the Sikaflex product at Home Depot in the concrete aisle. Hard to beat Home Depot for convenience.

Now that I have somewhere I can buy the sealant, I can focus on planning the job and getting it done. The plan right now is to start this around mid-May, so I have some time to finish up other projects first. Depending on when we decide to uncover the pool, it may get pushed back… we’ll see.

Alarm Oddity

So, I’ve got the wireless keys programmed into the alarm. Everything seems to work. The only “wild card” here is the range of the things, because the receiver is mounted a little farther away from the garage than I’d like. If the range turns out to be a problem, I’d expect all of the buttons on the keys to work inconsistently. What I’m seeing in practice, is that the garage door button works consistently, but the disarm button is spotty. I get the same behavior with both keys.

I don’t really have an explanation for this, so the first thing I’m going to try is moving the receiver closer to the garage. I’ll mount it in the new spot temporarily, and see how it works (in particular, it needs to still work with my existing wireless zones). The other thing is, I still haven’t installed the status transmitter module. It doesn’t seem like that should have anything to do with it, but I’ll go ahead and install it at the same time, and see how things go.

Stay tuned..

Followup.. turns out the spotty behavior did affect the garage door button after all, so most likely, this was simply an issue of the signals not getting to the receiver. My hypothesis is that the house’s aluminium siding was interfering with signal propagation. The fobs seem much more reliable now that I’ve relocated the receiver.

More on Coppermine

Still playing around with Coppermine, trying to set things up so that Cathy can have a separate login and still have the ability to upload and edit photos in the public albums. First, I tried setting her account up in the registered group. After a bit of fiddling and RTFMing, I was able to get it so that the account could upload to public albums. I had to

  1. Remove the disk quota from the registered group (group admin area, change default quota from 1024K to 0)
  2. Enable registered group to upload to public albums without admin approval (group admin area)
  3. For each album, go to the configuration page (go to album list and click “properties”). In properties, select “Visitors can upload files”

After I did that, I could upload pictures, but once uploaded, I couldn’t do anything further with them (like adding captions etc). So it looks like this isn’t the answer. That leaves me with two options:

  1. Add Cathy’s account to the administrators group; or
  2. Move all the albums to Cathy’s “personal” album space, so she “owns” them; then she should have access to them and I can access them through my administrator account.

For now, I’m going with option #1 because it’s the easiest.


A couple weeks back, I downloaded a PHP/MySQL-based online photo album package called Coppermine. At the time, I was looking for kind of a be-all-end-all-do-everything solution to managing all of our digital photos and publishing them on the web. I installed it and gave it a go last week. Installation was straightforward as soon as I got the MySQL tablespace properly configured. Once it was ready to go, I uploaded some pics to it.

The Coppermine documentation is very much geared towards users with web hosting services, as opposed to people like me who run their own servers. It took me a bit of sifting through directions like “use FTP to upload the pictures to your web hosting service”, before I figured out that all I need to do is place the photos in a directory that my Apache installation can read and write to. Once I did that, I fired up Coppermine’s import tool. And waited. And waited. And waited.

It appears that during the import process, Coppermine runs “convert” (from ImageMagick) on each file to create thumbnails and “intermediate” sized images. From running “top” on my server, it looks like it fires off four “convert” processes at a time (this may be configurable). This process is a bit slow on my crusty old 450mhz server box. So it looks like if I’m going to be importing hundreds of photos, I’m going to need to run this on a machine with a bit more juice. It probably doesn’t help that the web server is currently accessing the photos over an NFS mount.

However, once the import finishes and the photos are online, the viewer works pretty well. I think for now, I’ll scale back my ambitions and just use Coppermine to publish photos I want to share. I’ll move them to a local disk on the web server box, and then I’ll just pick and choose the photos I want to upload to it. I think it’ll do very nicely in that configuration.

More later..

Followup.. Desperately in need of a photo browser for my Linux box, I looked around and found xnview. The Motif interface is a little dated, but it works very nicely and it’s fast. It supposedly also works on Windows and Mac. I played around some more with Coppermine and found that it has a user-level upload tool, where I can upload pictures through the browser. Pretty cool.

Busy yardwork day

I played hooky from work today so I could catch up on some much-needed yardwork. If my work schedule permits, I really like doing that because I can pick a day where the weather is good, knock off all the yardwork, and free up the weekend for more leisurely pursuits. I started at 9:30 this morning doing trimming and edging, then mowed all the grass, then mulched up some twigs with the chipper/shredder. Plus, I relocated one of our compost bins and fixed the door on our big barrel composter. All in all, a very productive day.

Next up, I need to do a little pruning and weeding, and do end-of-season maintenance on the snowblower. Then I’ve got two outside projects I’d like to get done before I have to deal with the pool… a new lid for the sandbox, and a permanent pole for our bird feeder. I hope to get the ball rolling on these this weekend.

Adding content to Perl myUMBC codebase

Urrgh. I added new functionality to the Perl myUMBC codebase today, and I had forgotten what a pain it was. You know things are bad when you wrote the code, and you have to spend an hour trying to recall how it works. Since it looks like the Perl stuff is going to be around for awhile, I figured I might as well document this process while it’s fresh on my mind. Maybe it’ll save me some time down the road.

Just to clarify… when I speak of myUMBC here, I’m just talking about the Perl stuff, not uPortal. With that in mind, here goes.

Background: Everything in myUMBC is database driven. Every link, table, dropdown menu, heading, etc. that you can see, click on, or otherwise manipulate, has a corresponding entry in a database table. All internal URLs in myUMBC are of the form


The function code tells myUMBC what the end user is currently doing. Most of myUMBC’s core functions (registration, etc.) actually have two function codes, one for the initial screen, and one for the results page. Every function code needs to have an entry in the database. Otherwise the user will get a “not authorized” type error. This is to keep users from entering arbitrary function codes and producing undefined results. The database table that contains all of this stuff is called BRCTL.PROD_PROG_DESC (don’t ask about the name).

To add to the confusion, myUMBC also has a built-in function mapping table, which maps shorter function names to possibly-longer Perl subroutine names. For example, the Financial Aid Inquiry function I added today has a short name faidinq which maps to a subroutine finaid_inquiry. There’s no real reason for doing this, other than shortening the URL.

To make a long story short, first, you need a PROD_PROG_DESC entry with PPD_LINK_TYPE set to “function” and PPD_URL set to the name of the Perl subroutine that builds the initial HTML (which could be a table, dropdown etc). Then, you need a second PROD_PROG_DESC entry for the results page. This one should have PPD_URL set to NULL, and PPD_FUNCTION_NAME should match the Perl subroutine that generates the results page.

That’s basically it… unfortunately, that probably didn’t make much sense unless you’re already intimately familiar with the myUMBC Perl codebase. One of these days I’ll improve and expand on this, to make it fit for general consumption. That’s why it’s in my blog and not the Syscore Wiki..


6/16: Here’s how I made our new Student Parking Registration form come up:

INSERT INTO prod_prog_desc

    (ppd_prog_id, ppd_url, ppd_desc, ppd_add_date_time,
     ppd_add_user_id, ppd_link_type, ppd_restrict_access,
     ppd_auth_level, ppd_function_name, ppd_portal_disposition)


    ('NEWPARK', '%2bParkingRegistrationForm',
     'Student Parking Registration (new)', sysdate, 'paulr',
     'myumbc', 'N', 'password', '+ParkingRegistrationForm', 'maximized')

Great to have notes to refer back to..

Quick note on Palm iCalendar Sync

A couple weeks back, I upgraded my copy of Missing Sync to the latest version, version 5.1.0. Last night I noticed that event deletions from my read-only calendar subscriptions had stopped propagating properly to the Palm. I probably should have suspected something was amiss.. every time I ran a sync, I was getting a sync services dialog telling me that the sync was “changing more than 5% of the calendars on this computer.”

I also had the event deleting problem when I first installed Missing Sync. At the time, the Mark/Space support folks gave me a procedure to erase everything on the Palm, reset the sync history, and sort of “start over”. It worked then, and it worked this time too. I documented the procedure in this post.

Looks like I might want to do this every time I upgrade Missing Sync, just to make sure I’ve got a clean slate and nothing gets wonky.

I’m still happy with Missing Sync. Now I’m pining for a desktop Mac, so I could do a bluetooth sync from anywhere in the house without worrying about firing up the laptop….

Wireless Alarm Keys Demystified

I successfully programmed an Ademco wireless keyfob transmitter today, and figured I’d document the process.. My panel is a Vista-20P and the transmitter is a 5804BD.

  1. Program an RF house ID into the panel. The house ID needs to be a number between 0 and 31. On the Vista-20P, this is done in location *24:

    Enter programming with 4-digit installer code + 800
    Enter *24
    Enter 2-digit house ID
    System chimes to confirm entry

  2. Install batteries in the transmitter. When prying the case open, hold the transmitter with the buttons facing down; otherwise they’ll all fall out when you pull the case apart.
  3. Program the house ID into the transmitter per the instructions. It must match the house ID programmed into the panel.
  4. Program each button individually using zone programming (*56). On the Vista-20P, zones 49 through 64 are reserved for keyfob zones. The following example will program button 4 to disarm the system:

    Enter *56 to enter zone programming
    Enter 1 at Set to Confirm? prompt
    Enter 49 to program zone 49 (or whatever)
    Enter * at summary screen
    At zone type prompt, enter 22 (disarm)
    Enter 1 at partition prompt
    Enter 0000 at report code prompt (no report)
    Input Device type will default to “Button type RF”
    Enter the device serial number at the prompt
    Enter 4 as the loop number (corresponds to button 4)
    Press button 4 on the keyfob at “Xmit to Confirm” prompt
    System confirms that the correct serial number was transmitted
    Review summary screen and press *
    Press 0 at “Program Alpha?” prompt

    Now, exit programming and assign a user number to this button: Enter master code + 8 + user number + #4 + zone number. For user 04 and zone 49, you would enter

    master code + 8 + 04 + # 4 + 49

    Keypad will chime to confirm.

    That’s it; button 4 on the keyfob should now work to disarm the system. The process should be repeated for each button on the fob (each button corresponds to a separate loop number).

Next step is to hook one of the buttons up to the garage door opener. It appears that I need to program the button as zone type 23 (no alarm response), then go into device programming and define an output function to activate the appropriate relay when the zone trips.

This weekend I’ll install the 5800TM transmitter so that the fobs will be able to display system status. I’ll also test the range to see if I’ll need a repeater. Hopefully I won’t.

Followup 4/22… I’ve programmed both keyfobs and everything worked as expected. I’m pretty impressed with the range of these things.. it seems to be pretty close to the advertised 200 feet. It’s looking like I won’t be needing a signal repeater. Haven’t gotten to the 5800TM yet, and may not this weekend, but the fobs don’t need it to work. I’ll use this week to test them out, and assuming they continue to work well, I’ll put the 5800TM in next weekend.

Bike to Work

The summer ritual officially began today: I rode my bike to work for the first time. I’m admittedly a fair-weather biker; I bike when it’s warm, sunny and light outside. So, today was my first time on the bike since, oh, last October or so. Combine that with two weeks or so of relative inactivity while I was home helping care for our newborn, and well, suffice it to say that I didn’t break any speed records getting here this morning. And then there’s the ride home looming, with its dreadded mile-long grind up Lawyers Hill Road. But I’ve got 8 hours or so before I have to worry about that.

With gas pushing $3 a gallon, the financial incentive to bike in (and avoid driving) is stronger than ever. The commute to work is about 15 miles round trip, and my car gets roughly 30 miles to the gallon (actually that’s being generous, it’s probably more like 25-28), so I save about 1/2 gallon of gas every time I commute by bike. At $3 per gallon, that’s around $1.50 extra in my pocket for each ride. And the more expensive gas gets, the bigger the payoff gets.

Last year, I biked to work 22 times, but I didn’t start doing it until early August. So hopefully this year I can do it a lot more. This year I plan on keeping a log so I can track my times, average speed etc. At the end of the season we’ll see how I did.

Blosxom Import Complete

I just finished importing all my Blosxom entries into b2evolution. The process was more or less painless; I just pulled down all the Blosxom entries in Movable Type format using the flavor I mentioned earlier, then processed the result with a Perl script, then ran b2evolution’s Movable Type import utility to bring the entries in. The Perl script basically catenates lines together in the body area of each entry, which makes the result look more attractive in b2evolution. Once the entries were in, I went through and made minor edits to make things look better.

The only thing I don’t care for about b2evolution is its insistence on sticking <br> tags at the end of every line, even within blocks of markup. This makes it really hard to include code snippets, because I can’t use <pre> blocks; I have to explicitly format everything and use &nbsp; entities to do spacing. There must be a way to make this work right, but I haven’t found it yet.

That aside, it’s nice to have a “real” blogging engine with all the associated bells and whistles. I’m sure I’ll figure out all of b2evolution’s various quirks over time.

Followup — Looks like the <br> tag thing is controlled by the Auto-BR option at the bottom of the page where you edit posts. It seems to be turned on for all the imported entries, and off for the native entries. When Auto-BR is off, it seems to be much better behaved with embedded HTML in entries.