Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Battery Incorrect Report - Drops to zero randomly #55

Closed
eximo84 opened this issue Aug 9, 2021 · 7 comments · Fixed by #144
Closed

Battery Incorrect Report - Drops to zero randomly #55

eximo84 opened this issue Aug 9, 2021 · 7 comments · Fixed by #144
Assignees
Labels
bug Something isn't working

Comments

@eximo84
Copy link

eximo84 commented Aug 9, 2021

Odd issue where the battery for a period of time showed 0% despite showing 90% previously.

This actually reflected the app until i forced a refresh to get the value back to normal. I've noticed this a few times with the bluelink app?

Maybe some logic to check for instant recharge of battery which couldn't happen unless the odometer increases or something is left on but even then it wouldn't be 90%-0%

image

@fuatakgun
Copy link
Member

Checking sudden changes might look suitable for EVs but not suitable for PHEV, they have a range of 50km (9kwh) and decrease can happen so quickly. But I noticed that this is happening when car is still / not moving. If you can confirm this too, I can come up with a solution;

  • if car was not running and is not running now and
  • if EV battery decreased to 0% and previous value was not 0%
  • initiate force_update.

@eximo84
Copy link
Author

eximo84 commented Aug 11, 2021

Yep car was stationary and hadn't moved. Logic sounds good.

@fuatakgun
Copy link
Member

OOO for 2 weeks.

@fuatakgun fuatakgun changed the title Battery Incorrect Report Battery Incorrect Report - Drops to zero randomly Sep 16, 2021
@fuatakgun fuatakgun added the bug Something isn't working label Sep 16, 2021
@fuatakgun fuatakgun self-assigned this Sep 16, 2021
@TobiasLaross
Copy link

I have a related problem. I have an automation that if the car has less than 45% battery it is set to charge needed and will be charged until >65%. While charging, force_update is called once per hour during the blackout period. It is interesting that when charging was started it dropped to 0 and after it reached 65% it dropped again. And afterwards it dropped to 30% which was the initial level before charging started.

This makes me think that it has something to do with force_update and I was sleeping during this charging session but I have seen similar behaviour before and when opening the UVO application it also reported 0% until I hit refresh in the app. Do I need to trigger update after each force_update?

My workaround is now that charging needed is only set if charging needed has been off for 5 hours.
Screen Shot 2021-10-28 at 08 38 40

@dahlb dahlb mentioned this issue Nov 11, 2021
@cdnninja
Copy link
Collaborator

Maybe we either

  1. Force a rescan if a 0 value occurs. I would think most people don't run a car to 0%.
  2. Force a rescan when the value changes by more than X percentage from last value.

First one may be an easy approach but based on the above chart 0% doesn't seem to be the only issue as I assume your car didn't go from 35 to 100 in a single scan.

@dahlb
Copy link
Contributor

dahlb commented Nov 16, 2021

I'm going to try to put this logic into a pr tomorrow

  • if car was not running and is not running now and
  • if EV battery decreased to 0% and previous value was not 0%
  • initiate force_update.

@dahlb
Copy link
Contributor

dahlb commented Nov 16, 2021

#144 should fix this, extra testers needed as it takes a while to repro, I'll be running for a few days and expect to see no errors and no more 0 logs

@dahlb dahlb linked a pull request Nov 19, 2021 that will close this issue
@dahlb dahlb self-assigned this Nov 19, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants