Tesla Wall Connector load sharing protocol

[brkaus]

On a quick search, I didn't find it, but there was a thread here where someone here built/sold key fobs that could open the charging door. The idea was that they could be used for people using J1772 chargers to get some of the convenience of the Tesla EVSEs. Initial designs transmitted with a little too much power and could open every charge port within a rather large area.

I think this thread -

Get J1772 adapter to pop charge port door

 

[WinterDragoness]

I'm highly interested in this method of controlling my gen 2 HWPC to scale charge rate along with solar array output. I'm putting in an order for the RS485 raspi board so I can do some logging though I doubt I'll be able to figure out anything without two HPWCs. Hopefully widodh will get some useful logs unless someone in Southern California wants to loan me a second HPWC while they wait on a Model 3 order. Another option would be to purchase a second HPWC for testing, then sell it as near-new on ebay/TMC for a small loss. Having only one EV to plug in also limits the kind of data I can get, though hopefully that doesn't matter. There is a guy down the street with a Tesla maybe I could bug, though I don't know him too well.

 

[WinterDragoness]

Shall we all buy the same USB cable so we can share code/drivers? This one has the highest reviews: https://smile.amazon.com/EZSync-RS485-USB-RS485-WE-compatible-EZSync010/dp/B010KJSCR8

ctr said earlier he was operating in "4-wire" mode, but it looks like the HPWC has 2 wires in and 2 wires out. I assume that means 2 wires to connect to parent HPWC and 2 to connect to child HPWC in a chain, so what is 4-wire mode? Is he somehow monitoring traffic on all 4 terminals to see what it's sending to parent and child? If so, I don't think the USB cable will support that.

 

[brkaus]

This looks like a tease from someone regarding HPWC...

Free Destination Charging: 50x L2 80A Stations @ Caltech, Pasadena, CA

 

[WinterDragoness]

The manual shows multiple HPWCs are wired together like this:

That implies the master rotary switch sets the max power of all units in the chain and the power output of each slave is controlled by the master.
I'm guessing that each OUT to IN connection is its own bus, so a signal on the two IN wires of a particular unit won't be seen on the OUT wires unless the unit chooses to copy the message because it was intended for a unit further down the chain. If that's true, then when you wire two units together, they can exchange a simple handshake saying "I'm here". The rotary switches control who is master and slave so there's no need to negotiate that via the protocol.

With only one HPWC to work with, this process may work:

1. Set HPWC to F, see what it broadcasts on IN pins when turned on. Save broadcast.
   
2. Set HPWC to non-F and send saved broadcast to OUT pins. Save any response it makes.
3. Set HPWC to F and send saved response, save any new response.
4. Repeat until initial handshake is understood.
5. Set HPWC to non-F, emulate handshake on OUT pins so it thinks a child HPWC is connected.
6. Charge car and see what is broadcast on OUT pins telling the fake child HPWC how much power remains.
7. Alter car charge rate via car itself and see if HPWC broadcasts updates with different values.

During this process of reverse engineering the protocol, it would be helpful to have two USB cables, one connected to IN and one to OUT. It would be easier to have two HPWCs but I think the above is reasonably likely to work.

MITE46 confirmed that "raspberry pi + USB RS485 adapter works well for residential single HPWC control" though I hope he might share some details of the protocol!

 

[WinterDragoness]

I'm ordering two USB RS485 cables from Digikey. I think it's the same as the Amazon listing but I'd rather not support Amazon and Digikey links to tons of support documents for installing drivers in all operating systems and even has one on accessing the cable through Perl.

 

[MITE46]

Get this USB RS485 adapter...https://www.amazon.com/JBtek-Conver...UTF8&qid=1509653243&sr=8-3&keywords=usb+rs485

if you only have one HPWC, set it to master say position 6...connect the RS485 usb to the output ports. listen to the packets, write them down.

then change HPWC to slave position F....connect the rs485 usb to the input ports. play back. That should get you started, the rest should be easy to figure out =)

 

[Kasper]

If the protocol is not bidirectional, and the connections from master to slave are labelled out->in, does that imply that the master will provide as much power as is required for the connected vehicle, and simply tell the slave what amount of available power is left over?

 

[WinterDragoness]

If the protocol is not bidirectional, and the connections from master to slave are labelled out->in, does that imply that the master will provide as much power as is required for the connected vehicle, and simply tell the slave what amount of available power is left over?

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.

RS-485 - Wikipedia explains the basics of the RS-485 wires. Basically, when the D+ wire has higher voltage than D-, a binary 1 is being transmitted, otherwise a binary 0 is being transmitted. Which HPWC is doing the transmitting is defined by the protocol, not by the RS-485 standard.

I'm guessing each HPWC in the chain tells the Master when they have a car plugged in, how much energy the car is requesting, and anything else they know. The Master knows the max power it can distribute to all cars (defined by position of the rotary switch) and Master tells each slave how much power it can draw from the power source shared by all HPWCs in the chain.

My RS485 cables aren't due to arrive till Mon so I won't be able to do any experiments till at least then. Although it just occurred to me that I have an extra Teensy USB board which I believe supports RS485 with the right firmware and pins connected... We'll see how adventurous I feel.

 

[scaesare]

On a quick search, I didn't find it, but there was a thread here where someone here built/sold key fobs that could open the charging door. The idea was that they could be used for people using J1772 chargers to get some of the convenience of the Tesla EVSEs. Initial designs transmitted with a little too much power and could open every charge port within a rather large area.

Holding the rear trunk button on the regular Tesla key fob opens the chargeport door...

(I learned and exercised this after my wife ran over my HPWC cable handle, breaking the button...)

 

[WinterDragoness]

Bah. Teensy USB only supports 0-5V "TTL" level signalling and requires something like a MAX232 chip to convert to RS485 voltage level. So unless I can find a MAX232 chip to steal out of some old serial device, I'm dead in the water till the USB cables arrive. Still, I'd like to get Teensy working because it may fit in the HPWC for permanent control. Just need to find a way to power it and add Wifi.

 

[M_VdM]

I guess you would need a MAX485 / MAX3485 (for 3,3V) or some similar transceiver IC.
Plenty of info on the interwebs ;-)

 

[WinterDragoness]

I guess you would need a MAX485 / MAX3485 (for 3,3V) or some similar transceiver IC.
Plenty of info on the interwebs ;-)

Yeah, I actually found a spare ADM202 (similar to MAX232) and then realized they both convert 5V TTL to RS-232 which is not compatible with RS-485. Bah humbug. Back to waiting for cables.

Note the ADM202 came out of a Wacom tablet I converted from serial interface to USB using a Teensy, which is why I thought it might work for RS-485. I'm a software writer by day and only dabble in this hardware stuff from time to time so feel free to correct me if you see me heading in the wrong direction again.

 

[MITE46]

If the protocol is not bidirectional, and the connections from master to slave are labelled out->in, does that imply that the master will provide as much power as is required for the connected vehicle, and simply tell the slave what amount of available power is left over?

The master tells the slave how much power is available. The slave will announce it's status...interestingly enough, the master does't reveal too much to the slave what it is doing. When the units are first powered on, there are some rapid fire redundant messages, probably to establish master/slave relationship.

 

[Fuzzylogic]

Small side project, I captured the charge port open signal from my eu wall connector.
Its transmitted on 443.920 MHz using I belive OOK+Manchester.
For each button press the message is repeated ten times (looking at three of those in the first screenshot).

Hi TheNoOne,

Here's the sourcecode for some microchip pic chips, plus the code for the Silabs Si4010 (the same chip tesla used in the UMC)
GitHub - mstegen/Open-Chargeport: Opens the chargeport of a Tesla Model S

 

[WinterDragoness]

The master tells the slave how much power is available. The slave will announce it's status...interestingly enough, the master does't reveal too much to the slave what it is doing. When the units are first powered on, there are some rapid fire redundant messages, probably to establish master/slave relationship.

