alandtse / tesla

Tesla custom integration for Home Assistant. This requires a refresh token be generated by third-party apps to login.
Apache License 2.0
583 stars 100 forks source link

Charger switch state reports off while charging #101

Closed jesusmarcos closed 1 year ago

jesusmarcos commented 2 years ago

As far as I understand, the charger switch is to stop/allow a charge while the car is plugged. Is this the case, that switch is not working in my car.

I tried to use it to avoid charges of 5 minutes while connected, so if I detect that the SoC is greater than 70%, the car doesn't charge.

Before the authentication change in the API I was doing it directly by myself but after that, and knowing that a component exists, I decided to move to you component to execute actions over the car.

Thanks for the great job

alandtse commented 2 years ago

Please turn on teslajsonpy in debugging and see what it says when you try to change the switch.

jesusmarcos commented 2 years ago

Please, can you let me know how to do it? Is it something I should install in home assistant? Change its configuration?

Sorry.

alandtse commented 2 years ago

in the debug section of homeassistan's configuration.yaml add teslajsonpy: debug

jesusmarcos commented 2 years ago

Sorry for the late reply. I usually charge the car at night and I never remember to test it at 1:00am

I don't have any special event at log when switching off the switch "charger_switch".

Yesterday, I tried it manually and it worked (clicking directly the switch), but when doing it from an automation, it switches it off but there is no effect in the charging status of the car.

Any additional test that can bring some light?

Thanks a lot for your time and effort

alandtse commented 2 years ago

I can't debug this with the info you provided. If it works manually then it should work automatically. Absent teslajsonpy logs showing what is happening to the API call at 1AM, there's not much i can do to resolve this for you.

jesusmarcos commented 2 years ago

I know that it's difficult. :-(

Today I tried manually again and it didn't work again.

This is the part of the log when I tried to enable the switch (at that moment, the car was connected and charging):

2021-12-17 05:09:52 DEBUG (MainThread) [teslajsonpy.connection] post: https://owner-api.teslamotors.com/api/1/vehicles/2xxxxx8/command/charge_start {} 2021-12-17 05:09:52 DEBUG (MainThread) [teslajsonpy.connection] 200: {"response":{"reason":"charging","result":false}} 2021-12-17 05:10:22 DEBUG (MainThread) [teslajsonpy.controller] Skipping update of 04169 with state online

The car was charging, but the switch was disabled at that moment. When I switched it on, it immediately switched it off again and the only message in the log was that.

The other day, manually it worked but the difference was that the switch was on while charging. I normally don't use the component to get the status because I use also teslamate with MQTT for that. I use it for executing commands.

I hope this helps a little bit. If you want me to do some more tests, don't hesitate to ask for that.

Thanks a lot for the great effort

alandtse commented 2 years ago

Ok, so you're saying the state says it's off but it's actually on? This is why "not working" is not a good description of your problem because if you had said this at the beginning I probably could have solved it then.

The logs have the expected behavior since you can't start a charge if it's already charging. But if it's a UI issue then maybe it's something we can fix.

What do the logs say about the charging state right before this point? There should be a large json being dumped to the log with charging_state. See https://tesla-api.timdorr.com/vehicle/state/chargestate for an example. In theory if it's been charging, the component should have received an update to update the switch state.

jesusmarcos commented 2 years ago

First of all, sorry for not providing a proper description to the problem. When I created the issue I had no further information than "it's not working". As I said, I have an automation that deactivates this switch so for me the status of the switch was correct (according to the order given by the automation) but it was not stopping the charge.

Ok, anyway...

The status in the previous info row in the log of the field charging_state is "Charging".

Thanks again for the effort maintaining this useful component.

alandtse commented 2 years ago

Can you provide the raw logs (with obfuscation of your sensitive info) showing the two updates right before this and up to the automation attempt? The code is quite simple at this stage and should be setting the charger switch to true.

jesusmarcos commented 2 years ago

log.txt

Hi again. I could finally dedicate some time (due to Christmas holidays) to investigate and get the log. Find attached the log with a couple of updates.

Also I can give you more details about what is happening in my case.

1) Let's suppose that the car starts charging. At this moment the charging_state is "complete" (because it was charging before) so if I switch off the switch, nothing happens (the status of charging_state is not updated because of the timeout defined). It takes (in my case) 660 seconds to update (this is what is configured). In this scenario, nothing is registered in the log. Simply ignores that I want to switch it off.

2) If it's charging and the charging_state is "charging" because it had time to update the status, then I can stop the charge and start it again with no issues.

3) If I stop the charge from the car (for example), it takes some time to detect that the charge is stopped. So if I try to switch it on again, ignores the command as in the scenario 1.

