Hi Paul,
a full answer to your question is hard, since you did not describe you ful setup. But cascading rainduinos in general is very easy. I2C is a single Master bus topology, so I see 2 options for your scenario.
(I2C-Master)<->1stRainduino)<->2ndRainduino)<->3rdRainduino
The master could be an arduindo or anything else that can send the messages. all 3 rainduinos will use the same code, but must have different I2C addresses.
In this case the master must be aware of the fast that there are 3 recievers and where to send which messages.
This is also what I have used in my project. The master arduino has a network shield and offers interfaces for both global control e.g. set color xyz will be translated into 3 identical messages send to the 3 different IDs as well as some specific interfaces like DrawPixelABCRGB where A is the ID of the receiver B and C the coordinates inside the rainduino and RGB the color.
external interface e.g.serial->1stRainduino)<->2ndRainduino)<->3rdRainduino
In this case you need 2 different firmware vesions, one for the first rainduino, which is capable of spliting the incoming commands to the ones used hinself and the one to be resend via i2c to the other rainduinos. The other to rainduinos will just have a simple slave SW like in example 1.
secnario 1 is more what I was thinking. I’m familiar with the i2c bus. When I tried using neorainbowduino firmware, I got a problem where the i2c slaves simply didn’t respond at all.
I’d be happy with some sample code that I knew worked. Otherwise it’s easy to get tied up with bus timing and irq servicing. What upsets me is the blithe remark “i2c is easy” with no code to back that up.
The wiki even says for the RainbowDash firmware (which seems to be working great) that “Can easily be changed to use I2C; only one file (RainbowDash.pde) needs to be changed.” I wondered if anyone had actually done it.