I thought I’d follow-up with a few thoughts on these expansion boards and where I might use them in future, and what their pros and cons are compared to simply using an ESP32 (or two)…
As I said to begin with, my original project required 5 switches with built-in LEDs, 5 relays and a handful of other sensors. It was possible to do this with an ESP32, but I had to avoid the pins that output something at startup, especially for the relay connections.
Are these really needed?
Most of my home automation projects use remotely located ESP devices to do things like control a lamp, take environmental readings, send IR signals interface to a solar controller etc, These are scattered around the house in the locations where they can best do this job, and many are built-in to off-the-shelf devices like Sonoffs (that are running custom firmware of course).
I’m not a great fan of centralising everything in one location, so the times when everything needs to be n one physical location, with banks of relays, switches and flashing lights is fairly limited (unless you happen to live on the Starship Enterprise of course 
).
My 5 relay scenario is the first time I’ve really needed to do something like this, and I think it will be a while before I have a similar challenge, but obviously everyone uses these devices for different things. An ESP32 with one expander board would obviously give the best (or is that the worst) of both worlds as the expander needs only three pins to provide an additional 16 GPIOs. This would allow you to use a combination of ESP32 and expansion board GPIOs, provided you can retain your sanity when coding the native and expanded GPIOs.
Physical layout considerations
The biggest issue I find with the ESP32 is that the GPIO numbers seem to be scattered around the board as randomly as physically possible. This means that either your wiring will turn into a total rats nest, or you’ll use GPIO numbers that aren’t sequential in your code.
The beauty of these Waveshare expander boards is that the pins are arranged sequentially in two banks and this leans itself to using a couple of 10-pin Dupont headers and rainbow ribbon cable to wire everything up. Obviously you still have the capacity to turn this in to a jungle of wires if that’s you ‘thing’, but for the OCD sufferers amongst us it does allow the wiring to be much neater.
If (like me) you like to put 0.1" header sockets onto circuit boards and give the option to easily plug/unplug your MCU onto the board then these expander boards work very well for that type of layout. The only drawback is that the address pads aren’t broken-out to pins, so if you’re using multiple boards plugged-in to a board you cant simply swap them around or plug in a replacement without first first altering the solder pad settings.
The boards do have two mounting holes in the corner farthest from the plug, so fixing them this way is also an option. once you have several of these boards floating around on the desk, or crammed into an enclosure along with relays etc, then some sort of physical restraint is needed if you don’t want sparks flying everywhere (trust me in that one 
)
I’m not sure what type of connector is used on the expander boards, but it’s not actually necessary to use this connector at all if you’re mounting the boards onto a PCB. The socket at one end of the board and the plated-through holes at the other end have straight through connections, so that don’t actually need to be chained together as i’ve shown in the photo. They are parallel bus devices, so multiple boards could all be connected onto bus rails on the PCB just using pins soldered into the plated-through holes.
Documentation and Library support
If you look at the GitHub page for the Adafruit MCP23017 library you’ll see that one person in particular has forked the code several times to add additional features. One of these removed the need to create multiple instances of the mcp object in the code, and instead enumerate the references to the various mcp boards attached to the daisy-chain. I’d toyed with the idea of trying this forked code, but decided to wait until the changes are incorporated into the main library.
Multiple ESP32’s versus multiple Expanders
You could of course use multiple ESP32s, each with their own connection to the Wi-Fi system and Blynk auth code to operate multiple devices. This has a number of advantages (the coding is maybe simpler, providing no bridging is needed) and the hardware is more familiar. I guess the cost of using this approach is slightly higher, but not to a point that makes it prohibitive.
Here’s a few pros and cons of using these expander boards, based on my analysis…
Pros:
- Expander pins are logically laid-out and easily accessible on the boards.
- The boards lend themselves to being incorporated onto circuit boards, with the minor exception of the pads used to set the addresses.
- They are cheap and appear to be readily available.
- They are 3.3 and 5v compatible, so will work with most common MCUs.
- The functionality is good.
- Interrupts are available on all pins.
- Only 3 GPIOs are required on the MCU to give upto 128 extra GPIOs.
Cons:
- Limited documentation and working code examples (hopefully some of that is addressed by this topic).
- The library is rather clunky and illogical in some ways.
- The process of reading and clearing interrupts can be a bit messy, especially when using multiple boards, but this would be simpler if all the devices that generate interrupts could be confined to one expander board.
The library may change in future, and if it doesn the there is no guarantee of backwards compatibility with the methods hat I’ve used in my code.
Conclusion
Would I use these expander boards in my projects in future - 100% yes, assuming that I have a need for lots of GPIOs.
Pete.