Tesla Wall Connector load sharing protocol

[Nietschy]

I got this, and its working great with no resistor on a 20ft cable:

https://www.amazon.com/DSD-TECH-Converter-Adapter-Compatible/dp/B0721BB8PQ

 

[widodh]

I got this, and its working great with no resistor on a 20ft cable:

https://www.amazon.com/DSD-TECH-Converter-Adapter-Compatible/dp/B0721BB8PQ

Thanks!

I decided to rule out my (cheap) USB modules and ordered this one: USB-RS485 module

That hopefully fixes my issues as I don't want the hardware to be my problem.

 

[widodh]

So I got the new USB module, same result.

I found a cheap one somewhere between my stuff and that one works! It now pairs with TWCManager (Python).

It is really weird that all the modules I tried failed and this simple Chinese one works.

It is not my CAT6 cable I’m assuming.

I’ll dig into this further next week and maybe add a resistor

 

[WinterDragoness]

I've now traced every RS485 command in firmware 04.04.0D. The ones that don't do something obvious generally read or write the state of one or more General Purpose Input/Output (GPIO) pins on the MCU. Knowing what these GPIO are connected to is difficult without scraping off the hard clear coating on the TWC boards in order to electrically test what each GPIO pin leads to. It doesn't really matter because my goal was to find a command that stops charging and it's clear by sending each command whether charging stops or not.

I mentioned earlier that most of my tests to stop charging were done using a fake car device that I now know even a P1 TWC won't let you stop charging. Now that I can see which commands are safe to run, I ran them on a real car while charging. I found only one command had an effect: FC E5. This command stops charging, but only for ~3 seconds. Sending FC E5 repeatedly at various rates will keep charging off when sent at the correct rate, but no rate will stop a relay from flipping on/off in the car every couple seconds which makes the technique useless.

Looking at the firmware, all FC E5 does is set GPIO 14 low. GPIO 14 is never tested anywhere so that's not a flag to the firmware to do anything more complicated. GPIO 14 does not get set high again anywhere in the firmware that's hit when FC E5 is run (I know that because I figured out how to keep the debugger connected while charging, but it can take a number of attempts before it stays connected long enough). So, I theorize that GPIO 14 low tells some other component to reset or run a diagnostic, and that component sets GPIO 14 high when it's done. The component might be the CAN transceiver (labeled UA 16) that talks to the car. Whatever it is, it interrupts the CAN communication with the car so it stops charging, but only for 3 seconds. It's a side effect of FC E5, not an intentional way to stop charging.

An intentional command to stop charging would have to take a TWCID to direct the command to. Firmware investigation shows there is no such command that takes a TWCID parameter, other than master/slave heartbeat. It's still possible there could be an "emergency stop all TWCs on the network" command that takes no parameter, but then my tests of all commands would have found that.

So, given all this, I've moved my stop charge via car API code to github.

