Question: Multiple TWCs with no direct connection

[neilrees]

Just a question so feel free to close.

What would be required to get two TWCs load sharing when they are not physically close to each other? Basically if running an RS485 connection between the two is impractical, but they are on the same site so would like to share power between them - is it possible to homebrew a means for them to see each other?

If running multiple instances of TWCManager is it possible for them to exchange usage information, or is there an possibility of running RS485 over IP from one charger to the other and have something at the destination handle the comms with the second TWC?

Interested if anyone has any thoughts on how this could be achieved. Thanks!

[ngardiner]

That's an interesting one! Currently there isn't inbuilt logic for this, but it wouldn't be overly difficult to achieve if you had one pi on each side, it's just the approach taken. I could see a few different ways:

• A mode which places one TWCManager in a slave/relay mode which replicates TWC messages from one RS485 bus to another over the network without that TWCManager instance being a master instance, or
• A mode where each was independently master on their own bus, and reads the status from the other TWCManager

To be honest option 1 is probably the easiest, it would probably just involve another interface module which doesn't have to be very "smart" because it just replicates messages back and forward between bus 1 and 2, whereas option 2 has the advantage of being a bit more resilient, you don't rely on a single master instance - however it would need smarts to work out where each vehicle/TWC actually is in relation to itself.

Is this a scenario you have today or is this a future state, @neilrees? Would be interested in knowing what your plans were, ie were you planning on having a pi connected to each if that was able to control both TWCs?

[neilrees]

Thanks for your thoughts @ngardiner - today's scenario is that I have two EV chargers, one TWC with a Pi and TWCManager, and the other is a PodPoint unit and is completely dumb. I'm exploring options for providing more intelligence to the PodPoint which doesn't seem to have any expansion potential. One option is an Ohme cable to go in between it and the car, but I was also considering replacing it with another TWC and a Pi. At the moment I can't run both chargers (both 7KW) at full power at the same time without tripping breakers, so that's the real problem I'm trying to solve.

A second TWCManager could work, the second could be setup to use whatever capacity is not being used by the first, but as not sure they could be configured to cooperate as things stand today.

When there are multiple TWCs in play, what makes the decision as to the rate each should charge at, does the master allocate a rate for each slave or does it advertise how much power is available and they work it out between themselves?

[MikeBishop]

(2) seems easier to me, actually. The HTTP API already exposes what the local TWCs are consuming; we just need to factor these "remote" TWCs into the count of cars actually charging / amps available that's used to determine what each local TWC should offer. You'll get strange behavior if the TWCs have different policies, but as long as their policies are the same, this should work pretty nicely.

The logic in TWCSlave.py already runs semi-isolated, making decisions about what each TWC should offer based on what it's reporting and certain global values; making those global values reflect data from TWCs accessed over HTTP instead of RS485 doesn't seem that complicated, if I remember the algorithm correctly.

I wonder if there's a way we could make one of the TWCManager instances primary, and have the other one simply pull the config file from it on startup?

[MikeBishop]

When there are multiple TWCs in play, what makes the decision as to the rate each should charge at, does the master allocate a rate for each slave or does it advertise how much power is available and they work it out between themselves?

Kind of both. On the wire, the master tells each TWC how much power it's allowed to use. But in TWCManager, there's code that runs once for each TWC and considers the global state of the system plus data for that TWC. It basically boils down to:

• Not more than all the power allowed divided by the number of TWCs with non-zero usage (i.e. share fairly)
• Not more than all the power allowed minus what all the other TWCs are using (i.e. don't overload the circuit)
• But, not less than the minimum the TWC is capable of, even if the previous rule says zero (i.e. need to see when a car gets plugged in)

The idea is that when one TWC is using the full amount, the others are offering their minimum and actually using zero. When a second car gets plugged in, it starts drawing the minimum; that causes the first TWC to back off (because the fair share is lower) and the newly connected car can now be offered more.

That does mean that with two TWCs, it's possible to briefly go to the max plus the min; that should be okay, since your configured max is supposed to be 80% of what the circuit breaker permits and brief surges into that 80-100% range are safe. (The 80% rating is for draws expected to last 3+ hours; you can go up to 100% if it's short and infrequent.)

[M-VdM]

I guess you 'll find these projects by @jnicolson very interesting:

• TWCController: Wireless Controller for a Gen 2 Tesla Wall Charger (hardware and software) (TMC Forum Blogpost)
• twc-controller: Software for Tesla Wall Connector controller

The current code is written in C++. If you wanted, you could put Micropython on that ESP32.

[ngardiner]

@M-VdM Not sure I see the connection - isn't this just another implementation of TWCManager on a different H/W platform (which doesn't seem to have multi-TWC support yet)? That wouldn't inherently solve the problem of no RS485 bus connection between the slaves.

This discussion here is how to leverage the TWCManager instances connected to each TWC to create a virtual RS485 connection in the absence of a physical connection.

[M-VdM]

Bottom line: this is an in-line, in-band, self-powered (re-)programmable micro-controller PCB featuring integrated WiFi (photo). Easily addressable via MQTT for example ... but of course: some code will have to be written for that.

[leeliu]

I'd be interested in this as well. I don't have this situation today but will in a few months. I will likely need to run 2 separate TWCManagers on 2 pis with 2 TWCs.

Though prior to reading this thread, I thought that TWCManager already natively handled this with the existing code today, utilizing the home consumption meter. Wouldn't TWCManager1 simply see additional load used by TWCManager2 as home consumption and adjust itself automatically? It wouldn't fairly share load equitably between the 2 chargers (basically first come, first serve) but it shouldn't overload the circuit. Or I could be understanding this wrong.

[MikeBishop]

@leeliu, you're correct that with two separate instances of TWCManager, each TWC would see the other as part of the load and back off accordingly. Effectively, the first to be plugged in would take the spare capacity at that time; any new capacity becomes available, the first to see it will claim it. It's not really FCFS but kind of random allocation.

[leeliu]

Got it. The HTTP API is interesting. Will it allow me to artificially limit how many amps a particular TWC can use? Or maybe increase some metric similar to home consumption? Basically even if TWCManager didn't natively support this, that I could potentially even write a script to balance 2 TWCManagers to use the spare energy equitably.

[MikeBishop]

I'd think if you were going to do the coding work to build something either way, it would make more sense to extend TWCManager to support a primary-secondary pattern between two instances. On the primary side, it would need to fetch the list of TWCs from the secondary and consider them when deciding how to allocate current; on the secondary side, it would need to fetch (its share of) the allowed current from the primary and allocate to its TWCs out of that share.

[leeliu]

Heh…yeah I would if my python didn’t suck. :) I can definitely help with a poc and testing, if someone translates my eventual (hopefully minimal) code into python and integrating into TWCManager itself.

The approach you outlined is pretty much what I had in mind along with maybe some basic options like distribute equally vs preferred order of twc’s/vin’s. The api allows reads only or writes as well like how much allocate to a secondary?

[MikeBishop]

Reads only. I suggest it because TWCManager already has this logic for local TWCs and local policy -- it's just a matter of fetching it from a remote endpoint instead.

[ngardiner]

Two of the to-do list items involve remote TWC integrations, one being support for OCPP (Open Charger Project) and another being initial support for TWCv3 (in terms of reading values, not controlling the TWC). So it's possible this could leverage those interfaces or use a similar approach