If you got it to compile, you're at the same state as me today. I don't have any X10 gear at home, so I can't test further.

I have some notes in "Making Things Talk" as to the hardware hiccups you're likely to hit beyond the library. In summary, they amount to:

* Make sure your modem and devices are on the same AC circuit. X10 won't get past the circuit breaker
* Once you've uploaded working code, unplug the modems and reset the Arduino. The modems are sensitive to timing disruptions. I found I can seldom get code to run without re-plugging while I'm developing, but once I have stable code, I can reset everything and it'll run reasonably well, as long as they're all on the same circuit
* Check your house codes, etc. to make sure you're sending to the right device and right group
* Make sure your code sends infrequently. Sending every time through the main loop will make a horrible mess, as the modem's only sending 120 bits a second, on the zero crossing, or 100 bits a second in Europe

Honestly, leaving X10 behind is probably not a bad idea. As I said, I have always found X10 to be troublesome. I wanted to delete it from the last version of "Making Things Talk" but there had been enough to keep it that I did, and updated the library. I've never intended that library to be a final version, and many others have made their own.  Check out  John Giametti or Doug Clinton's work for more, sorry I don't have their latest links but they are google-able.

If you want a more flexible home automation system, look into more modern alternatives like WeMo, Power line interfaces (I saw some from NetGear in the BestBuy store earlier today), or build your own with XBees and PowerSwitchTails, or your own relays.

For what it's worth, I've tested my version of the X10 library on everything from 1.0 through 1.0.3 and it works fine. I get occasional mails about it, and most of the problems seem to center on a few issues:

1) libraries installed incorrectly. For this, check that you have libraries installed correctly. That's usually the answer to 99% of the mails I get.

2) doesn't work with pre-1.0. I didn't make it backwards-compatible, sorry.

3) doesn't work with all X10 units. I don't own anything but the ones I tested it with. So I can't say.

4) doesn't do read. I have not had time or need to implement read, but others have. I recommend searching out some of the other X10 libs if you need read.

I check with each version of Arduino to make sure the code is intact, and that it compiles and works with my units, but I haven't actually implemented a new X10 project since 2010. It's not a protocol I use much anymore. X10's always been a bit flaky for me, even when the library's been working perfectly, So I haven't had time to improve this library. If I were doing home automation projects right now, I'd look into other alternatives. I find the Philips Hue, the Wemo, and the PowerSwitchTail to be more useful for things around the house, for me.  They don't have the main limitation that X10 does, not being able to send data across different circuits in my home. Every time I've used X10, I've had to ensure that the devices are on the same circuit breaker.

Hope that's helpful in some way.

Please see http://arduino.cc/en/Hacking/PinMapping2560 for the 2560 pin mapping and convenient tablular presentation.

Fixed.  The old language was from before we referred to the analog pins as A4 and A5, it should be clearer now.

I tried this on a 4x20, and I wasn't able to replicate the problem in code alone, but I was able to replicate it when any of the pins DB4 - DB7 were loose.  So it could be a physical connection issue.  Has anyone else had this problem, with known good physical connections?

Are you on a Mac?  There's a known menu issue with the Processing IDE, which is the IDE that Arduino uses: see http://processing.org/reference/troubleshooting/#known for more, but basically:

"Unlike most applications, the menu bar is inside the editor window when Processing is used with Mac OS X 10.5. This is a workaround for an Apple bug in Java 1.5 and 1.6 on Mac OS X 10.5 that causes the menu bar to be so excessively slow that the application appears to have crashed. (Bug 786)

"Please file a bug report with Apple at bugreporter.apple.com if you want this fixed. The problem has existed since the spring 2008, and we first filed a bug with them in June, and we have received no indication that it when it will be fixed, or if it will ever be fixed.

"Or if you want to take your chances with the slow menu bar, you can change the default setting in the Preferences window. "

Arduino defaults to the menus at the top, but you can go into Preferences and change it to place menus inside the window to avoid this.

Yep. On the Diecimila and Duemilanove and mega, you don't need to hit reset when you upload, but on other models you do.

It doesn't hurt to hit reset on any of the models, though, so if you're unsure, hit the reset button on upload.

I just posted version 0.7 of the String lib, which is basically the bug fix Mikal Hart posted.  Sorry for the long delay. String is not part of the core, so it's always been a side project for me, and one I only get to once in a blue moon. The memory bug,at least, should now be gone. Thanks Mikal.

This is an interim version. Hernando Barragan made some nice API changes for a Wiring version, but they change the core libraries a bit, and have not yet been ported over fully. There are also some changes I want to make, because there's some nomenclature and behavior I'm not happy with.   Xiaoyang Feng is working on this.  The major issue he's working on is to make the library portable without need to modify the core, and to reduce memory usage somewhat.  If anyone wants to jump in on this task, mail me.

Thanks Mikal. I am visiting family at the moment, with no Arduinos handy to test, but when I get back to work, I'll add this to the String lib.  

FWIW, though, this library is not part of the core distribution, to my knowledge.  It isn't in the svn, and isn't in the distribution, though that'd be nice.  There are also some optimizations I'd like to get to as well, but the day job keeps getting in the way

...and the length bugfixes are already in 0.9, posted now.

Thanks for the discoveries, and sorry for my delay in replying to this.  We've never included String in the core libraries partially because it's always been a little buggy and not ready for prime time.  One of my colleagues and I are doing some work to improve that in the coming weeks, though, and I hope we'll have a new version up soon.

I like that last solution even better, since it is consistent with what we do in the state change detection example. I'll put that in the SVn for the next version, thanks.

I'll try it when I've got a board in front of me next. Seems like a reasonable change, as long as the time between checks is never significantly larger than the interval, for any reason.

Examples are all up to date now, thanks.  As for the changes in the library, patches are welcome, best way to submit them is via the google code issue tracking database at http://code.google.com/p/arduino/issues/list.

THe "blobby things hanging down" are force-sensing resistors.  You can get them from a number of online retailers now: Sparkfun, Adafruit (I think), Trossen Robotics, Images SI, and more.  That particular model is made by Interlink Electronics.