I added a Charge 1-day button and better debug web interface (http://<pi IP>/ndex.php?debugTWC=1).

I also found that charging at low amp rates wastes a lot of power and degrades batteries faster.

Charging at 5A @240V wastes 8.16% more energy than charging at 10A, which wastes 2.48% more energy than charging at 40A. Charging only at 20A and above would be a decent compromise (wasting less than 1.9%), but few home solar systems generate that high a power level for long enough. TWCManager now defaults to charging at a minimum of 10A (2.4kW) to limit these losses. This is set using minAmpsPerTWC in the python source.

Professor Jeff Dahn is considered a leading authority on lithium ion batteries. He says minimal battery damage happens when charging at total battery capacity / 2. For a Tesla with minimal 60kWh battery, 60kWh / 2 = 30kW. Even 240V*80A=19.2kW, so there is no way to charge that quickly at home, but basically charging at the maximum amps your charger supports is best to limit battery degradation. I have no idea how much this actually matters (anyone know?).

Jeff Dahn also says leaving a battery at 75% SoC is best. Since the car is only using 95% of the true battery capacity when the UI says 100%, 75% SoC should be more like 80% on the car UI.

I found that California's electricity grid wastes less energy (4.6% in 2016) than the historical US average (6.5%). This reduces the amount of power TWCManager can save me, but I also did a better analysis of how much power would be drawn from the grid for a day of charging. This analysis is at the top of the PDF installation manual and suggests a savings of 6kWh per month in California.

You can check grid losses in any US state here. Click your state name, scroll down and click Full data tables 1-14, then click the little green Excel icon near the top. Open the downloaded file in a spreadsheet program or Google Docs then switch to tab 10. Divide “Estimated losses” by “Total supply” to get a loss percentage for your state.

 

[M_VdM]

Great Job !
I suppose you 've been performing all this testing/probing with the TWC 's DIP-switch 2 in the UP position (=Default) ?
What if you put that one in the DOWN position ?
Apparently, that puts this EVSE in a more generic J1772 mode - not using any (Tesla proprietary) CAN-bus signalling ...
See this "Destination charger settings" thread.

 

[WinterDragoness]

Great Job !
I suppose you 've been performing all this testing/probing with the TWC 's DIP-switch 2 in the UP position (=Default) ?
What if you put that one in the DOWN position ?

Putting DIP 2 in the down position is like turning the Tesla into a fake-car equivalent. It disables CAN communication and even a P1 TWC won't stop charging a non-CAN car. It's my understanding that J1772 actually has no analog pilot-signal state for a charger to tell a car to stop charging or use 0A. TWC can obviously just cut power if there's an error like overheat, but maybe they worry how different cars will react to that so it's only done on error. I'm not sure if they even consider non-Tesla cars plugged in to the TWC in its design since you need a third-party adapter like JDapter to even make that possible. It's too bad the third-party adapter doesn't include CAN emulation.

I actually did most of my testing with dip2 down and fake car because with it up, you must leave fake car plugged in ~10sec before TWC gives up trying to talk CAN to it and reverts to J1772. If you try to start the charge before TWC stops talking CAN, TWC blinks red. If you stop and start charge, you must also unplug and re-plug the charge plug and wait 10 sec again unless DIP 2 is down. I don't think I've done any testing with DIP 2 down on a real car but I also can't see what it might accomplish that hasn't already been tested with a fake car.

One other interesting thing I came across: Master linkready2 actually does trigger 5 slave linkready responses from a slave, but only when slave receives two Master linkready2 in a row. This is weird and I'm not sure why it's done that way, unless it's looking for some timing signal in the distance between the two linkreadies in order to choose when it responds. There is some randomness in the delay between the five slave linkready responses, and delays get longer towards the end of the sequence. Firmware also shows slaves look at the Master linkready1 message and at least save the TWCID contained in it to a memory location. They do a bunch of other stuff too but it wasn't immediately obvious what it accomplishes.

 

[davewill]

Putting DIP 2 in the down position is like turning the Tesla into a fake-car equivalent. It disables CAN communication and even a P1 TWC won't stop charging a non-CAN car. It's my understanding that J1772 actually has no analog pilot-signal state for a charger to tell a car to stop charging or use 0A. ...

Lots of non-Tesla EVSEs have timers, and put the pilot in a state that tells the car not to charge. I'm pretty sure, as I noted before, that the pilot is held at 0v to achieve this. It's not particularly helpful if the TWC doesn't do that, however.

 

[WinterDragoness]

This seems to verify that J1772 spec does not define any signal for stop charge. 0% duty cycle on the pilot signal does not mean 0A, it means error. That, and some other states like 0 volt pilot indicate error conditions, so one of those could be used along with cutting power, but I'm not sure if the spec defines how cars should respond to that. Most cars will probably stop charging and start again when the error signal clears, but some (like Tesla) will refuse to resume charging after some number of errors.

TWC definitely never sends a 0% duty or 0V pilot signal even in P1 firmware when set to 0amps.

 

[Nietschy]

TWCManager now defaults to charging at a minimum of 10A (2.4kW) to limit these losses. This is set using minAmpsPerTWC in the python source.

Do you respect the EU 3 phase system and let it stay at a minimum of 5A (or 6A)=4.1 kW if EU System is determined?

So, given all this, I've moved my stop charge via car API code to github.

I added a Charge 1-day button and better debug web interface (http://<pi IP>/ndex.php?debugTWC=1).

May you elaborate this a bit?
Do I understand you correctly that you implemented this "stop charge" command repeatedly every 3 seconds? Or did you mean "Tesla API"?
What does "charge 1 day" mean exactly? Let the car charge for 24 hours in a row?

 

[WinterDragoness]

Do you respect the EU 3 phase system and let it stay at a minimum of 5A (or 6A)=4.1 kW if EU System is determined?

I just pushed an update to implement that. I changed minAmpsPerTWC to minWattsPerTWC in the config section. EU users won't need to alter the setting unless they want to minimum watts even higher 4180 (6A). I also upped the default setting to 2880W (12A) because there was a suggestion in the efficiency study I pointed to earlier that multiples of 3A were most efficient.

Do I understand you correctly that you implemented this "stop charge" command repeatedly every 3 seconds? Or did you mean "Tesla API"?
What does "charge 1 day" mean exactly? Let the car charge for 24 hours in a row?

I'm almost certain there is no way to stop charging in firmware 4.4.D so I uploaded the method that uses the remote car API to stop charging. Sending FC E5 every second or so keeps charging stopped but flips a relay in the car on/off every second or two which will wear out the relay and the car probably won't go to sleep.

This begs the question, how is Maxem stopping charge? Either they're reverting to P1 firmware or they're using a newer firmware version with some new command. Or they use a hardware hack of some sort... I'm trying to get hold of a newer TWC to check if firmware has changed. I also don't understand why my TWC never gets a firmware update from the car. This thread shows the car definitely updates the firmware, or at least tries. Maybe only newer firmware actually supports firmware update? In which case, I'd never get a newer firmware without buying a newer TWC...

The 1-day charge button charges at maximum amps for 24 hours, then returns to whatever settings are otherwise specified. Basically something to click if you need to charge fast during a time period the car doesn't normally charge.

 

[greenjb]

CDragon, first of all a big thank you for all your hard work on this, particularly in commenting your code so comprehensively.

Am based in the UK where 32A 230/240V single phase (7kW) is pretty much for norm for home EV chargers - some people have access to 3-phase but it isn't common. Does your code update/change to minWattsPerTWC take this into account?

We run a system at home called OpenEnergyMonitor (https://openenergymonitor.org) that has a back-end called EmonCMS - it gives us PV, consumption and net grid power figures via a neat JSON API, so I've added code to TWCManager to tie into this. I thought I'd share below in case it was useful for other EmonCMS users (or you wanted to incorporate some modular green energy feed input functionality into TWCManager longer term?):

                   # Use EmonCMS realtime feed data
                   greenEnergyData = run_process('curl -s -m 4 "http://[emoncms_server]/emoncms/feed/value.json?id=[emoncms_pv_feed]&apikey=[emoncms_read_apikey]"')
                   houseEnergyData = run_process('curl -s -m 4 "http://[emoncms_server]/emoncms/feed/value.json?id=[emoncms_house_usage_feed]&apikey=[emoncms_read_apikey]"')
                   # Use realtime EmonCMS voltage data, alternatively just set: houseVoltage = 240
                   houseVoltage = run_process('curl -s -m 4 "http://[emoncms_server]/emoncms/feed/value.json?id=[emoncms_voltage_feed]&apikey=[emoncms_read_apikey]"')

                    if(greenEnergyData and houseEnergyData and houseVoltage):
                        solarWh = int(greenEnergyData)
                        houseWh = int(houseEnergyData)
                        greenEnergyAmpsOffset = 0 - (houseWh / float(houseVoltage)) + self.reportedAmpsActual
                        surplusWh = solarWh - houseWh + (self.reportedAmpsActual * float(houseVoltage))

                        # Watts = Volts * Amps
                        # Car charges at 240 volts in North America so we figure
                        # out how many amps * 240 = solarWh and limit the car to
                        # that many amps.
                        maxAmpsToDivideAmongSlaves = (solarWh / float(houseVoltage)) + \
                                                      greenEnergyAmpsOffset

                        if(debugLevel >= 1):
                            print("%s: Solar generating %dWh, surplus is %dWh, so limit car charging to:\n" \
                                 "          %.2fA%.2fA = %.2fA.  Charge when above %.2fA (minAmpsPerTWC)." % \
                                 (time_now(), solarWh, surplusWh, (solarWh / float(houseVoltage)),
                                 greenEnergyAmpsOffset, maxAmpsToDivideAmongSlaves,
                                 minAmpsPerTWC))

Is it correct to use self.reportedAmpsActual in the surplusWh calculation rather than self.lastAmpsActual?

One odd bug I spent most of the weekend chasing was that if the surplusWh dropped below the 6A minimum it was set to for the first time (for instance a kettle was boiled or power washer started), the car would successfully stop charging but then wouldn't start charging when surplusWh went back to being above minAmpsPerTWC. The debug output kept reporting carApiStopAskingToStartCharging = True despite the car not actually charging/waking up/attempting to charge - it would then stay in that state indefinitely until TWCManager was restarted (or cable unplugged/replugged). The issue seemed to be that the Tesla API didn't respond with a valid response when TWCManager first attempted to re-start charging, so carApiStopAskingToStartCharging was set to True and then was in a state (I think?) where it could never be False. The quick "fix" seemed to be to send:

            apiResponseDict = json.loads(run_process(cmd).decode('ascii'))

.. twice (just duplicated that line); if you want some debug info just let me know. The second API call response always seems to be valid and it has been running flawlessly since, stopping/restarting when other loads cause net grid import. Screenshot below:

 

[greenjb]

Also, as a data point, my brand new UK TWC reports firmware version: FD 1B 04 04 0D 00 00 00 00 00 00 00 00 30

 

[WinterDragoness]

if you want some debug info just let me know.

Yes, please PM me the contents of apiResponseDict so I can handle whatever it's returning differently. carApiStopAskingToStartCharging is meant to only be set True when the car reports that it's done charging or is already trying to charge.

Is it correct to use self.reportedAmpsActual in the surplusWh calculation rather than self.lastAmpsActual?

Yes, reportedAmpsActual should always be used. In fact I just renamed lastAmpsActual to reportedAmpsActualSignificantChangeMonitor because its only purpose is to monitor for significant changes to reportedAmpsActual.

Am based in the UK where 32A 230/240V single phase (7kW) is pretty much for norm for home EV chargers - some people have access to 3-phase but it isn't common. Does your code update/change to minWattsPerTWC take this into account?

So you're saying your TWC runs on one-phase 230VAC instead of three-phase 230VAC? I didn't know that was possible. minWattsPerTWC does not account for that because there is no way to know that is your setup. In fact it looks like there are quite a lot of setups possible which would require adding a numPhases parameter and a voltsPerPhase parameter. I'm not absolutely sure how to convert those three params into Watts (I assume it's voltsPerPhase * numPhases * amps but not certain that works in all configurations?).

minWattsPerTWC was supposed to simplify configuration but I feel like using 3 config params is more complex and more likely to lead to errors in coding or in people configuring so I've gone back to minAmpsPerTWC. That does mean some people will need to adjust the value and figure out how it applies to their system, but you need to understand how amps apply to power delivered for a number of parameters so at least that's nothing new. If 3-phase power to home chargers is rare in the EU, then most people won't have to change minAmpsPerTWC.

 

[greenjb]

Yes, please PM me the contents of apiResponseDict so I can handle whatever it's returning differently.

Will do this tonight.

So you're saying your TWC runs on one-phase 230VAC instead of three-phase 230VAC? I didn't know that was possible. minWattsPerTWC does not account for that because there is no way to know that is your setup. In fact it looks like there are quite a lot of setups possible which would require adding a numPhases parameter and a voltsPerPhase parameter. I'm not absolutely sure how to convert those three params into Watts (I assume it's voltsPerPhase * numPhases * amps but not certain that works in all configurations?).

Yes - in the UK single-phase 230VAC is pretty much standard for normal homes, with commercial premises (or much larger houses) generally being the only ones that have 3-phase (which over here is 400VAC). Therefore we just wire up the TWC with L1, Neutral and Earth and it will function in single-phase mode. However, I believe in other parts of the EU (Germany, Netherlands?) 3-phase is common for standard houses, but not sure of the voltage. I think your idea of numPhases and voltsPerPhase is a good one (and likewise voltsPerPhase * numPhases * amps), and is how EmonCMS and other energy monitor system do it. I can't see any scenario that wouldn't work for.

 

[gingerbeer]

So you're saying your TWC runs on one-phase 230VAC instead of three-phase 230VAC? I didn't know that was possible.

Not something the code should be able to operate with, but for your info I have a switch installed by my electrician, so i can effectively open/close phase 2 and phase 3 of the circuit.

Logic being that
1) when i am on solar (TWC Manager running) then having single phase is better, so that I can have more than 6a or so for the greater part of the day.
2) if I want to charge rapidly, then i can just switch on all 3 phases and get up to 22kw at the TWC. My electricity supplier only gives cheap power between 11pm and 3am, so if i need a lot of charge then 3 phases needed to finish within that window.

