Just to confirm: there are only 2 bits used for the address space of the wall connectors in a master-slave configuration ?
So normally it will not be possible to dynamically control more than 3 or 4 chargers with 1 controller ?
Thinking about a config with 8 chargers where we want to optimize charging based upon power output of our own solar PV.
Each TWC has a two BYTE id ranging from 1 to 0xFFFF. Although the manual says only 4 TWCs can be linked together, there's nothing about the protocol that implies such a limit. I've never tried simulating 4 or more TWCs on a network so I'm not sure what would happen. I suspect normally the master TWC would show an error light when it detects more than 3 other unique ids, but if TWCManager is playing master, maybe there would be no limit? Slaves could also detect the presence of more than 3 other TWCs and show an error but I'm not sure if they do or not. You could give it a try. TWCManager will currently show an error when more than 3 slave TWCs are connected and it will drop the oldest slave from its memory. You would have to modify that behavior in
sub new_slave.
The 9600bps speed of communication limits it to ~70 messages between TWCs per second, but Master is expected to send a heartbeat message per second to each Slave, and Slave sends one heartbeat message back. Voltage and amps are exchanged periodically, which adds up to 2 more messages during some seconds, so up to 4 messages per second per TWC pair. 70 / 4 = 17 max TWCs in theory but I suspect with processing time and perhaps intended delays designed between messages the actual limit is lower.
Even if slaves start showing error lights when they detect more than 3 other slaves on the network, you could use two Rapsberry Pi Zeros running two copies of TWCManager and separate your TWCs into two groups of four. You'd have to modify TWCManager to talk to the other master TWC wirelessly when deciding how to split power between the two groups. If the wifi link was ever lost you would need a safe fallback state. Perhaps choose one TWCManager that shuts down its charging or set them both to draw exactly half the available power.
Also note that TWCManager sends one heartbeat message per ~1.1 seconds to each slave in a round robin. That works fine for small numbers of TWCs but with 8 there would be over 8 seconds of delay between heartbeats for each slave. That could help you fit more slaves on the network but it might also cause slaves to think Master has disappeared. I seem to remember slaves wait 20 seconds before they decide that, but it's something to watch out for. I assume a real TWC master would send a heartbeat to every slave once per second but I've never monitored to confirm that. Allowing 8 seconds of delay between heartbeats is probably not safe if you ever tell one TWC to rise to max amps and wait 8 seconds to tell another TWC to go to min amps, so I would advise altering TWCManager to send heartbeats more often with more than 3 real TWCs being controlled.
Also, a real TWC Master uses a tactic of sending state 06 or 07 to gradually shift each slave up or down by 2 amps every 10 or 20 seconds which makes things even more safe as far as preventing one slave from spiking power up when another slave is still using high power. TWCManager is not that advanced and will use state 09 to set an absolute amp limit on all TWCs whenever a new car plugs in or a car unplugs. I think that's probably fine with up to 3 TWCs such that they each get the new settings within 3.3 seconds, but it might be an issue with 8 TWCs and 8.8 seconds of delay. Basically, TWCManager was not designed with the idea of controlling more than 3 real TWCs in mind.