Skybound, I am new to Blynk but have some experience with the issue you are encountering.
There are many reasons to prefer the approach of having several 4 port dosing controllers vs. a single 8, 12 or 16 port controller.
Some reasons that immediately occur to me are:
- Scalability. Need more pumps? Add another 4 port controller.
- Have a failure? Keep a spare 4 port device with pumps attached for quick changeout. It is both more difficult and potentially economically prohibitive to replace the 12 port controller if something fails.
- When you have several wires per port, it becomes more and more difficult to physically get the wires into a small board even if it does have 30 more I/O pins. At some point you begin to knock wires loose as fast as you connect them. This doesn’t happen when you modularize.
The downside of such nearly identical modules (aside from MAC address) is that they need a manager process to support a single point of communication with the outside world (Blynk).
This is a significant issue since you need to have a protocol to communicate between all the modules and a manager, whether that manager is a separate dedicated device or one of the modules that runs the management function in addition to its doser pump control activity. The manager is the only one that would communicate with Blynk, collecting and dispersing the Blynk virtual pin data from and to the other modules.
I used this strategy to build a 32 bit EL wire controller from 4 8-bit controllers with low end AVR processors (Sparkfun), connecting them with the SPI bus.
With an ESP8266 you could also use the SPI capability or a mesh strategy based on WiFi to accomplish the same thing.
This is a pretty challenging task, however. It would be worthwhile if you are contemplating commercializing your design or convincing many people to use you work.
If you intend this to be for your sole use, the balance is probably in favor of the multi-IO (ESP32) board because, even though it has disadvantages, you can do the simple thing in the software, just adding more virtual pin handlers and associated ‘operational’ code.
My inspection of the functions available in the Blynk environment has not suggested any way to serve separate modules in a single project where it is necessary to act on them specifically. (The SuperChart can aggregate among several devices but the operations are all unordered – average, sum, median, min, max – using a common tag mechanism. That tag mechanism means that it cannot be easily extended to the retrieval of an array of values with known order, for example.)