95% of the time my system sits on 1 phase. 1 -> 3 phase normally works OK without having to do a reset. 3->1 does generally require a reset, to avoid the red light errors at the car.

 

[WinterDragoness]

I've updated github to fix the bug reported by greenjb.

I also fixed the problem where one car being unreachable prevented all cars from start/stop charge (at least in theory - I only have one car to test with).

The first time a car is contacted by TWCManager, its GPS location is now saved to TWCManagerSettings.txt as homeLat and homeLon. Only cars located within 2000 feet of homeLat/Lon will have their charge started or stopped. This prevents starting/stopping charge on a car plugged in away from home.

If homeLat/Lon are set incorrectly because a car was away from home when you first started TWCManager, stop TWCManager and correct homeLat/Lon values manually by editing TWCManagerSettings.txt. You can also delete the values and start TWCManager only when all vehicles are at home. You may need to start or stop charge via the web UI to trigger the car API to set homeLat/Lon values.

Based on greenjb's TWC serial number (near the red reset button) that starts with A18D, it was manufactured ~June 15 2018 (because D=13 divided by 2 weeks = 6.5 = June 15). The fact he's still got firmware 4.4.D implies there have been no updates in the last ~10 months which is frustrating.

 

[Nietschy]

I'm not absolutely sure how to convert those three params into Watts (I assume it's voltsPerPhase * numPhases * amps but not certain that works in all configurations?).

