The address is hardcoded...actually, most of the I2C RTCs use the same address. That's why code designed for the DS1307 will work for the DS323x.

There is a library that makes using RTC modules and doing various timekeeping functions pretty easy. Here's an example I made a while back: http://www.macetech.com/blog/node/115

While I appreciate the sentiment, don't feel too obligated until you check out the relative shipping fees..USPS is killing me here.

Their kits - alas - as a wee bit cheaper than "yours".
Even with "multi-buy" from you, with the postage and all.

Please don't be upset.

Haha, I know what I'm charging, and what my "competitors" charge. Pretty sure I'm the next cheapest option for this type of product, at least. Also, they have the DS3232 with NVRAM, but I have the DS3231SN with the industrial temperature range. It's just a simple breakout board...I even have the design files open source, so I'm not going to be upset if someone else makes something similar and people buy it. I still get a lot of business from the USA because Futurlec typically has to ship from Thailand.

Obviously it looks suspicious coming from someone selling an alternative, but I've built my own RTC modules over the years and haven't had good results. That's why I was excited about the DS3231 and made a breakout board, actually. It's surprising tricky to get a crystal that matches the DS1307 precisely enough to get good accuracy at room temperature. And the PPM specification of the crystal is really important...if you want a system that drifts only a minute or two per month at room temperature, you should certainly expect to pay more than 10 cents for a crystal.

And of course, once you take your nicely matched non-compensated RTC module out of doors into the heat or cold, it all falls apart. They are optimized for climate controlled environments and it will start running fast or slow immediately. The DS323x built-in crystal and temperature compensation really shines in an outdoor environment. Of course, in an indoor environment it'll just run a lot better. I have one that was last synchronized at the beginning of March 2012 and it's only drifted about 10 seconds.

I make the ChronoDot: http://macetech.com/store/index.php?main_page=product_info&cPath=5&products_id=8

Freetronics has a similar module: http://www.freetronics.com/collections/modules/products/real-time-clock-rtc-module

I'd recommend something with the DS3231 or DS3232. Based on the experiences of thousands of ChronoDot users, the DS323x chips have a very high level of satisfaction regarding ease of use and accuracy in a wide range of conditions. DS13xx based modules...not so much.

Makerbot.com Or makergear.com, ultimaker.com, etc.

Once you make the admittedly large initial purchase, it's like having a small parts store in your house. Just as long as you only need plastic....

When the Arduino wakes up because the alarm output pin is activated, you'll also need to clear the alarm register. Otherwise the Arduino will never wake up again, because the INTCN/SQW pin remains active until the alarm flag is cleared by the microcontroller.

You'd probably do best to look in the respective datasheets for the parts.

But I can tell you now it's pretty unlikely you'll see a collision.

You assign addresses by pulling the A0, A1, and A2 lines high or low. If a chip has all three low, it is chip 000 and in the Centipede library is pins 0 through 15. If you set up the chip as address 001, then it will have pins 16 through 31.

There should be no conflict between the RTC and the MCP23017 on the same I2C bus.

Yes, you could use just four pins from the Arduino to the shield: 5V, GND, SDA, and SCL. Several customers have done off-board connections that way (or to non-Arduino controllers).

Alternately, you can solder up some boards using the DIP version of the MCP23017, and still use the Centipede Library to control them.

No...the interrupt is latched and reading the two bytes from the interrupted chip is the best way. It can be the end of your ISR and is pretty fast...you may already be reading the GPIO anyway.

I prefer using wires when possible, but sometimes nets make the most sense. A collection of chips floating loose with only nets is a bit too much.

You may also be interested using a signal bus for similar signals.

Label your net stubs:

In your code, make sure enough time is provided after startup to let all the input sensors settle, then enable the interrupts. Does your code (which you should post) allow multiple events to happen, or is it one shot and have to be reset?

Additionally...are all the inputs connected to something? A floating input can be anything.

Look at putt return devices. It's just a solenoid that kicks the ball. You could put a solenoid in a piece of PVC pipe.

Actually, no.

The Leonardo does not have the SPI pins at the same locations. The Ethernet shield needs hardware SPI. So you will need to cut off some pins and reroute them to the ICSP header. Then, maybe, it will work.

Yes on all your questions. What are you looking for, specifically?