Welcome to Tesla Motors Club
Discuss Tesla's Model S, Model 3, Model X, Model Y, Cybertruck, Roadster and More.
Register

Tesla Wall Connector load sharing protocol

This site may earn commission on affiliate links.
  • Like
Reactions: M_VdM
Woot! So, you've got a new TWC with the latest firmware, right? Is it sending any additional messages or data with voltage or battery state that TWCManager doesn't recognize?
I don’t know yet, it is still in the box.... I am really short on time. Traveling at the moment and won’t be home for another week er so.

In the mean time I am porting the software as far as I can.
 
TWCManager updated.

Added $greenEnergyAmpsOffset config parameter. See the comments above it but basically you can tweak it till you are neither taking much energy from, nor sending much energy to the power grid.

Web GUI has been prettied a bit and expanded to support two main new features:

1) Set a constant amp value to charge at plus a time to return to tracking green energy. So say you come home late with little battery left. You want to charge at max 40A overnight but return to tracking green solar energy at 6am. You can do that like this:
One-time quick charge.jpg

At 6am the next day, Non-scheduled power: will change back to "Track green energy" and stay there.

2) Set a minimum charging level to be applied between certain hours. For example, you want to charge from green solar energy during the day, but if the car is not completely charged due to clouds or whatever, you want to complete the charge overnight when power is cheapest:

Backup charge overnight weekdays.jpg

In this case, we've used the on days checkboxes to charge at 40A starting only at 11pm Sunday through Thurs to get to work on weekdays. on days only applies to the start time of the charge, so it won't stop charging at midnight when it becomes Friday.

I may add an option for two or more sets of schedules if someone requests it. Other than that, this will likely be the last significant change unless we discover battery state info.

To save all these settings, overrideMaxAmps.txt has been replaced with TWCManagerSettings.txt which is completely controlled by the web GUI. Changing it manually will have no effect unless you restart TWCManager.pl. Avoiding checking the SD card for changes to overrideMaxAmps.txt up to once every 5 seconds hopefully saves a little bit of power.
 
Last edited:
Two new TWC's here, i'm seeing a few new messages, like status messages every 5 seconds, reporting voltage per phase, and total kWh's delivered.

C0FDEB37240000000000E400000000002AC0FC: status message from 3724
C0FBEB372415010000000000000000005CC0FC: status request from master 3724 to 1501
C0FDEB15010000003800E600F100E800F8C0FC: status message from 1501

38= total kWh's (does not reset between charge sessions)
E6, F1, E8 = voltage per phase

Messages are also longer, as you can see.

Btw a Tesla will not use the J1772 signaling for communicating with the TWC, but uses 1 wire CAN at 33 kpbs.
The TWC will send it's serial nr, model nr to the car, and the car will send it's VIN to the TWC.
SOC, and minutes remaining are also on the CAN bus.
Just like a supercharger..

Unfortunately, i have not seen any messages that would indicate the SOC of the car on the RS485 bus.

I have seen a few heartbeat messages witch i don't fully understand yet.
the master>slave status bytes i have seen are:
00 all ok
05 start to charge (charge current in next 2 bytes)
06 charging, increase charge current with 2 amps?
07 lower charge current temporarily (10 seconds) with 2 amps.?
08 ack of master to charging stopped from slave.
09 limit charge current (next two bytes)

06 and 07 are weird, why would the TWC send these messages?
 
06 charging, increase charge current with 2 amps?
07 lower charge current temporarily (10 seconds) with 2 amps.?
08 ack of master to charging stopped from slave.
09 limit charge current (next two bytes)

06 and 07 are weird, why would the TWC send these messages?

At the top of send_slave_heartbeat() I have notes on when I've seen the various states. 06, 07, and 09 are not codes I've ever seen my TWC send in Master or Slave mode. If they work as you suggest, maybe they're used to let slave TWCs monitor their own car's SOC and request that Master raise or lower their amps to keep car charging balanced?

I'm not really sure how that could work unless each slave acts like its own load balancer... Slaves all see the same data Master sees so Slaves could note how many amps are being sent to each other slave and when they know the car they're plugged into is at a high SOC and they see a different slave is requesting a lot of amps, they decide they should request fewer amps for their high SOC car.

If it does work something like that, then all TWCManager can do is respond with proper acknowledgements to raise or lower amps as requested by each slave TWC.

To investigate further, you could put TWCManager in fake slave mode (set my $fakeMaster = 0; in the config area) and send 06, 07, 09 and see how a real Master-mode TWC responds.

Then return to Slave mode and see what the slave does if the fake master doesn't give an expected response. Does the slave still lower the amps it charges at and just try to tell Master what it's doing? Or does it only change if Master says it's okay?

Maybe it was done in this convoluted way such that TWCs with newer firmware could coexist with older firmware TWCs? Since the Master isn't actually in charge of load balancing, the master maybe doesn't need newer firmware? Or only the master needs newer firmware? It depends how or if Master needs to respond to those new codes.
 
Last edited:
  • Informative
Reactions: pilotSteve
Did anyone figure out a way to command a slave to stop charging?

The first way way of doing it is to send a "02 01 00" state/command as master to the slave. that will immediately stop charging, but the TWC will start blinking an error code, so you can never start the charge again, until you reset the TWC.

The other way is to stop sending heartbeat messages to the slave, it will then timeout and stop charging in 30 seconds.

I tried lowering the charge current, but everything < 600 (6A) is ignored , and the car will still charge at 6A.
 
Firstly, very cool work you guys are doing. A lot of possibilities open up for cool managed charging scenarios...

Second... I've been mulling over the minimum charging level of 6A that it seem the model S will accept. It occurred to me that the minimum power the car ever expects to see is using the UMC NEMA 5-15 connector on a 120V outlet. That 1.44KW (12A x 120V).

