search

ngardiner / TWCManager

Control power delivered by a Tesla Wall Charger using two wires screwed into its RS-485 terminals.
The Unlicense
130 stars 55 forks source link

Provide "stop responding to slaves" option for stopping car charging #2

Open ngardiner opened 4 years ago

ngardiner commented 4 years ago

Currently, a single option (using the Tesla API) exists for stopping car charging. If the API interaction fails, the car continues to charge at the minimum amps for the charger. This aims to provide an alternative for those who don't want to use the Tesla API (which is now modular as of v1.1.4 onwards) and want to instead stop TWCManager from responding to slaves.

This method may result in cars not resuming charge after charging restarts, and may require re-plugging the charger cable. For some, this will be acceptable (and for others, it will not). Providing the option is the preferred way forward.

ngardiner commented 4 years ago

This behaviour is available via 9dba647 by setting chargeStopMode under master.settings to 2. At the moment, the only way to do this is by editing the settings.json file directly. This will be made easier by a feature in the webui to allow changing settings, but this is still under development and not yet ready.

ngardiner commented 4 years ago

Added webui settings interface (not a very polished one, but still...) via d2d0a85. Needs some additional testing over the next few days

AndySchroder commented 4 years ago

FYI, it takes 30 seconds of not responding before the car actually stops charging.

Looks like the wall connector LEDs are green and solid on the upper part of the LED strip and blinking red towards the middle when in the "not responding" state.

It looks like this works more than 3 times before the car has to be unplugged and re-plugged.

Any ideas what changed in the new firmware in the wall connector that doesn't allow a stopping command to be sent? Is it just that no one has reverse engineered the correct RS-485 command yet?

ngardiner commented 4 years ago

Is it just that no one has reverse engineered the correct RS-485 command yet?

There is a stop charge command, refer to the following thread:

https://teslamotorsclub.com/tmc/threads/new-wall-connector-load-sharing-protocol.72830/page-24

I will add it as an option, but I don't think it will be widely adopted. Have a read of the command behaviour from that thread:

FC B2 SS SS RR RR

   - Tell TWCID RR RR to stop charging. SS SS is the fake master TWCID.

   - Stop charge command is seriously bugged in that it will cause a plugged-in Tesla to show a red ring around its charge port as soon as you send the command. Car will refuse to charge again until you send start charge command and then physically re-plug the car.
   - If you set DIP switch 2 in the TWC to the down position, it turns off CAN communication to the car and start/stop charge actually work correctly except if you stop and start charging more than once, the car will randomly decide the charger is bad and refuse to charge again until you re-plug the car. The car may also decide to limit itself to 30A charging and that change is permanent unless you raise amps using the car UI.
   - Basically I'm saying stop/start charge commands are useless for most purposes as they are implemented in firmware 4.5.3.
   - The reason cars respond badly seems to be that stop/start simply turn the relays in the TWC off or on but do not send any CAN message to the car telling it to stop or start (I reached those conclusions by looking at the firmware). My 2014 Model S responds to this by trying to use CAN to start the charger again (car ring flickers blue to show CAN communication) and after a bit it enters perma-error state unless DIP 2 is down which disables all CAN communication. Conceivably, Model 3 or X don't respond badly which is how this escaped quality control? If anyone has a 3 or X or a newer S, please test and let me know.

I am of the opinion that stopping the TWC from responding to slaves for a period of time is still more useful than the behaviour above, but there is no reason we can't offer both as an option.

ngardiner commented 4 years ago

I have added support for the "Send stop charging command" option to stop vehicles from charging in 05231bc. It is currently untested and is regardless not recommended, at least not with Tesla vehicles connected - but it may be the best option so far for non-Tesla vehicles (subject to testing of course).

One feature that I am considering and would like to hear people's feedback on, is an option to take action after issuing a stop command over the Tesla API, in the event that charging continues afterwards. This would allow a mixture of methods for Tesla vehicles and non-Tesla vehicles.

The way I would see this being implemented is via a back-stop method. The idea being this:

In terms of default behaviour, I would be tempted to have it turned on and set to Stop Responding to Slaves, although it would need some testing to ensure the default back-stop Grace Period is not too low.