I hope this, together with the log, clarifies a little bit the issue.

Thanks a lot for your patience

Olen commented 2 years ago

This is due to the polling interval, which is - as you say yourself - 660 seconds. This means that the car status is only updated every 11 (actually 12, but that is another discussion) minutes. So it might take up to 12 minutes from the car starts charging until it is reflected in Home Assistant. And it might take up to 12 minutes from the car has completed charging, or it was stopped, until that is reflected in Home Assistant.

I am currently working on a series of patches to both teslajsonpy and this integration to try to improve on this situation. The first one was just approved for teslajsonpy and a few more will be coming up shortly. When they are ready (if they are accepted), you will be able to dynamically control the polling interval, and also keep polling more aggressively e.g. when you are connected to a charger, even if the car is not actively charging.

alandtse commented 2 years ago

Ok I'm reading the log. I don't think it's related to polling. The state is being updated correctly because as you noted it's in a "completed state" for multiple polls before. I assume the charging switch is off. Please confirm. If the switch is on, then there's something broken.

Are you doing anything to start charging again other the HA command? For example, are you actually issue a charge command via the app or something else? I wonder if there's a Tesla bug where if you try to issue a charge_start command while it's in a completed state that it results in

{"response":{"reason":"charging","result":false}}

Right now, we assumed the only charging_state that turns on the switch is Charging. The fix may be to also treat Complete as on so you have to explicit disable it and reenable it in the UI.

Olen commented 2 years ago

If I understand this case correctly, what happens here is that his car is connected to a charger. It charges to the charge limit - say 80%. Then it stops charging and goes to state "Complete". When it drops own to 78% (or something) due to vampire drain, the car will automatically start charging again, up to 80% - since that is the charge limit. And this is what OP is trying to avoid.

Is this correct?

The problem now, is that charge state in HA is "Complete" for up to 11 minutes after the car starts charging (depending on where in the Poll Interval the charging starts). And while it is in this state, the charging switch in HA is "off", and hence it can not be turned off again.

First of all - I don't think the switch should be turned on if the state is "Complete", as that would make the switch useless for checking if the car is actively charging or not.

Now, I don't really inderstand the rationale behind what OP is trying to do here. If he wants charge limit to be 70%, it would be better to just set the charge limit to 70%. This could be done with an automation, and even with some conditions for the location of the car if the limit should be set to different values based on location. Currently it needs to be done using an API call, but we could create a service call directly for that as well.

If you update to 1.5.0 and look at the two Wiki-pages documenting the Polling Policy and Dynamic Polling Interval: https://github.com/alandtse/tesla/wiki/Polling-policy https://github.com/alandtse/tesla/wiki/Dynamic-Polling-Frequency This might give you some ideas on how to adjust the Polling Interval such that you don't have to wait 11 minutes before the charging state is updated.

jesusmarcos commented 2 years ago

Hi Alan.

You understood it perfectly. The car arrives to 80% and due to vampire drain drops below that value. Then the car itself tries to charge it until the selected value (that in this case is 80%).

What I’m trying to avoid with the automation is that the car is continuously charging and stopping, charging and stopping,… Due to sentinel mode the battery drain is around 5-10% every day so if the car is stopped for a week, I don’t want to have hundreds of “charges” of 5 minutes in my Teslamate’s records. This is the reason why I created this automation. So, this means that if everything works fine, once every two days, there will be a charge (from around 68%-69% to 80%). In case I need it, I can always activate the charge manually to have it ready.

I’m going to try to change the polling interval dynamically as you suggest, so when connected to the charger, it polls more frequently. I thing that this can be the best option.

Thanks a lot for your help and support.

Jesús Marcos Martín Tel: +34 619 244 961 Email: @.**@.>

@.***http://www.alwaysimproving.es/[hIiNefZgsgdPwC_I5UBPHSAolzlVFKP3qw1ejourX3TqpnNsCh-mwGwOtHfLy7a888p6Oc_YocHwVCKUPze3n08=w1280]https://www.scaledagileframework.com/ [U5hOdKHcSc-f1qBQNvHC6Doo8qg4RPH1vModyT9bNSMxPaD2iX-OfstEqQJr_Icn7k8PGg7umaOO9BVH0VJ4j606BaxdJuGCVFIDt6CYUpeN1s24UXdL7T0pQhwpbnhtuA=w1280] https://www.leanagileinstitute.org/

