How comprehensively is this protocol understood?

[TurkeyMan]

I'm writing TWC software and using this repo as reference.
I've configured 2 TWC's, one master and one slave, and I'm sniffing the bus to watch the native communication, just to gain confidence that the protocol described here is complete and correct.

I'm noticing way more messages than this software described.
This software seems to understand master linkready 1 (FCE1), master linkready 2 (FBE2), slave linkready (FDE2), and master/slave heartbeat (FBE0, FDE0)...

I see the heartbeat messages flying back and forth, but I also see a whole bunch of other messages that aren't mentioned anywhere in this software.
Heartbeat messages come in pairs, and are ordered MASTER, SLAVE; ie, FBE0, FDE0

I have also recorded the pairs FBEB/FDEB, FBEC/FDEC, FBED/FDED, FBEE/FDEE, FBEF/FDEF, FBF1/FDF1, which seem to have a different pattern; they always transmit in sequences of 3 messages in the order SLAVE, MASTER, SLAVE.

There's also a reliable sequence of events:

FDEB, FBEB, FDEB
FDEC, FBEC, FDEC
FDEE, FBEE, FDEE
FDEF, FBEF, FDEF
FDF1, FBF1, FDF1
FDED, FBED, FDED
repeat...

Did anyone that's participated in the reverse engineering of this protocol notice all these extra messages?

Also, one random observation... why would the checksum skip the first byte?! That's super weird... if there's an error in the first byte, the checksum won't catch it!

[TurkeyMan]

Sorry, that was wrong; the three messages are MASTER, MASTER, SLAVE, but it confused me because the master sends FDxx, FBxx, then slave responds FDxx. Normally master sends FBxx messages and slave sends FDxx messages, so it surprised me when the master sends it the first time.
Also, the first FDxx message the master sends is 4 bytes longer than all the others, except FDEC, that one's the normal length.
Anyway... weird!

[TurkeyMan]

Does anyone know how the TWC avoids collisions on the bus? Both devices are sending messages kinda randomly.

I notice the startup process doesn't necessarily seem to be the same as this software either... I notice that the slave sends slave linkready every 6 seconds when they're not connected, and the master can receive that one message before it sends a single master link ready of any kind, and it immediately starts communicating as if they're friends...

Maybe this is an old project, but if any of the people that reverse engineered this are still around, I'd love to chat!

[ChutneyMary]

You might already be familiar with this thread, but it describes some of the progress of reverse engineering the protocol -

https://teslamotorsclub.com/tmc/threads/tesla-wall-connector-load-sharing-protocol.72830/

@WinterDragoness is the main person responsible, but I think they moved on. Good luck!

[TurkeyMan]

I worked out the messages (VIN, Charver Serial, charge details), and then also found them discussed somewhere deep inside the long thread... (still working through every page in the very long thread!).

[ChutneyMary]

There's a fork of dracovention's TWCManager that is still being actively developed -

https://github.com/ngardiner/TWCManager?tab=readme-ov-file

Amongst other things, the new fork uses VIN to control which vehicles can and cannot be charged. The main limitation with the RS485 interface is that Start and Stop Charge can only be done via the Tesla API. Charge rate can be manipulated via TWCManager/RS485.

If you've played with the new Tesla API, you'll know what a headache the authentication routine is.

[TurkeyMan]

Oh yeah. I'm desperately trying to find a way that doesn't rely on the web api... it doesn't even work where I live because it depends on mobile phone radios, and where I live there's no mobile phone service.

[TurkeyMan]

I wonder if custom firmware is an option...

[ChutneyMary]

You'll be pleased to know that the Tesla Bluetooth API works well. It doesn't need any internet connectivity.

The link below describes all the commands that are supported -
https://shankar-k.medium.com/tesla-developer-api-guide-ble-key-pair-auth-and-vehicle-commands-part-3-485e4a357e7d

And here's the code I've been using -
https://github.com/Jeoffreybauvin/tesla-http-api-over-ble

I've used the development above to successfully start/stop charging and change the charge rate. There's two components to this; the 'vehicle-command' docker image and the 'http-over-ble-api' docker image.

I can send commands to the car via bluetooth by typing at the command-line interface of the 'vehicle-command' image. I should be able to send http commands to the 'vehicle-command' image using the homemade 'http-over-ble-api' image. I can't yet successfully install the 'http-over-ble-api' image.

These are running on a Raspberry Pi Zero W installed within the Tesla Wall Charger (powered off a 14VDC rail on the LED light strip with a 5VDC converter).

Here's another Bluetooth development I haven't had a chance to experiment with -

https://github.com/wimaha/TeslaBleHttpProxy