The key benefit of implementing the "Stop Responding to Slaves" back-stop method whilst maxAmpsPerTWC is below minAmpsPerTWC is to avoid having to stop newly connected vehicles from charging, as there would be no current offered until it went back in to positive territoriy. It would also work fine for up to 3 charge stop events for any "Guest" Teslas which are connected, and it should also work fine for non-Tesla vehicles connected to the TWC.

I will need to go back through the thread or do some testing for a refresher on what a Tesla vehicle will do if it is connected to a TWC that is not being responded to by the master however, I am not sure if it will resume charging once the charge policy allows it.

Can't hurt to add the option, and if we find it is not optimal, we can just default it to off and add a warning in the documentation as I have done for the Send Stop Message option.

AndySchroder commented 4 years ago

Why do you want to tell all units to stop at the same time instead of a specific one?

Also, not sure if your self.getModuleByName("RS485").send() function adds the extra \x00 values in a more general way, but I've had to use:

self.master.sendMsg(bytearray(b'\xFC\xB2') + self.master.getFakeTWCID() + bytearray(self.TWCID) + bytearray(b'\x00\x00\x00\x00\x00\x00\x00\x00\x00'))

in order to get it to work.

ngardiner commented 4 years ago

Why do you want to tell all units to stop at the same time instead of a specific one?

All units connected will reach the same condition at the same time (falling below minAmpsPerTWC) as it is evenly divided amongst slaves. Doing something more refined than that (eg choosing to divert more power to one Slave TWC over another) would be nice, but it would require code/logic that just does not exist today. Implementing this only for this one function won't help as the rest of the system has no concept of diverting available amps from one TWC to another.

Also, more frankly, very few people have more than one Slave TWC, hence the lack of issues being raised around this.

MikeBishop commented 4 years ago

There's a tension between two cases, though. Seeing the flashing red light is an indicator that the script/device has failed, and currently a cause for concern. I would hesitate to make that "normal" by default. Also, the comments in the current code deliberately don't stop charging immediately on plug-in, for a few reasons: First, so that people see the green flashing light they're used to, as a signal that the connection is good. Second, because power might become available -- flex current is one possible cause. If charging starts and there's enough flex for it to continue, the script will respond by increasing the current to minAmpsPerTWC.

I'm wondering if the VIN offers us a better avenue. Now that the script can collect the VIN of the charging car, we could:

There's an inherent timing issue there; we shouldn't take that last step until we've received the full VIN, or we might accidentally conclude no car matches because we have pieces from two different VINs.

AndySchroder commented 4 years ago

Been testing this "Send stop charging command" feature lately and it is working pretty good for what I want it to do. The TWC does not have any red lights come on it, it all stays green. The car does have a red light on the charge port. The car screen has a few different error messages that come up. I will post a video soon showing what is going on.

Also, any ideas if this is requesting the car to stop charging before it pulls the contactors out? Just wondering if repeated use of it could cause the contactors to degrade over time due to arcing a little bit every time it opens if the car is still drawing current?

ngardiner commented 4 years ago

It's a good question @AndySchroder and it is entirely possible that it could lead to early wear, as it does not send a CAN message to the vehicle before it pulls the contactors, and the vehicle has no indication that it is about to occur, leading to the vehicle-side error messages. Unfortunately we have no interface ourselves to communicate to the vehicle via the CAN bus, making this problematic to solve. It would be nice if there were some combination of methods we could chain which ultimately ended with the stop command, but that would take some experimentation and is not guaranteed to be workable.

AndySchroder commented 4 years ago

Finally got around to recording the video of what happens with the "Send stop charging command" in a Tesla Model 3.

https://youtu.be/ynZYQiJx3no?t=293

The command is sent at 5 minutes, 30 seconds.

As I said above, this functionality is working very well for my application.

AndySchroder commented 4 years ago

P.S. Please check out this web page for my project: http://andyschroder.com/DistributedCharge/ .

I have the single wire CAN bus working, so all we need to do is log the CAN bus while triggering the stop some other way (tesla API, touch screen, networking multiple real TWC's together instead of using the fake master that TWCManager is, etc.) and figure out what the stop command you want to use is. Then just use CAN directly instead of the RS-485 port.

You may also want to dig through https://github.com/joshwardell/model3dbc/ , because the command may already have been decoded, I just haven't looked hard enough into that file.