What are you calling an emonHub device?
Do you just mean a raspberry pi without an emonPi or RFM2Pi add-on board? I would still regard that as an emonBase. I have several RPi’s that have USB connected emonTx’s and run emonHub (software), I still refer to them as emonBases even though they have no ability to receive RFM transmissions.
As would I.
2x RPi’s? 6x Tx’s and 6x USB adaptors, yes plus
2x good 5v AC adaptors (genuine RPi or good 3A+ with integral (micro-usb) leads)
2-6 AC:AC adapters depending on whether you “share” the AC signal (you’ll need some cable and connectors to do that and beware of the AC polarity as one side is connected to gnd (0vdc) in each emonTx so a short could be caused through the USB’s)
and of course 22 CT’s
The main pointer about multi-usb connected emontx’s is identifying each one. By default the emonTx stock FW doesn’t pass a node Id so unless you chose your USB-serial adapters very carefully so they are not all indistinguishable (from each other) devices you will need to edit the firmware of all the emonTx’s to output a node id. If you are planning on making FW changes either way, this becomes less of an issue of course.
The problem is that linux assigns device addresses on a first come first served basis at boot time, so whilst one day node 10 might be /dev/USB1 at the next boot up /dev/USB1 could get assigned to the emonTx known as node 15 (for example) which will really screw with your data (and your head!)
When the emonTx FW identifies itself within the payload you can have 4 identical interfacers set up in emonhub for /dev/ttyUSB0 thru /dev/ttyUSB3and it really doesn’t matter who gets what address, unless you unplug one and reconnect it, then that one may be given the address /dev/ttyUSB4 and not seen by emonhub.
If you use genuine FTDI usb devices (or really good clones so that eeprom is functional) you can give each of your emonTx’s a unique serial number and create udev rules so that each device is always recognised by a address defined by you eg /dev/emonTx-abcdef where “abcdef” is the serial number you have defined.
But beware there are “bad clones” out there that are sold as genuine and do not even function the same way (let alone being actually genuine). I suspect that the ones I use are just “good clones” as they are cheap, but the first thing I do when buying “FTDI” (brand) devices is check the eeprom works. If you are buying from ebay (for example) you can back them if the eeprom doesn’t function, it’s either faulty or a poor clone. Unfortunately, even the sellers are often duped, I cannot recommend a seller as even when i have found a reliable source in the past, they have had bad batches, it’s a bit of mine field or just pay the “genuine” prices if you want to avoid the hassle/risk.
Search the forum for “udev rules” for more on this. The FTDI software to program the FTDI eeprom is FoC from their website and it’s really easy to do (unless they are bad clones, then it’s impossible).
[edit]
Also if you mount all the emonTx and the Pi in a (ventilated) box you can save yourself the cost of 6 emonTx cases (and 2 Pi cases?). This makes mounting the FTDI’s simpler, neater and less prone to being knocked. Her’s 3 emonTx’s stacked in a box with a RPi from the thread previously linked and also of the flip side so you can see the FTDI “stuck on” where the battery carrier used to be.
Also note that although the emonTx’s MCU operates at 3.3v, it requires a 5v supply so set the FTDI to 5v not 3.3v.