Funny. I ran into a similar lightning problem with my house and kinda had the same idea two years ago. Lightning sucks. Had a lot to learn about proper overvoltage protection despite being an electrician. That post is older, but maybe it helps others who go down a similar approach a bit.
At first I wanted to use I2C expanders too, because I needed lots of pins, but due to lack of excess time, I still haven't even started experimenting with those. I ended up just using the Arduino GPIOs. I connected them via USB to a Raspberry PI 2, but also used an USB Lan Cabel Adaptor to connect to one in a remote control box over a 25m long shielded Cat5 network cable.
Then I ran into the connection drop problem described here:
I found a different solution by simply adding one of those cheap 10€ USB-signal amplifiers to it. It's running stable for one and a half years now. (Only works with the amplifier on the PI before the adaptor, not the other end of the cable surprisingly)
My 4 Arduino Mega are running on Firmata, talking to node red trough the nod-red-node-arduino. Btw I'm still using old version 0.0.18 of it, because newer versions including the latest version 0.3.1 don't seem to safely reconnect after a restart when several Arduinos are connected to the PI at once. Occasionally all nodes configured to connect to one Arduino, may connect to the wrong one or not at all at reboot. Same when reimporting saved flows. Don't know why so I stick with the old version working fine. I'm open for better ways, but "never change a running system". I'm actually using over 240 GPIOs (including the RPIs) simultaneously, to do my home automation, to give you an idea.
I've connected all my ordinary installation push buttons (4-ways mostly ~25€ each) throughout the house via standard shielded cat5 network cables to the GPIOs on the one side (using the integrated pullups configured in the node). On the other side, the commons of the push buttons are connected to 1 current limiting resistor (just in case an input becomes an output) connected to RPI ground.
The response time is insanely fast! 2 to 6 on/off massages are sent within 2-4ms on a single push down. You can literally record the bouncing effect of each push button in node red, that's how fast it responds. Crazy! While that's easy to filter out, what's more difficult is the capacitive crosstalk transmission between the wires within the same long cable. When one is pushed, the other buttons(wires) inside the same cable, within the same shield, may go on too, just to go off again after a very short time, only the pushed remains. Increasing the time in a debounce node, beyond that time frame alone, will still results in false button released messages. EM interferences like when several devices turn off under load (blinds ~15-45ms) or again heavy thunderstorm lightning (~60-70ms) were another source of problems. Yes I had to figure that out the hard way and found sulotions. Using Pullup is a necessity. Shielded cables help, they aren't antennas. Long unshielded wires are. Connecting those shields and grounding them may help too. While not placing the relays directly next to the Arduinos maybe might have helped as well, a little subflow after each input node to filter it all trough code solved it for me. Reliably so and heavy thunderstorm proof.
For switching I used 8€ cheap china 5V 8-way relays for Arduinos. They are rated at 10 Amps (wouldn't trust it), enough to switch blinds and LED light bulbs though. Compare that to a 300€ 8-way KNX actor who does nothing but switching either. OK, thats comparison is off a bit. They all worked fine for 2 years now. Let's see how that progresses. To replace a defective would take maybe half an hour. They have onboard optocouplers and flyback diodes on a separated relais circuit onboard (if you connect it right). To have the possibility to use an extra power supply, separated from the RPI (and Arduino) one, just to power the relay circuit alone is nice, because it can't affect the other circuit, due to the electrical isolation between them, like when your switching lots of relays at once. But they have inverse logic, meaning they turn on when GPIO is low or 0 (has negativ (-) potential). Happens during startup and reconnects like during a redeploy! Fair warning: blinds engines may die when up and down relays can switch on at the same time. It all depends on the right relay wiring to prevent that. Raspberry GPIOs don't show that startup turn on behavior with those relays. I just use one of these to cut off relay power until deploy or startup completes.
I handle all the programming in a modular way using subflows, from double-click long-press inputs, to blinds or rolloshutter relay control, to dimming LED Lamps, to talking to RGBW LED Stripe Wi-Fi Contollers by TCP. For each functionality I created its own subflow and now I only have to connect these subflow modules the way I like it, transmitting switch states color information or what have you. I used openhab for hue light control and dashboard at first too. Too complicated for me. But since there are new functional contrib nodes it's all node red now. The colorpicker could be better for lights though.