It so happens that 6A at 240V is also 1.44KW. So I wonder if that floor value is a byproduct of the system not expecting any less that that?

This also makes me wonder what will happen if I manually dial the current down in the car to something less than 12A when I'm plugged in to a 120V outlet.
 
  • Like
Reactions: Ulmo and pilotSteve
As far as I can tell, the underlying J1772 spec only supports 6 - 80 amps. You're likely running into trouble selecting current ratings outside this range (below 6 amps) because the J1772 specification doesn't support it and so the Wall Connector rejects that input.
 
TWCManager stops the slave TWC from charging by setting the car to 0A using state 05. The car eventually goes to sleep, turns off all its fans, and only checks for power every 15 mins or so. See notes in source code for details. Hopefully that behavior hasn't changed in the newer firmware TWCs. Listen for fans under the hood when you've set it to 0A.

5A is actually the minimum you can reliably charge at because 5A can be selected from Tesla's UI, at least on US cars. The J1772 spec says 6A is the minimum but I've charged down to around 1A successfully, at least for short periods, before the car decides it's an error condition. I suspect the hardware is designed with 5A minimum in mind and you may be creating a highly-inefficient situation or perhaps a potentially damaging situation by sending under 5A which is why the car decides there's an error and stops charging when set to low amp for too long. J1772 specifies a method to use power-line signaling when the amps are set low enough and that could be used to specify low amp values using a custom Tesla protocol.

For the RS485 adapter, the goal is to find one as small and low power as possible. I used JBTek's because it lacks the two LEDs that waste power on the FTDI adapter, but JBtek is larger, so there is a tradeoff. If someone finds a smaller one that also lacks LEDs, please let us know. Otherwise, search Amazon, ebay, or whatever local site you prefer for "JBTek rs485" and that should work fine.
 
  • Informative
Reactions: pilotSteve
What MITE46 said implies the protocol IS bidirectional. The fact that each HPWC is connected to another HPWC by only two wires only implies they can't communicate at "full duplex" meaning they can't both send data at the same time. Instead, they communicate at "half duplex" meaning only one HPWC can be sending data at any particular time. They must simply agree on rules that govern which HPWC will send data at any particular time. If they both try to send data at the same time with only two wires, the data is corrupted.
Has anybody figured out what keeps two TWCs from transmitting at the same time on the single bi-directional bus? It looks like the slaves don't respond unless spoken to first. But this method might not work so well when querying for the IDs of the slaves.
 
Has anybody figured out what keeps two TWCs from transmitting at the same time on the single bi-directional bus? It looks like the slaves don't respond unless spoken to first. But this method might not work so well when querying for the IDs of the slaves.

Slaves transmit their IDs around every 10 seconds until a Master sends them a heartbeat message, at which point slaves only transmit immediately after a Master sends them a heartbeat message. With a maximum of 4 TWCs on the network there is plenty of silent time such that Master will eventually see every slave TWC and basically control the timing of when slave messages are sent. Master never "queries for slave IDs". The "linkready" messages that Master sends do not directly prompt any response from slaves. If anything, Master's linkready messages may be intended to detect when there is more than one Master on the network and flash an error code. Most of this is described in TWCManager's source-code comments.
 
  • Informative
Reactions: pilotSteve
git repository has been updated with a PDF document containing a detailed hardware and software installation guide.

FuzzyLogic's findings on new-firmware TWCs have been integrated into TWCManager.pl, though something he said makes me worry TWCManager can't stop a newer firmware TWC from charging. It's not clear to me if FuzzyLogic is actually using TWCManager or writing his own code.

Has anyone used TWCManager successfully on a TWC purchased in the last couple months?

I looked more carefully at FuzzyLogic's post and I think he's saying his real Master units send this message:
FB EB <Master ID> <Slave ID> 00 00 00 00 00 00 00 00 00

And slaves respond with:
FD EB <Slave ID> 00000038 00E6 00F1 00E8 00

where 00000038 (56) is the total kWh delivered to cars by this TWC since its construction.
00E6 (230) is voltage on phase A
00F1 (241) is voltage on phase B
00E8 (232) is voltage on phase C

I tried sending an FB EB message of the same format to my TWC in slave mode and it's simply ignored. I also tried reducing the number of 00 bytes at the end in case we need fewer bytes in North America with our two-phase power. So it seems the FB EB Master message and FD EB Slave response are features of newer firmware TWCs and do not work with older firmware.

I added notes on the above to TWCManager.pl

To test the FB EB message, I added a hidden feature to the web interface that sends an arbitrary message on the RS-485 network. Type a URL like this in your browser to send message FBEB7777032E000000000000000000 (message start/crc/end are added automatically):
Code:
http://(Pi Zero address)/index.php?submit=1&sendTWCMsg=FBEB7777032E000000000000000000

Could slaves respond to other message codes from Master?

So far, we know Master may send:
FB E0 heartbeat
FC E1 linkready1
FB E2 linkready2
FB EB request kWh and voltage
FC 1D four-hour idle

I'm guessing FC messages are like announcements that don't trigger responses from slaves.
FB XX messages expect an FD XX response from slaves.
XX values we've seen are 1D, E0, E1, E2, EB.

I'm wondering if a slave might respond to other codes like E3, E4, EC, etc. Perhaps such codes were used during development and will return interesting info. The problem is how many zeros to send after the codes. Most codes above want 7 bytes of zeros, but FB EB seems to want 9 bytes. Maybe some codes will require something other than zeros. Anyway, I might write a test program to send between 1 and say 20 zeros with message values from FB 00 to FB FF. I suspect I won't get much from my old firmware TWC but new firmware could be more interesting.
 
Last edited: