Tesla Wall Connector load sharing protocol

[sparkypete]

@widodh - what state is the Python script in? Is the version on GitHub working?

 

[widodh]

@widodh - what state is the Python script in? Is the version on GitHub working?

Pretty bad. I've been caught up in way to many projects recently. I did a Electric Scooter conversion ( Building a Lithium battery for my electric scooter – Widodh ) which sucked up all my time.

The HPWC is still blinking and has a Pi connected to it. I just need to get working on the code again.

 

[sparkypete]

I just need to get working on the code again.

Thanks for the quick update. Sounds cool. If I find time to play with it I'll update you.

I'm looking to develop code so the TWC appears as a discoverable device via SSDP. The plan is to then develop a hub app that finds devices in the home like WEMO switches etc and then allow configuration of priorities via a cloud app for smart energy usage.

 

[widodh]

Thanks for the quick update. Sounds cool. If I find time to play with it I'll update you.

I'm looking to develop code so the TWC appears as a discoverable device via SSDP. The plan is to then develop a hub app that finds devices in the home like WEMO switches etc and then allow configuration of priorities via a cloud app for smart energy usage.

That sounds very interesting! The Python code could mimic a SSDP server once it talks with the TWC.

The basics work for me now, I see the TWC sending a slave message, I just need to respond to it.

 

[gingerbeer]

Hi everyone. I bought my first Raspberry Pi (W Zero) to give this awesome project a try.

@CDragon - is there an update to the TWCManager.pl file on Github? After lots of testing it looks like I'm getting the same issue as others where I have errors because the message is 18 bytes long, whereas the TWCManager file is written around a 16byte message. This is identified in January and February 2018 messages in this thread, but github's last version of the perl script is in December.



Just in case mine is a different issue, logging at debug level 10, it starts like this.

TWC Manager starting as fake Master with id 7777 and sign 77

19:59:55: Send master linkready1
Tx@19:59:55: c0 fc e1 77 77 77 00 00 00 00 00 00 00 00 46 c0 fe
19:59:55: Send master linkready1
Tx@19:59:55: c0 fc e1 77 77 77 00 00 00 00 00 00 00 00 46 c0 fe
19:59:55: Send master linkready1
Tx@19:59:55: c0 fc e1 77 77 77 00 00 00 00 00 00 00 00 46 c0 fe
19:59:55: Send master linkready1
Tx@19:59:55: c0 fc e1 77 77 77 00 00 00 00 00 00 00 00 46 c0 fe
19:59:55: Send master linkready1
Tx@19:59:55: c0 fc e1 77 77 77 00 00 00 00 00 00 00 00 46 c0 fe
19:59:55: Send master linkready2
Tx@19:59:55: c0 fb e2 77 77 77 00 00 00 00 00 00 00 00 47 c0 fe
19:59:55: Send master linkready2
Tx@19:59:55: c0 fb e2 77 77 77 00 00 00 00 00 00 00 00 47 c0 fe
19:59:55: Send master linkready2
Tx@19:59:55: c0 fb e2 77 77 77 00 00 00 00 00 00 00 00 47 c0 fe
19:59:55: Send master linkready2
Tx@19:59:55: c0 fb e2 77 77 77 00 00 00 00 00 00 00 00 47 c0 fe
19:59:55: Send master linkready2
Tx@19:59:55: c0 fb e2 77 77 77 00 00 00 00 00 00 00 00 47 c0 fe
Rx@19:59:56: c0 fd e2 26 85 9d 0c 80 00 00 00 00 00 00 00 00 b6 c0
ERROR: Ignoring message of unexpected length 18: c0 fd e2 26 85 9d 0c 80 00 00 00 00 00 00 00 00 b6 c0
Rx@19:59:56: c0 fd e2 26 85 9d 0c 80 00 00 00 00 00 00 00 00 b6 c0
ERROR: Ignoring message of unexpected length 18: c0 fd e2 26 85 9d 0c 80 00 00 00 00 00 00 00 00 b6 c0
Rx@19:59:56: c0 fd e2 26 85 9d 0c 80 00 00 00 00 00 00 00 00 b6 c0
ERROR: Ignoring message of unexpected length 18: c0 fd e2 26 85 9d 0c 80 00 00 00 00 00 00 00 00 b6 c0
Rx@19:59:58: c0 fd e2 26 85 9d 0c 80 00 00 00 00 00 00 00 00 b6 c0
ERROR: Ignoring message of unexpected length 18: c0 fd e2 26 85 9d 0c 80 00 00 00 00 00 00 00 00 b6 c0​

The raw data looks like this (taken after it has been on for a while). (logged with "od -t x1 < /dev/ttyUSB0")

pi@TWCManager:~/TWC $ od -t x1 < /dev/ttyUSB0
0000000 00 fc c0 fd e2 26 85 9d 0c 80 00 00 00 00 00 00
0000020 00 00 b6 c0 fc c0 fd e2 26 85 9d 0c 80 00 00 00
0000040 00 00 00 00 00 b6 c0 fc c0 fd e2 26 85 9d 0c 80
0000060 00 00 00 00 00 00 00 00 b6 c0 fc c0 fd e2 26 85
0000100 9d 0c 80 00 00 00 00 00 00 00 00 b6 c0 fc c0 fd
0000120 e2 26 85 9d 0c 80 00 00 00 00 00 00 00 00 b6 c0
0000140 fc c0 fd e2 26 85 9d 0c 80 00 00 00 00 00 00 00
0000160 00 b6 c0 fc c0 fd e2 26 85 9d 0c 80 00 00 00 00
0000200 00 00 00 00 b6 c0 fc c0 fd e2 26 85 9d 0c 80 00
0000220 00 00 00 00 00 00 00 b6 c0 fc c0 fd e2 26 85 9d
0000240 0c 80 00 00 00 00 00 00 00 00 b6 c0 fc c0 fd e2
0000260 26 85 9d 0c 80 00 00 00 00 00 00 00 00 b6 c0 fc
0000300 c0 fd e2 26 85 9d 0c 80 00 00 00 00 00 00 00 00
0000320 b6 c0 fc c0 fd e2 26 85 9d 0c 80 00 00 00 00 00
0000340 00 00 00 b6 c0 fc c0 fd e2 26 85 9d 0c 80 00 00​

I have tried 2 different usb-485 adaptors - one with and one without the 120ohm and 680ohm resistors. Cable is short and shielded - both give the same result.

 

[vloschiavo]

Hi everyone. I bought my first Raspberry Pi (W Zero) to give this awesome project a try.

@CDragon - is there an update to the TWCManager.pl file on Github? After lots of testing it looks like I'm getting the same issue as others where I have errors because the message is 18 bytes long, whereas the TWCManager file is written around a 16byte message. This is identified in January and February 2018 messages in this thread, but github's last version of the perl script is in December.



Just in case mine is a different issue, logging at debug level 10, it starts like this.

TWC Manager starting as fake Master with id 7777 and sign 77

19:59:55: Send master linkready1
Tx@19:59:55: c0 fc e1 77 77 77 00 00 00 00 00 00 00 00 46 c0 fe
19:59:55: Send master linkready1
Tx@19:59:55: c0 fc e1 77 77 77 00 00 00 00 00 00 00 00 46 c0 fe
19:59:55: Send master linkready1
Tx@19:59:55: c0 fc e1 77 77 77 00 00 00 00 00 00 00 00 46 c0 fe
19:59:55: Send master linkready1
Tx@19:59:55: c0 fc e1 77 77 77 00 00 00 00 00 00 00 00 46 c0 fe
19:59:55: Send master linkready1
Tx@19:59:55: c0 fc e1 77 77 77 00 00 00 00 00 00 00 00 46 c0 fe
19:59:55: Send master linkready2
Tx@19:59:55: c0 fb e2 77 77 77 00 00 00 00 00 00 00 00 47 c0 fe
19:59:55: Send master linkready2
Tx@19:59:55: c0 fb e2 77 77 77 00 00 00 00 00 00 00 00 47 c0 fe
19:59:55: Send master linkready2
Tx@19:59:55: c0 fb e2 77 77 77 00 00 00 00 00 00 00 00 47 c0 fe
19:59:55: Send master linkready2
Tx@19:59:55: c0 fb e2 77 77 77 00 00 00 00 00 00 00 00 47 c0 fe
19:59:55: Send master linkready2
Tx@19:59:55: c0 fb e2 77 77 77 00 00 00 00 00 00 00 00 47 c0 fe
Rx@19:59:56: c0 fd e2 26 85 9d 0c 80 00 00 00 00 00 00 00 00 b6 c0
ERROR: Ignoring message of unexpected length 18: c0 fd e2 26 85 9d 0c 80 00 00 00 00 00 00 00 00 b6 c0
Rx@19:59:56: c0 fd e2 26 85 9d 0c 80 00 00 00 00 00 00 00 00 b6 c0
ERROR: Ignoring message of unexpected length 18: c0 fd e2 26 85 9d 0c 80 00 00 00 00 00 00 00 00 b6 c0
Rx@19:59:56: c0 fd e2 26 85 9d 0c 80 00 00 00 00 00 00 00 00 b6 c0
ERROR: Ignoring message of unexpected length 18: c0 fd e2 26 85 9d 0c 80 00 00 00 00 00 00 00 00 b6 c0
Rx@19:59:58: c0 fd e2 26 85 9d 0c 80 00 00 00 00 00 00 00 00 b6 c0
ERROR: Ignoring message of unexpected length 18: c0 fd e2 26 85 9d 0c 80 00 00 00 00 00 00 00 00 b6 c0​