AVISO DE CONFIDENCIALIDAD: Este mensaje y sus archivos van dirigidos exclusivamente a su destinatario, pudiendo contener información confidencial sometida a secreto profesional. No está permitida su reproducción o distribución sin la autorización expresa de ALWAYS IMPROVING COACHES, S.L. Si usted no es el destinatario final por favor elimínelo e infórmenos por esta vía. En cumplimiento del Reglamento General de Protección de Datos (UE) 2016/679 del Parlamento Europeo y del Consejo de 27 de abril de 2016, y por la LOPD 3/2018 de 5 de diciembre, y garantia de los derechos digitales, le informamos que sus datos serán tratados con la finalidad de realizar la gestión ofertada por ALWAYS IMPROVING COACHES, S.L. Asimismo, le informamos la posibilidad de ejercer los derechos de acceso, rectificación, oposición, supresión, limitación y portabilidad de sus datos ante ALWAYS IMPROVING COACHES, S.L.: C/ SANT GABRIEL 4, 1-4, 08950, ESPLUGUES DE LLOBREGAT, BARCELONA, @. Si usted no desea recibir nuestra información, póngase en contacto con nosotros enviando un correo electrónico a la siguiente dirección: @.

De: Olen @.> Fecha: lunes, 17 de enero de 2022, 9:27 Para: alandtse/tesla @.> CC: Jesús Marcos @.>, Author @.> Asunto: Re: [alandtse/tesla] Charger switch state reports off while charging (Issue #101)

If I understand this case correctly, what happens here is that his car is connected to a charger. It charges to the charge limit - say 80%. Then it stops charging and goes to state "Complete". When it drops own to 78% (or something) due to vampire drain, the car will automatically start charging again, up to 80% - since that is the charge limit. And this is what OP is trying to avoid.

Is this correct?

The problem now, is that charge state in HA is "Complete" for up to 11 minutes after the car starts charging (depending on where in the Poll Interval the charging starts). And while it is in this state, the charging switch in HA is "off", and hence it can not be turned off again.

First of all - I don't think the switch should be turned on if the state is "Complete", as that would make the switch useless for checking if the car is actively charging or not.

Now, I don't really inderstand the rationale behind what OP is trying to do here. If he wants charge limit to be 70%, it would be better to just set the charge limit to 70%. This could be done with an automation, and even with some conditions for the location of the car if the limit should be set to different values based on location. Currently it needs to be done using an API call, but we could create a service call directly for that as well.

If you update to 1.5.0 and look at the two Wiki-pages documenting the Polling Policy and Dynamic Polling Interval: https://github.com/alandtse/tesla/wiki/Polling-policy https://github.com/alandtse/tesla/wiki/Dynamic-Polling-Frequency This might give you some ideas on how to adjust the Polling Interval such that you don't have to wait 11 minutes before the charging state is updated.

— Reply to this email directly, view it on GitHubhttps://github.com/alandtse/tesla/issues/101#issuecomment-1014257205, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AGIJIJMXWQVS6QXFAAILII3UWPHFVANCNFSM5ISYH7ZQ. Triage notifications on the go with GitHub Mobile for iOShttps://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Androidhttps://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub. You are receiving this because you authored the thread.Message ID: @.***>

Olen commented 2 years ago

Hi,

You could try something like this (I don't have any code here, and there will be corner cases you need to take into consideration, but the concept should be possible to grasp).

You could also add an automation that automatically adjusts the charge limit back to 80% if you drive away. And you should maybe check other factors before adjusting the charge limit, like be aware if you intentionally adjust the limit to something else either in car or using the app etc.
But this gives you an idea of what can be done to mitigate what you are experiencing.

jherby2k commented 2 years ago

I believe i'm experiencing the same issue - i've set up dynamic charging current based on available solar power. its working great (adjusts charging dynamically every 2 minutes via automation, which is what i have the polling interval set to as well). However, sometimes long periods of time (hours) pass where the car is charging (according to the Tesla app) but the charging sensor in HA just shows "stopped".

This affects my dashboard, and also means my dynamic charging automation hits the API unnecessarily because it keeps trying to enable charging / change the amps unnecessarily.

I'm just enabling teslajsonpy: debug now - will reply again shortly.

jherby2k commented 2 years ago

ah, looking through the log i think i see what's happening:

In normal polling mode, it only polls at my configured 60 seconds while the car is charging. As soon as my automation turns off charging (due to a cloud or whatever) it then waits for the car to go to sleep for 660 seconds. If i turn charging back on during that time, the sensors still don't refresh until the 660 seconds elapses.

If i change my polling policy to 'connected' with 60 second polling, it never goes to sleep when plugged in at home.

I think ideally if teslajsonpy itself sends a command that should wake the car, like turning on charging, it should cancel the sleep wait and poll the car one more time at the configured interval, instead of waiting for the sleep wait to run down.

I recognize that's a code change.... open to other suggestions! Maybe i should use "connected" but change the polling interval back to 660 after the sun goes down, when the car is at home.