Tesla Wall Connector load sharing protocol

[tga]

here in the Netherlands Tesla has tested grid directional with the grid operator. So it’s possible!

As I said above, not with cars' batteries. The car/WC does not have the hardware to take DC from the battery, convert to AC, and feed to the grid.

It doesn't matter how many software updates they push down. The hardware is not there to do it.

If Tesla is involved in the project, it must be with Powerwalls or Powerpacks, NOT batteries in cars. There's no way around this (well, today, anyway).

 

[Craig 128]

@tga What do you think is missing from the cars?

In Europe on the Model 3, I understand they have the CCS2 plug. (I'm in Australia and have the same connector on the Model 3)

I would have thought the HV path from the charging port to the battery for DC fast charging/Supercharging is simply the HV DC pins on the ChargePort connected directly to the battery via a safety contactor, Fuse and current clamps. The charger is responsible for the regulated charging, and the car's onboard BMS will open the contactor if the charger misbehaves or a cell tap voltage goes out of range.

In that case, I would say its just a software change to enable the charging contactor to delivery the batteries HV potential on the ChargePort.

There is no evidence to suggest they are testing Model S/X. I'm not sure about the Model S/X as they multiplex HV DC on the Mennekes connector. But you would think if the DC path is there for Charging, it should work in reverse.

 

[tga]

@tga What do you think is missing from the cars?

In Europe on the Model 3, I understand they have the CCS2 plug. (I'm in Australia and have the same connector on the Model 3)

I would have thought the HV path from the charging port to the battery for DC fast charging/Supercharging is simply the HV DC pins on the ChargePort connected directly to the battery via a safety contactor, Fuse and current clamps. The charger is responsible for the regulated charging, and the car's onboard BMS will open the contactor if the charger misbehaves or a cell tap voltage goes out of range.

In that case, I would say its just a software change to enable the charging contactor to delivery the batteries HV potential on the ChargePort.

There is no evidence to suggest they are testing Model S/X. I'm not sure about the Model S/X as they multiplex HV DC on the Mennekes connector. But you would think if the DC path is there for Charging, it should work in reverse.

The discussion had been about somehow using the Gen 3 WC to backfeed power to the grid. There is no DC to AC inverter in the car or WC to do this.

Yes, with additional hardware (an off-board inverter or V2G-compatible L3 charger) you could connect the car's battery to an external inverter and turn it into a vehicle-to-grid (V2G) system. But Tesla has been very clear that they have no interest in supporing this and increasing wear and tear on car batteries (at least while the battery is under warranty, anyway).

I can't find anything online about Tesla doing V2G testing in the Netherlands. There are several articles about Nissan Leafs being used for V2G trials in Amsterdam, but nothing about Tesla. Until @Myfirstone posts some evidence that the Tesla trials are V2G, I'm going to continue to assume the Tesla products being used in the Netherlands projects are Powerwalls or Powerpacks, not cars, like the dozens (hundreds?) of Tesla projects around the world for virtual power plants, backup systems, grid stabilization, peak demand charge reduction, etc.

 

[israndy]

There is no DC to AC inverter in the car

Not entirely true, the charger circuit for the Model 3 could easily be triggered in software to produce 240v at the inlet pins. You would need a different kind of connection to make use of that power, but taking the DC voltage and making AC out of it can be done in software. I previously uploaded pics of the charger's schematic from a local electric car meeting where this was discussed.

Grid-connected inverters have to have the ability to synchronize with the power coming in, so that would be part of the Wall Connector style box that you would need to connect the battery out to the grid, sensing that and communicating that to the charger that would be used as an inverter. It would still be limited to 48 amps but that's a lot of power.

But it's also not a place Tesla wants to go, so it may be easier to just hack the DC power pins. Feeding that to a high power inverter external to the car, one that works with most electric cars will be an easier way to get to market. Plus you can pull more than the 11kW so you could power your whole house in an emergency or back feed the grid during periods of high demand that command high dollar payouts

I would love to have this ability at our cabin. We mostly drive there in the Tesla and usually plugin immediately to charge up. Then at midnight during the snowstorm, I am woken up by the neighbor's generator kicking on in response the power line coming down somewhere. There I am without heat or coffee or refrigeration but I have a full battery in my car...

 

[natetm3]

Hi All,

Just wanted to share something that I've been working on for a while now.

It's a modularized fork of cdragon's excellent TWCManager, with the ability to add modules for various different systems rather than having to fork the code each time for custom implementations

Some of the benefits of the fork:

• A policy-based approach to charging (Green/Scheduled/Non-Scheduled) allowing charging behaviour to be overridden in config, and to be able to read values from modules to make charging decisions.
• Consumption and charger load offset, so you only charge using the delta between generation and consumption during track green energy, excluding the charger load from the equation (if it is metered alongside household consumption).
  
• A lot of development around the ability to work with stored energy systems such as Powerwalls, implementing things like latching and flex current to avoid rapid transitions on/off charge for these systems.
• A new web interface which, while it is a work in progress, is more user friendly (being AJAX based). In the short future there will be support for debug functionality in the new web interface and the old IPC interface will go.
• The ability to read per-phase voltage and VINs from the TWC, so you can identify which vehicles are/were charging (if your firmware allows for it).
• Integration with MQTT and HomeAssistant (in both directions, input and output)
• A very early RESTful API interface that will expand in usefulness

Importantly, it is nearing a stable platform now after a lot of work to re-engineer it into a more modular form which should help with creative uses. Feel free to give it a try if you're interested.

ngardiner/TWCManager

 

[Craig 128]

Given that there has been some discussion here on bi-directional charging, interested members might want to look at:
Well, we got bidirectional in there after all?
Electrek has just ran a story on bi-directional charging for the Model 3.

 

[Craig 128]

Has anyone seen someone document the CAN protocol the car charge port uses? I don't need the whole protocol - just the stop charge message.

I did some logging on the can bus of the TWC.

CAN id 0x30C is the one you need.
Only one byte is sent:
0x00 Stop Charging
0x01 Start Charging

Thanks Fuzzylogic! Unfortunately, there is only one reference to 0x30C in the firmware and it appears to be comparing 30C to the MsgID of a message received from the car and taking some action. So 30C might be the car telling the TWC it wants to start or stop charging, but I need the message the TWC sends the car to tell the car to stop charging. This message is sent by P1 firmware when you tell the TWC to use 0Amps using the master heartbeat in the RS485 protocol.

Did anyone get to the bottom of this? And does anyone have any details of the SWCAN protocol?

I've been having a play myself. Attached is what I have decoded so far. What I haven't found is the message that advertises the current.

I'm tempted to tap the CP into my hardware in addition to the RS-485, so I can access parameters like SoC.

 

[Myfirstone]

Can someone tell me what I do wrong? I have tried reset the twc replug in the charger but nothing will help.

 

[Myfirstone]

Yes finally it works! rs485 was the problem!

 

[Craig 128]

Unfortunately, there is only one reference to 0x30C in the firmware and it appears to be comparing 30C to the MsgID of a message received from the car and taking some action. So 30C might be the car telling the TWC it wants to start or stop charging, but I need the message the TWC sends the car to tell the car to stop charging. This message is sent by P1 firmware when you tell the TWC to use 0Amps using the master heartbeat in the RS485 protocol.

Been playing around with this a little more.

The TWC sends a packet with a CAN ID of:

• 0x31C every 1 second advertising the max current available from the TWC.
• 0x46C every 1 second containing a payload of 8 bytes - all zero.

However when the TWC wants to suspend charging, first advertises a current of zero (msg 0x31C). Then it sends 0x46C every second with a payload of 00 00 10 00 00 00 00 00. The car on receipt of the first 00 00 10 00 00 00 00 00 payload will return what appears to be an ACK message on 0x45C.

The car will then sit there happy, not charging.

 

[Myfirstone]

Hi all,

I have a little problem. The charger still charge the Tesla without solar power ...

I get this screen -r

What do I wrong?

 

[magic7music]

Hi Guys, and thanks for the great job you did (respect) from the heart of Berlin where the Gigafactory4 is gonna be build.

I got everything set up and running together with my Wallbox (2nd gen.)
The USB-RS485 converter I use is DSD TECH SH-U11F USB TO RS485/RS422 Converter bought at Amazon and has a case around it.

But it seems that I have some problems with implementing my API from my smartmeter system.
I got an PI running the the smartpi software from Enerserve on it. It is acting like a smart meter and gives me all the readings that i want, including an API of the output. If there is enough energy from the sun on the roof I get some negative numbers on my 2nd phase (mains is 240v/400v 3phase).

My API key link looks like this:
http://192.168.1.2:1080/api/2/power/now

The output of the file lokks like this:
{"serial":"smartpi12345","name":"House","lat":52.3667,"lng":9.7167,"time":"2020-06-18 17:18:25","softwareversion":"","ipaddress":"192.168.1.2","datasets":[{"time":"2020-06-18 17:18:24","phases":[{"phase":2,"name":"phase 2","values":[{"type":"power","unity":"W","info":"","data":-425.00882}]}]}]}

The numbers in Bold is the negative energy from the solar panels. (I know it is not enough but I'm bussy with installing another extra 4K on the carport.

In the script i found the greenEnergyData and changed that with my IP and some other information.

greenEnergyData = run_process('curl -s -m 60 "http://192.168.1.2:1080/api/power/now?T=1&D=0&M=1&C=1"')

What went wrong and is somebody here that can help me.

 

[magic7music]

of course the green EnergyData is:

greenEnergyData = run_process('curl -s -m 60 "http://192.168.1.2:1080/api/2/power/now?T=1&D=0&M=1&C=1"')

sorry

 

[marin71]

Hello Guys,
I found this thread after looking for possibilities to charge my Hyundai IONIQ Electric with my TWC (2nd gen.)
Sorry for asking for help in a Tesla forum for non Tesla car. Hope you don't mind

Hardware setup with Raspberry, RS-485 adapter and Fronius smartmeter is fine. Ngardiners fork installed (1.20).
I can charge manually without problems and also via green energy.

Only issue I have is that even the numbers read from smartmeter are displayed correctly the amount of amps available for charging are way too low.

I don't find a parameter to be set in config.json for this problem. Is there anything I can configure so the amps available for charging are nearly the amount which is calculated from available green energy minus consumption.
"subtractChargerLoad" is set to true in my case.

It is already night here, so I will post part of screen dump tomorrow if necessary.

I am a noob when it comes to raspberry and linux, therefore I am happy to got it almost working.

Hope anyone can help!

 

[marin71]

As you can see generated energy is 7315W but charging is limited to 10.15A.
Why is charger load 6720W if it only charges with 10.15A?

 

[shreddyb]

@WinterDragoness In your testing, you mentioned that FCEA was able to perform the reset function but that it left it in an alternate state.

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.

In your testing, were you able to command a slave TWC to reset at all, but without leaving it in an alternate state?

 

[JarlN]

Been playing around with this a little more.

The TWC sends a packet with a CAN ID of:

• 0x31C every 1 second advertising the max current available from the TWC.
• 0x46C every 1 second containing a payload of 8 bytes - all zero.

However when the TWC wants to suspend charging, first advertises a current of zero (msg 0x31C). Then it sends 0x46C every second with a payload of 00 00 10 00 00 00 00 00. The car on receipt of the first 00 00 10 00 00 00 00 00 payload will return what appears to be an ACK message on 0x45C.

The car will then sit there happy, not charging.

Did you use a specific SWCAN transceiver to listen to the traffic? Or just tied CANL to ground like i've seen a few times via a Google search?

I'm trying to build a board based on an ESP32 (rather than using a raspberry pi) and i left a spot for a CAN transceiver, but stupidly i didn't do much research and just assumed it was two wire CAN. I'm hoping it will still work by tying CANL to ground.

Also, after you tell the car to stop charging via CAN, can the TWC issue another 0x31C with a new available current and the car will start charging again?

My software skills aren't wonderful so it's going to take me a while to do the RS485 code but if I can make that work i'd be interested in doing more with the SWCAN control line so i don't need to worry about using the API to stop charging..

 

[geirvevle]

Hi.
Seems to get everything set up, but for some reason GUI does not work and I get a lot of different messages like this in the log:
ERROR: Ignoring message of unexpected length 1604: 14 EC E8 B3 35 E7 FF FF FF FF FF FF FF FF FF EB 7F 07 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 F0 14 EC 78 1A B3 E7 FF FF FF FF FF FF FF FF FF 35 7F 07 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 14 EC 78 1A B3 E7 FF FF FF FF FF FF FF FF FF 35 7F 07 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00


They have different values in the length part but looks similar most of them.

Using a RS485 Shield for Raspberry pi from SEED. Have tried everything I think. Adding terminating resistor, changed wires, disconnected the second TWC. Grounded the RS485 shield. Any ideas anybody?

-geir

 

[Craig 128]

Did you use a specific SWCAN transceiver to listen to the traffic? Or just tied CANL to ground like i've seen a few times via a Google search?

I'm trying to build a board based on an ESP32 (rather than using a raspberry pi) and i left a spot for a CAN transceiver, but stupidly i didn't do much research and just assumed it was two wire CAN. I'm hoping it will still work by tying CANL to ground.

I've been using the NCV7356 Single Wire CAN Transceiver. (I built a breakout board here and have written a parser here to eavesdrop)

Also, after you tell the car to stop charging via CAN, can the TWC issue another 0x31C with a new available current and the car will start charging again?

I have yet to talk to the car myself - all I have done is eaves dropped on communication between the TWC and a Model 3. However, from what I have seen the TWC is able to re-establish charging again. An excel spreadsheet with the decoded commands can be found on GitHub.

What is the status on your ESP32 board? This is my next step (I've ported most of the TWC code to C to eventually use on an ESP32 target)

 

[JarlN]

I've been using the NCV7356 Single Wire CAN Transceiver. (I built a breakout board here and have written a parser here to eavesdrop)



I have yet to talk to the car myself - all I have done is eaves dropped on communication between the TWC and a Model 3. However, from what I have seen the TWC is able to re-establish charging again. An excel spreadsheet with the decoded commands can be found on GitHub.

What is the status on your ESP32 board? This is my next step (I've ported most of the TWC code to C to eventually use on an ESP32 target)

Thanks, i have a batch of PCBs coming but they are designed around a two wire CAN bus transceiver so may not be very useful. I don't know much about CAN, let alone SWCAN, so i'll have to do a lot more research before i get to that stage.

Thanks for your code in C - having it was actually what prompted me to try and build something. I've only just started putting together an outline of what i plan to do but i'm hoping that seeing as i'm basically joining up work done by others though various libraries and your code, i might have a chance of making something work.

My current PCB design is available in a GitHub Repo. Software will end up in there too at some point and there might be a Rev 00C of the PCB if i have to use a SWCAN transceiver (i'm still hoping a standard transceiver will work by tying CANL to ground and setting baud to 33.3k - looks like SWCAN has a high voltage wakeup mode which i'll miss out on but i'm hoping that won't matter.

I wonder how the TWC will react to something else issuing CAN commands and whether it would through it's internal state out. It'd be a lot of work to have to act as both devices and selectively pass certain messages back and forward (i.e. when you want to stop charging, send the car a 'zero current' message but at the same time send the TWC a 'car wants to stop charging' message). Anyway my first step is to get the RS485 piece working and control start and stop via the API and then look into CAN later if there's any motivation left.