For Nederlands, Swiss, Germany, Austria and (I guess many more) 3 phases Power is standard for homes and offices.

My house has 32A *230V *3 phases = 22.080W max. Yes, it's just that easy to calculate.
What you see here is the voltage from the 3 phases (like L1 to N) to the middle neutral = 230V
The Voltage between the phases like L1 to L2 to L3 = 400V

The neutral should not be used in a perfect world where all phases are uses equally (like on a powerful AC motor with all 3 phases and 11kW of power.

When you wire a house, you can decide to put all 3 phases to something powerful (like a car charger, or a cooking field), or you just wire just one phase and neutral and ground and split it up just as you need it.

One phase usually has a maximum of 16A and 230V = 3600W. Sometimes you will need 32A * 230V = 7200W (like for the new Jaguar I-Pace that has only a 32A single phase charger). But power companies do not like this, because you end up with an uneven load between the phases. That's the reason why we do not get the Powerwall 2 that has only a 1 phase DC/AC converter in Austria... *sad*

 

[marlan99]

Hi there,

i have also the TWCManager running on a Raspi1b and is working perfectly. Thanks to CDragon for this perfect work.

i have two things to inform here:
1. After installing and following strictly the installation guideline i had to change the executable rights for TWCManager.py to work correct. so a chmod 755 ~/TWC/TWCManager.py had to be done
2. i always set the nonScheduledmax Power with the URL: http://[ipadress]/index.php&nonSchedPWR=10&Save.... or something similar like this. Dont remember the correct syntax. When i use a floating point number (f.e. 7.15) then it sets the maxPower first to 15 and then to 7

are floating point numbers not supported? In the installation manual is a picture with a such a number.

thanks

 

[WinterDragoness]

When i use a floating point number (f.e. 7.15) then it sets the maxPower first to 15 and then to 7

are floating point numbers not supported? In the installation manual is a picture with a such a number.

Floating point isn't supported. Please use whole amps. The RS485 protocol does support floating point, but the actual amount of power the charger uses rounds to the nearest half amp (I think). Setting half amps in the UI would add too many options and not serve much purpose. The car's charger is theoretically most efficient on multiples of 3 amps (except 6A @240V which wastes a lot of power).

The TWC reports the amps actually being used with two digits of floating point which is what you see in the web UI. Amps being used are generally around 0.8A less than what you set it to, at least on my TWC. So if you set 6A, TWC reports it's using 5.14A or 5.23A most of the time.

 

[Nietschy]

The TWC reports the amps actually being used with two digits of floating point which is what you see in the web UI. Amps being used are generally around 0.8A less than what you set it to, at least on my TWC. So if you set 6A, TWC reports it's using 5.14A or 5.23A most of the time.

I want to add something to that, if thats ok:

I observed something that might be interesting for some:
EU chargers (of pre face lift cars) are capped at 16A*3*230V = 11kW. Thats common ground.
But IF I set up 16A in the GUI the system charges actually at about 15.7A*3*230V (reported by TWCmanager) and this is less than what the car is capable to.

BUT: If I set the maximum Amps to 17A, it charges reportedly at 16.something in the TWCmanager GUI and the car reports charging at a little more than when set up to 16.

It seems that the cap of the car is after the current measure of the TWC, so you need to juice up a bit to get the maximum possible charging speed.