search

ngardiner / TWCManager

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

Feature request: option to disable or enable #263

Open rtega opened 3 years ago

rtega commented 3 years ago

I think that the spiking is no longer necessary in recent Tesla's. The 2019 Tesla model 3 that I tested actually switches amperage so fast that I see it in the current use at my meter. This means that when it should charge below 16 amps it spikes for 5 seconds to 16 amps every 30 seconds or so. I disabled it crudely and the car happily seems to switch to the amperage TWCManager demands without actually spiking to 16 amps.

MikeBishop commented 3 years ago

That could be; the question is whether it's still necessary on older Teslas which are receiving firmware updates.

Flitzer42 commented 3 years ago

Great Idea, at least we should have the option to disable it (even its crudely :-) ). I would be happy to know where to tweek to test it also.

rtega commented 3 years ago

Depending on where you live I set setSpikeAmps to 1 here: https://github.com/ngardiner/TWCManager/blob/2cef9c242cf5beb227f1be50fd5219c65e587bd0/TWCManager.py#L852

Could one of the devs correct me if I'm actually wrong? Don't want to blow any Tesla's into the air because of this.

Flitzer42 commented 3 years ago

Hi rtega, many thanks for this info. It partially works (tesla did not catch fire :-) ). I observed, that the spikes to 16A do no longer appear when increasing the power from 6A. But there are still spikes to 0 when changing the power inbetween. So we are half way towards a solution, but I think we have to tune the code (not only parameters) for final success.

grafik The blue solid line is the charging power. At 9:45 I chnaged the parmeter in TWCManager.py and restarted the service. The peaks to 16A disapered, but the ones to 0 are still there. (Graph from OpenWB)

Another example grafik Works fine most of the time, sometimes spikes to 0.

rtega commented 3 years ago

I'm not seeing those spikes to 0, only to 4 amps. Ideally we would have to make the code in lib/TWCManager/TWCSlave.py conditional. I think it would be wise to leave that up to the devs. chargingsession

Flitzer42 commented 3 years ago

Fully agree. the code is complex but very well documented. If I understand it correct, there is already some probing to only create the spikes when the tesla does not react to the changes. But its up to the developers to clarify. Besides that I need to have a closer look into the spikes. Perhaps its only the current reported by TWCManager. Lets see.

MikeBishop commented 3 years ago

IIRC, there are two situations in which it spikes. One, the more common, is that on increases, whenever the old and new current are below the spike amps (21A in NA, 16A elsewhere, I think?), it spikes for 5 seconds and then drops to the new current. The other is when the car appears to be stuck at a speed lower than what's being offered. This is harmless, though it looks funny in the logs, since it doesn't change how much current is actually being drawn.

ngardiner commented 3 years ago

We can certainly provide a switch to disable the spiking, but I'm not sure we've established that it is no longer necessary for newer vehicles - even with the testing so far, it was never a case of always being needed to negotiate charge rate, it is there as a mechanism to unstick a stuck charge rate on the vehicle side so you don't have to walk to the vehicle and adjust the charge rate (as we can't do so over the API) if it does not increase as the TWC increases the power offered. As @MikeBishop points out there is both proactive and reactive charge spiking and disabling both is probably not as good an idea as disabling proactive charge spikes when testing this.