It's funny you're describing the protocol exactly as I guessed it would work. I'm also guessing each HPWC sends the same message repeatedly in case the connection is bad - at least one message should get through. The message repeats might also be because there's no way for each HPWC to know if the other is going to try talking at the same time (at least that's my impression). Sending the same message repeatedly might help ensure it gets through at least once. Maybe as soon as the slave sees corruption or senses another device is talking, it will shut up and listen to catch a message repeat.

There is no need to establish who is master and who is slave via the protocol. A device should always be considered master or higher in the chain to the device it's connected to via its OUT pins.

 

[WinterDragoness]

Hi TheNoOne,

Here's the sourcecode for some microchip pic chips, plus the code for the Silabs Si4010 (the same chip tesla used in the UMC)
GitHub - mstegen/Open-Chargeport: Opens the chargeport of a Tesla Model S

Someone tested TheNoOne's Pi code over on this thread and found that it works. You should probably continue the discussion over there to keep both threads on one topic.

 

[WinterDragoness]

I've been trying to figure out why ctr's logs show messages that are 34 bytes long while IanAber has 17 byte messages (exactly half the length). It might mean the protocol is different between the EU HPWC ctr owns and the American one IanAber is using. But I also noticed ctr said he was logging in "four wire" mode which I assume means he connected to the two IN and two OUT pins during logging of just one HPWC. Since the manual says only the OUT pins should be connected on the master charger, I'm wondering if monitoring the IN pins means he captured twice as many bytes, but those extra bytes are meaningless.

On the other hand, 4-wire mode in RS485 usually means two wires for send and two for receive, so it doesn't make sense he would log anything on the pins his logger considered to be send pins. In that case, ctr's messages really are 34 bytes long and the protocol must be significantly different for EU vs US chargers. I'm going to be working with a US HPWC so I suspect I'll see 17 byte messages and my conclusions won't completely answer how to control the EU HPWC.

 

[TheNoOne]

You should probably continue the discussion over there to keep both threads on one topic.

sorry for mixing up the threads ..

 

[WinterDragoness]

MITE46,

I feel like I've almost got the initial handshake but something's not right.

With rotary on F, I send this fake message from Master:
C0 FB E0 0A 51 03 2E 00 00 00 00 00 00 00 6C C0 FE

and slave immediately responds with something like this:
C0 FD E0 03 2E 0A 51 02 00 00 00 19 00 00 87 C0 FE

I've worked out that my HPWC has hard coded ID 03 2E so 0A 51 is a random ID used for my fake master. Bytes 4-5 contain the ID of the sender and 6-7 the id of the receiver. 02 00 00 00 19 00 00 is some sort of data area and those values may change in reach response, though I've only seen 02 one time (usualy it's 00) and other than 19, I've only seen 11 and 21 once each.

Switching HPWC rotary switch to 8 (40A master mode), I fake a message from a slave with 0A 51 id:
C0 FD E2 0A 51 45 1F 40 00 00 00 00 00 00 E1 C0 FE

As far as I can tell, this message just broadcasts the slave's existence. It prompts master to query the slave with a message directed to it:
C0 FB E0 03 2E 0A 51 00 00 00 00 00 00 00 6C C0 FE

This message repeats 26 times and acts like it's waiting for a response from my fake slave. Based on my first test described above, the appropriate response should be this:
C0 FD E0 0A 51 03 2E 02 00 00 00 19 00 00 87 C0 FE

but sending that has no effect. Master keeps broadcasting its query 26 times, then gives up and starts broadcasting its existence, but it repeats that message to the slave every once in awhile.

I've triple checked my checksum bytes are correct.

I have a number of theories I can try but I hoped maybe you could point out the problem. One theory is that I'm not responding to Master's message within some timing window (I'm using a terminal program because the Perl interface had problems). Another theory is I have to respond correctly to some minimum number of Master's messages before it considers me valid. Testing either of those requires getting Perl or something other than the terminal working.