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

widodh

Model S 85 and 100D
Jan 23, 2011
6,856
2,812
Venlo, NL
Nov 14, 2015
212
281
Southern California
  • Like
Reactions: M_VdM

widodh

Model S 85 and 100D
Jan 23, 2011
6,856
2,812
Venlo, NL
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.
 

widodh

Model S 85 and 100D
Jan 23, 2011
6,856
2,812
Venlo, NL
@widodh : I think we all appreciate & applaud your effort ... but are you not creating unnecessary confusion by referring to HPWC (the old version/name) instead of TWC as it is commonly called nowadays ?
Fair point! Didn't think about that. Renaming it is easy, might do that indeed.
 
  • Like
Reactions: M_VdM

widodh

Model S 85 and 100D
Jan 23, 2011
6,856
2,812
Venlo, NL
Nov 14, 2015
212
281
Southern California
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:

Fuzzylogic

Roadster Sport 2.5 & S100D
Jun 23, 2009
361
95
The Netherlands
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?
 
Nov 14, 2015
212
281
Southern California
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

Fuzzylogic

Roadster Sport 2.5 & S100D
Jun 23, 2009
361
95
The Netherlands
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.
 

scaesare

Well-Known Member
Mar 14, 2013
8,577
15,162
NoVA
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

swaltner

Active Member
Oct 13, 2012
1,631
1,678
Kansas, USA
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.
 
Nov 14, 2015
212
281
Southern California
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

hcsharp

Active Member
Jun 7, 2011
3,420
1,479
Vermont
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.
 
Nov 14, 2015
212
281
Southern California
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
Nov 14, 2015
212
281
Southern California
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:

Products we're discussing on TMC...

About Us

Formed in 2006, Tesla Motors Club (TMC) was the first independent online Tesla community. Today it remains the largest and most dynamic community of Tesla enthusiasts. Learn more.

Do you value your experience at TMC? Consider becoming a Supporting Member of Tesla Motors Club. As a thank you for your contribution, you'll get nearly no ads in the Community and Groups sections. Additional perks are available depending on the level of contribution. Please visit the Account Upgrades page for more details.


SUPPORT TMC
Top