The raw data looks like this (taken after it has been on for a while). (logged with "od -t x1 < /dev/ttyUSB0")

pi@TWCManager:~/TWC $ od -t x1 < /dev/ttyUSB0
0000000 00 fc c0 fd e2 26 85 9d 0c 80 00 00 00 00 00 00
0000020 00 00 b6 c0 fc c0 fd e2 26 85 9d 0c 80 00 00 00
0000040 00 00 00 00 00 b6 c0 fc c0 fd e2 26 85 9d 0c 80
0000060 00 00 00 00 00 00 00 00 b6 c0 fc c0 fd e2 26 85
0000100 9d 0c 80 00 00 00 00 00 00 00 00 b6 c0 fc c0 fd
0000120 e2 26 85 9d 0c 80 00 00 00 00 00 00 00 00 b6 c0
0000140 fc c0 fd e2 26 85 9d 0c 80 00 00 00 00 00 00 00
0000160 00 b6 c0 fc c0 fd e2 26 85 9d 0c 80 00 00 00 00
0000200 00 00 00 00 b6 c0 fc c0 fd e2 26 85 9d 0c 80 00
0000220 00 00 00 00 00 00 00 b6 c0 fc c0 fd e2 26 85 9d
0000240 0c 80 00 00 00 00 00 00 00 00 b6 c0 fc c0 fd e2
0000260 26 85 9d 0c 80 00 00 00 00 00 00 00 00 b6 c0 fc
0000300 c0 fd e2 26 85 9d 0c 80 00 00 00 00 00 00 00 00
0000320 b6 c0 fc c0 fd e2 26 85 9d 0c 80 00 00 00 00 00
0000340 00 00 00 b6 c0 fc c0 fd e2 26 85 9d 0c 80 00 00​

I have tried 2 different usb-485 adaptors - one with and one without the 120ohm and 680ohm resistors. Cable is short and shielded - both give the same result.

I'm getting similar results. I'm in the US and have just purchased (March 2018) a TWC, which presumably has the latest firmware. The messages I'm getting on the RS-485 are below - additionally the RPi master never syncs with the slave TWC.

20:29:52: Send master linkready2
Tx@20:29:52: c0 fb e2 77 77 77 00 00 00 00 00 00 00 00 47 c0 fe
Rx@20:29:52: c0 fd e2 74 97 60 1f 40 00 00 00 00 00 00 00 00 ac c0
ERROR: Ignoring message of unexpected length 18: c0 fd e2 74 97 60 1f 40 00 00 00 00 00 00 00 00 ac c0
Ignoring byte fc between messages.

 

[WinterDragoness]

I haven't updated the git code since December because I still haven't found a way to cleanly stop the car from charging in newer TWC models. Ceasing communication with the TWC will stop charging but randomly put the car in an error state where it won't start charging again until you re-plug the connector, as I've described in previous posts. I don't want to put up new code that will randomly cause cars to stop charging and leave people stranded.

Unfortunately I don't have an ETA on when or if I will find a solution.

 

[vloschiavo]

I haven't updated the git code since December because I still haven't found a way to cleanly stop the car from charging in newer TWC models. Ceasing communication with the TWC will stop charging but randomly put the car in an error state where it won't start charging again until you re-plug the connector, as I've described in previous posts. I don't want to put up new code that will randomly cause cars to stop charging and leave people stranded.

Unfortunately I don't have an ETA on when or if I will find a solution.

Thanks CDragon. It would be interesting to see the current code for the v2 protocol, I'd like to stop charging via a call to the Tesla Vehicle API instead of manipulating the wall connector.

 

[S-Men]

I love this great project and I would like to thank all of you and especially CDragon for the good job.

unfortunately my TWC has some communication issues with TWCManager. I get most the time UNKNOWN MESSAGE FROM SLAVE

c0 fc e1 00 85 12 00 00 00 00 00 00 00 00 78 c0​

or

c0 fb e2 00 85 12 00 00 00 00 00 00 00 00 79 c0​

also sometimes message of unexpected length

c0 fe 80 fc e1 00 85 12 00 00 00 00 00 00 00 00 78 c0​

After a communication attempt, TWC goes into error mode (flashing red LED). After Reset of TWC It starts operating normal until I send next message to it.
The TWC is from mid-2016, so not the new model. EU version with max 22kW/3*32A installation.
Would be great to hear if someone else had similar issues or any idea how to solve it.

 

[WinterDragoness]

unfortunately my TWC has some communication issues with TWCManager. I get most the time UNKNOWN MESSAGE FROM SLAVE

c0 fc e1 00 85 12 00 00 00 00 00 00 00 00 78 c0​

or

c0 fb e2 00 85 12 00 00 00 00 00 00 00 00 79 c0​

​

Those two messages are linkready1 and linkready2 from a master TWC. This means you have a TWC on the network set to Master mode. You need to rotate the rotary switch inside the TWC to point at position F on the dial after powering down the TWC. Position F sets the TWC to slave mode such that TWCManager will control it. Search the installation PDF that comes with TWCManager for the phrase "Use a 3mm-wide flathead screwdriver to rotate the arrow in the rotary switch till it points at the F as in the picture above." to see a picture.

Thanks CDragon. It would be interesting to see the current code for the v2 protocol, I'd like to stop charging via a call to the Tesla Vehicle API instead of manipulating the wall connector.

My current code is a mess of test cases but I've attached a version to this message that should have minimal changes to support Protocol 2. It does not cease communication with TWC when charging should be stopped, so it should not be able to stop a protocol 2 TWC from charging. It is not well tested.

 

[S-Men]

Those two messages are linkready1 and linkready2 from a master TWC. This means you have a TWC on the network set to Master mode. You need to rotate the rotary switch inside the TWC to point at position F on the dial after powering down the TWC.

Thanks a lot. I got same hint already from a good soul and that helped a lot. Soemtimes I do not see the wood for the tree...

 

[vloschiavo]

My current code is a mess of test cases but I've attached a version to this message ....

Thanks Chris!

 

[S-Men]

I could not really beleave it, but it's running and updating power like expexted.
Just charging start seams to be a little bumpy. Car and App shows e.g. 16A available but also shows "check charger". After some time power jumps to 6A and charging starts, than back to 16A and charging stops again. But after some cycles car and charger seams to sync to the coerrct value (e.g. 13A) and from than also power changes works great.
I know that it's maybe not the intendet way to use, but I switch power externaly via an OpenHab2 rule where my power meters are connected. I use "&nonScheduledAmpsMax=XX&submit=Save" parameter for that. So for a future realease it would maybe an idea to have an additional URL parameter to switch power externaly without saving the settings always to the file. Just to rest the SD card a little.
So again: a great project and i was looking forwart to such a funcionality since I installed the TWC in 2016. Now I just have to finalize a propper wiriing etc. and than I just enjoy charging with my own renewable energy....

 

[vloschiavo]

So for a future realease it would maybe an idea to have an additional URL parameter to switch power externaly without saving the settings always to the file. Just to rest the SD card a little.

I use TMPFS on my Raspberry Pis to do exactly that. Mount a ram drive and use that to save the write cycles.

 

[S-Men]

I use TMPFS on my Raspberry Pis to do exactly that

Good idea, I think i will do the same, Thanks!

 

[WinterDragoness]

I use TMPFS on my Raspberry Pis to do exactly that. Mount a ram drive and use that to save the write cycles.

You could also just search for sub save_settings and add return; at the top.