We'll add a switch to disable this, which would allow others to effectively "crowdsource" testing across different types of vehicles. I suspect we'll always default to spiking because it doesn't seem right to me from a logic perspective to default to not spiking to encourage charging at the higher rate if newer vehicles don't need it, whilst breaking the functionality by default for older vehicles - I could only see this as being opt out (since we can't read the vehicle type from all TWCs, although those with newer firmwares we can read the VIN and decode it, something I am working on now, and we can also read some values from the API).

Let's see what the outcome of testing is, but we'd probably need a combination of multiple confirmed tests for a given model, and the ability to identify that particular model either through VIN decoding or API calls, before we'd turn it off automatically for vehicles - and then there's the issue of working out which vehicle is connected to which TWC in a multi TWC setup without the VIN functionality, so you can see the complexity that comes from disabling for certain vehicles and the relatively low payoff that this brings vs just leaving it universally enabled.

ngardiner commented 3 years ago

Also, part of the reason for the spike amps functionality is to get around this behaviour from Tesla vehicles:

https://myenergi.info/tesla-model-3-remembering-lowest-possible-amperage-t484-s80.html

https://teslamotorsclub.com/tmc/threads/car-not-charging-using-all-amps-available.171068/

It will record sometimes that it saw an "issue" with a TWC, and lock the charging down to 6/9/11 amps. The spiking unsticks this limit.

rtega commented 3 years ago

Thanks for your opinion on this and wanting to introduce a switch! I entirely agree on not switching it off by default. We should indeed carefully test whether it doesn't break stuff. The problem I have with it is that when there is relatively little sunshine and thus relatively little spare current available that the spiking in my model 3 actually results in drawing energy from the grid for at least 10 seconds each minute. My model 3 switches so easily it actually defeats the purpose of using TWCManager. In the three charging sessions I've done up to now, all seems to go well. I'll certainly report when something goes haywire.

Flitzer42 commented 3 years ago

@rtega: does the spiking happen each minute also if there is no change in "Amps offered"? On constant amps offered I do not see any need for spikes. @MikeBishop: yes I already expected that id does not spike at any chnage of the power @ngardiner: Fully agree. It is (at least to me) rather cosmetic improvement than an urgent issue (you might have some more important things to solve). Also I think it is the right way to only provide this as an option to disable and keep the default as is. I am only wondering whether this also happens on load sharing between TWCs. Looking close to the graphs I posted in revious comment, I see the spikes to zero on the current reported by TWCManager (blue), but I do not see them on my grid meter (red). The values from the grid meter are filterd and thats perhaps the reason for not seeing them. On the weekend, I will have a closer look (need sunshine :-)).

rtega commented 3 years ago

I tested it in variable weather (cloud-sun-cloud-sun-...) so it was jumping up and down all the time. When there was a stable period it didn't spike as far as I can remember. I saw the positive and negative spikes on my grid meter.

ngardiner commented 3 years ago

If you feel like getting a bit experimental, I have added 2 switches as part of a separate PR that I'm working on (but that was touching a lot of the same components, so made sense to add it in) to the vin_mgmt branch that is in active development. You can switch to this branch with a git checkout vin_mgmt. The checkboxes to enable or disable spiking are on the Debug page, under Advanced Settings, and there are two different toggles:

image

Proactive Spiking are cases I've identified where we spike not as a result of a "stuck" charge but as a proactive measure when we detect that a charge rate change is below a given threshold, the first of the two reasons for spiking. This is the one that I think is most likely going to both reduce the majority of the spikes you see and likely not affect you much - but also the one that needs widespread testing.

The Reactive Spiking cases are where we detect that a vehicle hasn't responded to a change in charge rate. You probably want to keep them enabled, but that really depends on what you observe when turning it on/off. I haven't done much useful testing of either of these because the generation conditions in my area have been really poor over the last few days, and things may not work exactly as I'd anticipated but given it's a development branch we can always experiment and tune things. If you do get a chance to test it out, I'd be interested in your findings, in terms of if it smooths out the spikes and whether things keep working as expected for your with one or the other option disabled.

The other test that might be interesting to run with these settings is to artificially introduce a stuck charge. We can do this by adjusting the MCU's charge rate to 6A for example. That way, when we offer more current and the car doesn't respond, if reactive charging is enabled it would spike to get the car out of that state. Proactive spiking turned off shouldn't stop this from being fixed with a reactive spike, so the more I think about it, the more I suspect that most of what we wanted in terms of spike behaviour is in the reactive spiking rather than the proactive spiking - we may end up finding only one is necessary.

Flitzer42 commented 3 years ago

@ngardiner Hi Nathan, thanks for working on this topic. I would be happy to test it. The installation failed. Agree with your statement regarding the proactive spiking. Think reactive should solve the issue when the car is getting stuck, but does not show up when everything goes right. I tried it on a blank system as well as with having v1.2.1 installed. In both cases the installation terminates with

> Package libffi was not found in the pkg-config search path.
> Perhaps you should add the directory containing `libffi.pc'
> to the PKG_CONFIG_PATH environment variable
> No package 'libffi' found
> c/_cffi_backend.c:15:10: fatal error: ffi.h: No such file or directory
>  #include <ffi.h>
>           ^~~~~~~
> compilation terminated.
> error: Setup script exited with error: command 'arm-linux-gnueabihf-gcc' failedwith exit status 1
> make: *** [Makefile:50: setup] Error 1

Same happens when checking out "main". As I am no programmer I have no idea how to overcome this.

ngardiner commented 3 years ago

Thanks @Flitzer42. It looks like one of the new dependencies introduced in v1.2.2 requires libffi. I've updated the Makefile in the vin_mgmt branch, could you please do a git pull and try again?

Flitzer42 commented 3 years ago

One step foreward but perhaps not the final one :-)

Installing pycparser-2.20-py2.py3-none-any.whl to /tmp/easy_install-qybjmk4e/cryptography-2.1.4/.eggs

Installed /tmp/easy_install-qybjmk4e/cryptography-2.1.4/.eggs/pycparser-2.20-py3.7.egg no previously-included directories found matching 'docs/_build' warning: no previously-included files matching '*' found under directory 'vectors' build/temp.linux-armv7l-3.7/_openssl.c:570:10: fatal error: openssl/opensslv.h: No such file or directory

include <openssl/opensslv.h>

      ^~~~~~~~~~~~~~~~~~~~

compilation terminated. error: Setup script exited with error: command 'arm-linux-gnueabihf-gcc' failed with exit status 1 make: *** [Makefile:50: setup] Error 1

No test today ...

rtega commented 3 years ago

Another dependency. You need libssl-dev as well. I installed it and tried it and seems to work as intended. I'll test it extensively this week. Thanks a lot!

On 25 April 2021 18:15:24 CEST, "Flitzer42 - @." @.> wrote:

One step foreward but perhaps not the final one :-)

Installing pycparser-2.20-py2.py3-none-any.whl to /tmp/easy_install-qybjmk4e/cryptography-2.1.4/.eggs

Installed /tmp/easy_install-qybjmk4e/cryptography-2.1.4/.eggs/pycparser-2.20-py3.7.egg no previously-included directories found matching 'docs/_build' warning: no previously-included files matching '*' found under directory 'vectors' build/temp.linux-armv7l-3.7/_openssl.c:570:10: fatal error: openssl/opensslv.h: No such file or directory

include <openssl/opensslv.h>

      ^~~~~~~~~~~~~~~~~~~~

compilation terminated. error: Setup script exited with error: command 'arm-linux-gnueabihf-gcc' failed with exit status 1 make: *** [Makefile:50: setup] Error 1

No test today ...

-- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: https://github.com/ngardiner/TWCManager/issues/263#issuecomment-826349445

ngardiner commented 3 years ago

Great, thanks @rtega

@Flitzer42 - I've pushed the additional dependency, you can do a git pull to get the update.

Flitzer42 commented 3 years ago

Hello Nathan, thanks for fixing the dependency. Installation worked fine. Here my findings from the test: First of all, I am using the legacy web API to connet OpenWB. In OpenWB I can see both, the current charging power of the vehicle (from TWCManager) and the data from my grid meter.

When I switch on "Proactively"

Additional finding 1: With "reactively" there are no spikes necessary to change the power from whatever power to whatever. I almost tested all combinations.

Additional finding 2: When current limit in the car is set to 10A, the behavior is a bit strange: Set to 14 Amps via legacy interface ("reactive")

Summary

Flitzer42 commented 2 years ago

Sorry for bothering you again with this issue. I recently updated to 1.2.4 (main) and now it looks like that the spike settings are no longer stored persistently. By default, both settings are activated. Thats fine. When deactivating one of the spike modes (unchecking the check box), saving the debug-settings and refreshing the page, the boxes appear as selected. Looks good. But when switching to another view (e.g. home) and switching back to debug, the boxes are checked again (spiking enabled). The settigns do not show up in "settings.json".

In comparison, on 1.2.2 it works fine, settings are shown correct in UI and the settings are stored in settings.json. Any idea where the settings are gone? Are they stored at a different location?

BTW: Can I just add the <"spikeAmpsProactively": 0,> at any position in the the settings.json file?

rickhuizinga commented 2 years ago

Data point: 2019 Model 3 (SR) - spike amps can be disabled (both proactively & reactively). Changing the charging current continues to work work properly with spike amps disabled.