So... Despite being as careful as possible, I've broken another TWC.

I spent weeks running automated tests that tried sending master heartbeat state 01, and 03 to 0B with amp values 0 to FFFF in increments of 1 every 5 seconds and that never stops a TWC from charging.

Having no other choice, I had to try undocumented messages again. When I was trying undoc messages last time, I ran through all message commands from 0000 to FFFF two or three times without causing a problem, so I figured it must be safe to send lower command values followed by higher values. When I crashed the first TWC I was sending just the commands I thought might produce interesting results, which meant sending higher followed by lower in some cases. So I avoided doing that with the second TWC. If I needed to send a lower value, I power cycled the TWC.

I also thought maybe I broke the first by leaving it plugged into the car while sending commands, so this time I had it plugged into a fake car device that wouldn't send it anything weird or try to update the TWC's firmware or whatever else the car might do.

Finally, I avoided sending any commands that I knew could crash the TWC or cause it to pause as if waiting for more commands.

I set my code to zero pad commands shorter than the normal message length for protocol 2 so I wouldn't risk causing a buffer underflow or overflow in the TWC.

Despite all those precautions, I broke the second TWC on the first day with the following series of commands:

• // TWC was power cycled
• FB1A00 // Returns model num. Actually sent FB 1A 00 00 00 00 00 00 00 00 00 00 00 00 00 <CRC>
  • FD 1A 45 56 57 54 53 38 30 48 4C FF 00 AE // Response from TWC
• FC1A00 // Maybe returns 01 for slave mode, 00 for Master.
  • FD 1A 01 00 00 00 00 00 00 00 00 00 00 1B
• FC1B
• FB1B // Returns firmware version? Date of manufacture?
  • FD 1B 04 04 0D 00 00 00 00 00 00 00 00 // Returned by second broken TWC
    
  • FD 1B 04 03 0B 00 00 00 00 00 00 00 00 // Returned by first broken TWC
• FB1C // Returns amps used by TWC
  • FD 1C 00 00 00 00 00 00 00 00 00 00 00 1C
• FC1C // Commands below return nothing and probably have no meaning to the TWC.
  
• FC1C77779393
• FC1C93937777
• FC1D
• FC1E
• FC1E77779393
• FC1E93937777
• FB1E93937777
• FB1E77779393
• FB1E
• FB1C77779393 // Amps used by TWC
  • FD 1C 00 00 00 00 00 00 00 00 00 00 00 1C
• FB1C93937777 // Amps used by TWC
  • FD 1C 00 00 00 00 00 00 00 00 00 00 00 1C
• FBE893937777 // No idea but first TWC returned same value.
  • FD E8 00 01 00 00 00 00 00 00 00 00 00 E9
• // At this point I was ready to test values FB1E to FBA0 and FC1E to FCA0 but I needed to power cycle the TWC to try lower values. I set up test code to try those values sequentially, but I needed to test my code, so I set it to try FBE1 to FBE2 and FCE1 to FCE2. This breaks my rule of trying lower value commands without power cycling, but FCE1 and FBE2 are Master linkready1 and Master linkready2 which are always sent normally so I figured they couldn't break anything. Technically, FBE1 and FCE2 are meaningless/undocumented but being variations on linkready1/2 I figured they couldn't hurt. Probably not a safe assumption in retrospect.
  
• FB E1 00 00 00 00 00 00 00 00 00 00 00 00 00
• FB E1 00 00 00 00 00 00 00 00 00 00 00 00 00
• FB E1 77 77 93 93 00 00 00 00 00 00 00 00 00 // Test code also tries different data values, 77 77 93 93 instead of all 00 in this case.
  
• FB E1 93 93 77 77 00 00 00 00 00 00 00 00 00
• FC E1 00 00 00 00 00 00 00 00 00 00 00 00 00
• FC E1 77 77 93 93 00 00 00 00 00 00 00 00 00
• FC E1 93 93 77 77 00 00 00 00 00 00 00 00 00 // Slave changes ID in response to this message because it thinks we're saying we have a Master with ID 9393 on the network which conflicts with the slave's 9393 ID. Slave chooses new ID 09F5 and reports it is ready to link.
• FB E2 00 00 00 00 00 00 00 00 00 00 00 00 00
• FB E2 77 77 93 93 00 00 00 00 00 00 00 00 00
• FB E2 93 93 77 77 00 00 00 00 00 00 00 00 00
• FC E2 00 00 00 00 00 00 00 00 00 00 00 00 00
• FC E2 77 77 93 93 00 00 00 00 00 00 00 00 00
• FC E2 93 93 77 77 00 00 00 00 00 00 00 00 00

At this point, nothing seems wrong. TWC is still streaming LEDs, charging fake car. TWC ID has changed but that's expected behavior and was only temporary until the next power cycle. I shut down TWCManager in preparation for power cycling TWC. Fake car stops charging as expected. Unplug fake car. TWC blinks red indicating fake master has disappeared, also expected since I closed TWCManager.

Turn off power ~10 sec, turn on power, and TWC (I'll call it TWC 2) is in a similar broken state to previous broken TWC (I'll call it TWC 1).

There are a few differences:

1. TWC 1 broke after sending a command that seemed to crash it and make it reboot. TWC 2 never crashed and behaved normally until powered off and on.
   
2. The particular lights that blink during boot in TWC 2 are identical to a normal working TWC until it shows both top and bottom green (this is normal for a TWC in Master mode, except the rotary for this is set to Slave mode) instead of just bottom green (indicating Slave mode). TWC 1 showed a slightly abnormal sequence of lights before showing the same odd top and bottom green. I'm wondering if the particular lights that illuminate indicate the health of various hardware components.
3. All LEDs turn green and middle LED turns orange but is very hard to see with the other LEDs on. In a working TWC, only top LED would be green at this point and no orange LED. TWC 1 reboots itself every 30 seconds after showing all LEDs green. TWC 2 stays on indefinitely.
4. Both TWCs act like masters and send Master Linkready1. TWC 2 never sends Linkready2, but TWC 1 does.
5. TWC 1 responds to commands as if it were a master. TWC 2 does not respond to any command that I've tried. It's like its RS-485 interface ignores all incoming messages.
6. Changing rotary switch position of either TWC does not change its behavior. TWC 1 responds to FC E7 message by returning rotary switch position which means it does know what position the switch is in. TWC 2 does not respond to FC E7 (but it used to before it broke).

Left TWC 2 powered off overnight. Same problem in morning. Holding reset button makes it reboot into same state. Plugged TWC 2 into car with rotary switch set to 8 after removing Raspberry Pi. No change in LEDs. Car says 'check charger power'. I'm going to leave it plugged in 24+ hours on the off chance the car will send it a command to fix it, but doing that with TWC 1 did not help so I don't expect success.

The fact I can't get TWC 2 to respond to any commands makes me think there's nothing more I can do. I guess I should try sending it commands 0000 to FFFF in case it's in a debugging mode that's waiting for some particular command to get it out of the mode. I may take it in to Tesla and just tell them it broke for no apparent reason because it almost seems like that's what happened. At the very least, they've designed their firmware to be possible to break the TWC on receipt of certain RS-485 commands which really must be considered a fatal flaw covered by warranty because even if I hadn't purposely sent the commands, RS-485 is not perfect and garbage commands can be sent to a TWC during normal operation, especially if water gets into the wires that link TWCs. There should not be a command that breaks it.

 

[hcsharp]

The fact I can't get TWC 2 to respond to any commands makes me think there's nothing more I can do. I guess I should try sending it commands 0000 to FFFF in case it's in a debugging mode that's waiting for some particular command to get it out of the mode.

My first reaction to this idea was "you've learned your lesson about sending random commands - don't do it again!" But I realized you have nothing to lose at this point. It's not responding to any messages.

 

[WinterDragoness]

My first reaction to this idea was "you've learned your lesson about sending random commands - don't do it again!" But I realized you have nothing to lose at this point. It's not responding to any messages.

I learned my lesson when I broke TWC 1. I only felt obligated to try it on TWC 2 after I'd exhausted all other options and because someone had donated to me two TWCs specifically to try to figure stuff like this out. Now that I'm down to one working TWC again, I'm afraid I can't risk doing anything else with the remaining good one, unless I can fix TWC 2 somehow, which I don't have much hope for.

 

[WinterDragoness]

My wife said something today that made me remember that Maxem has devices that act as fake TWC masters to control charging. Has anyone found that a Maxem device can stop a 2018 Protocol 2 TWC from charging? Maxem charges a monthly fee for their units so they might go after anyone that tried to log their methods of TWC control and spread the info, but I'd still like to know if it's even possible or if Protocol 2 TWCs removed the ability to stop charging.

vloschiavo pointed out that TWCManagerProtocol2.pl won't change the car's charging amps once charging has started at a particular amp value. This is because protocol 2 uses state 09 instead of state 05 to set an absolute amp value. Protocol 2 does use state 05 as well, but only to tell a car to start charging at an amp value, not to change the amp value once it's started. Using 09 in both cases seems to work, so change this line in TWCManagerProtocol2.pl:

$self->{masterHeartbeatData} = [0x05,

to this:

$self->{masterHeartbeatData} = [0x09,

I've also attached a file with the fix.

TWC 2 remains broken but I did find that if I reset it and don't send it Master linkready messages, it will respond to messages. It will actually behave like a normal Master TWC if I have TWCManager play fake slave, except it constantly sends state 02 05 as its master heartbeat. State 02 is an error state, and I assume 05 is an error code. It won't charge a car. Along with the error state, all LEDs on the front are lit green, but there is also a faint orange LED lit in the middle of the LED string that is hard to see behind the green LEDs. The orange makes me think error or non-standard state. TWC 1 has the same orange LED.

If I send the FCEA command it seems to be equivalent to holding red reset button for 3-4 seconds (not long enough for a full reset). The front LEDs turn off, just the top remaining green, the orange replaced by an odd greenish yellow, and master heartbeat changes to 02 01. I've found no purpose to doing this and no additional responses or interesting features once in this alternate state, but it's interesting. TWC 1 does something similar.

Since TWC 2's behavior is very similar to TWC 1, I don't think it's a hardware problem. My best guess is it's a factory or debug mode. Or just an unstable, bugged state caused by erasing something important in NVRAM. The fact I can't get FB1A to return the model number in either TWC makes me think one of the commands erased the area containing the model number, and without the model the firmware may just enter a funky state. I suspect once the model is erased, the TWC will behave normally until you next reset or power cycle, and then it's in this broken state. If you call FB1A in the working state and it finds no model number, I think it may immediately reset into the broken state, which is what happened with TWC 1. TWC 2 entered broken state after I power cycled it.

It could be that they issue a 'reset' command at the factory to erase things and then tell it what model it is, date of manufacture, and whatever else. I've tried all the obvious things I can think of to put the model number back. Since the fix isn't obvious, without documentation I think it's a hopeless cause. I have nothing to go on. Repeating the commands I think could have broken it doesn't help. There are six commands that I sent to both broken TWCs so maybe one of them is the culprit: FB1A, FC1A, FC1B, FB1B, FC1C, FCE2. Sending them with different parameters doesn't help. I haven't yet tried them with _every_ parameter, but I will eventually.

The problem with this theory is that I issued commands 0000 to FFFF sequentially to TWC 1, each command sent 15+ times so it couldn't have missed any, and it didn't enter this broken state. That implies there isn't a single command that reliably enters broken state (maybe there's just bad timing involved?), or that I did enter broken state but a later command exited the state. No amount of sending sequential commands after getting in broken state has gotten me out of it. Maybe once you're 'booted' in it, there's no simple escape? I really don't know. It could also be that you can only enter broken state by issuing commands while it's charging a car (even a fake car). Both TWCs were charging when they broke. TWC 1 was not charging when I sent sequential messages originally.

At this point, the only likely solution would be to de-solder the NVRAM from a working TWC, copy it, and burn it to a broken TWC. I don't have the tools or experience for that or want to risk breaking a working TWC, but maybe some reader will want to take on getting an NVRAM image. If someone gets a working NVRAM image I'd be willing to try to burn it to my broken TWC.

 

[vloschiavo]

vloschiavo pointed out that TWCManagerProtocol2.pl won't change the car's charging amps once charging has started at a particular amp value. This is because protocol 2 uses state 09 instead of state 05 to set an absolute amp value. Protocol 2 does use state 05 as well, but only to tell a car to start charging at an amp value, not to change the amp value once it's started. Using 09 in both cases seems to work, so change this line in TWCManagerProtocol2.pl:

$self->{masterHeartbeatData} = [0x05,

to this:

$self->{masterHeartbeatData} = [0x09,

Thanks Chris! That fixed it!