13 posts / 0 new
Last post
jbeuree
OVMS Keeps trying to charge over and over

Have a newly installed OVMS, and for some reason it caused the car to continually keep charging all night over and over. Used the OVMS to initiate the initial charge as it was on the timer, so it wasn't going on it's own initially. It kept going all night though, and the logs look like the OVMS was trying to initiate a new charging session every time the previous one completed. Had to unplug the vehicle to get it to stop. Here's a sample of what kept showing up in the logs. Any advice on what the possible cause of this would be?

2020-08-24 01:37:57 EDT I (12333553) ovms-server-v2: Incoming Msg: MP-0 AFA
2020-08-24 01:37:57 EDT I (12333553) ovms-server-v2: Send MP-0 a
2020-08-24 01:38:19 EDT I (12355163) ovms-server-v2: Send MP-0 PA - Charge Stopped|SOC: 100.0%|Ideal range: 160km|Est. range: 112km|ODO: 121494.0km|CAC: 52.8Ah|SOH: 80%
2020-08-24 01:38:19 EDT I (12355653) pushover: Sending message Charge starting with priority -2
2020-08-24 01:38:24 EDT I (12360363) pushover: PushoverMongooseCallback(MG_EV_CONNECT=0:Success)
2020-08-24 01:38:24 EDT I (12360393) ovms-server-v2: Send MP-0 PI - Charging|396.0V/0.0A|SOC: 98.0%|Ideal range: 160km|Est. range: 112km|ODO: 121494.0km|CAC: 52.8Ah|SOH: 80%

 

2020-08-24 01:52:59 EDT I (13235493) ovms-server-v2: Incoming Msg: MP-0 AFA
2020-08-24 01:52:59 EDT I (13235493) ovms-server-v2: Send MP-0 a
2020-08-24 01:57:25 EDT I (13501243) housekeeping: 2020-08-24 01:57:25 EDT (RAM: 8b=80672-84060 32b=9576)
2020-08-24 01:59:45 EDT I (13641163) ovms-server-v2: Send MP-0 PA - Charge Stopped|SOC: 100.0%|Ideal range: 160km|Est. range: 113km|ODO: 121494.0km|CAC: 52.8Ah|SOH: 80%
2020-08-24 01:59:45 EDT I (13641183) pushover: Sending message Charge starting with priority -2
2020-08-24 01:59:48 EDT I (13644923) pushover: PushoverMongooseCallback(MG_EV_CONNECT=0:Success)
Drc38
Hi, I have not used the timer

Hi, I have not used the timer or charge start feature through ovms myself. If you let me know what build version you're running and age/battery size of your Leaf I can see if I spot anything in the code that may cause the issue for you.

Just a thought, as it appears the start charge message is coming from the App, do you slide it across once and slide back to the start the charge? Or leave it slid across?

Cheers Derek 

jbeuree
I'm on the latest build, 3.2

I'm on the latest build, 3.2.0.14. It's a 2015 SV model, with the 24kwh battery. I slid the charge indicator in the app (android) to the right to start the charge, and think I also tried to see what would happen by sliding it back, but it didn't appear to do anything. I'll try some different combinations, including not using the app at all, to try to isolate the exact cause.

markwj
markwj's picture
I suggest look at the logs

I suggest look at the logs (in debug or verbose mode) a little before what you show, to see if you can find out what initiated the charge. The logs you show are just the charge itself starting, not who/what requested that.

jbeuree
Ok, thanks for the suggestion

Ok, thanks for the suggestion. I was most concerned that this could happen all the time and wreck the battery, but I've done 2 charges since and they both worked normally, although the events look a little messed up to me (i.e. charge start and stop when plugging in but not charging, only a charge stop at the end and no charge finished). I'll try different variations each day to narrow down the cause and then crank up the logs to try to figure out why.

jbeuree
Whatever is causing the car

Whatever is causing the car to charge over and over happens very infrequently, but did happen again last night. We've had this vehicle 6 years, and it never did this before plugging in the ovms. I turned on logging and let it go through a cycle where it finished and started again on it's own, but don't see anything obvious in the logs. Is it possible the ovms is somehow interfering with the car's own communications and causing this to happen? Wondering what the best way to debug this would be. Maybe turn off can writes, if that's supported on the leaf?

Also, I do use the leaf's charge timer, which seems to still work fine with the ovms. In the case of last night, it was plugged in before the charge timer should have been in effect but looks like it started charging right away. Don't have logs from it being first plugged in but here's what a bit from it finishing charging and restarting:

2020-10-03 07:04:38 EDT V (70041238) v-nissanleaf: Range: ideal=112 km, est=94 km, full=94 km
2020-10-03 07:04:38 EDT V (70041238) v-nissanleaf: Time remaining: 0 mins to full
2020-10-03 07:04:38 EDT D (70041238) v-nissanleaf: Poll state: 3
2020-10-03 07:04:39 EDT V (70041718) gsm-mux: ProcessFrame(CHAN=1, ADDR=05, CTRL=ff, FCS=5c, LEN=79)
2020-10-03 07:04:39 EDT V (70041728) gsm-nmea: IncomingLine: $GNGNS,110439.0,4514.850943,N,07555.324123,W,AA,11,0.8,142.1,-36.0,,*52
2020-10-03 07:04:39 EDT V (70041728) gsm-mux: ProcessFrame(CHAN=1, ADDR=05, CTRL=ff, FCS=bf, LEN=78)
2020-10-03 07:04:39 EDT V (70041728) gsm-nmea: IncomingLine: $GPRMC,110439.0,A,4514.850943,N,07555.324123,W,0.0,191.3,031020,,,A*78
2020-10-03 07:04:39 EDT D (70041728) time: gsm-nmea (stratum 2 trusted 1) provides time Sat Oct  3 11:04:39 2020 (000000us) UTC
2020-10-03 07:04:40 EDT V (70042728) gsm-mux: ProcessFrame(CHAN=1, ADDR=05, CTRL=ff, FCS=5c, LEN=79)
2020-10-03 07:04:40 EDT V (70042728) gsm-nmea: IncomingLine: $GNGNS,110440.0,4514.850939,N,07555.324121,W,AA,11,0.8,142.1,-36.0,,*53
2020-10-03 07:04:40 EDT V (70042728) gsm-mux: ProcessFrame(CHAN=1, ADDR=05, CTRL=ff, FCS=bf, LEN=78)
2020-10-03 07:04:40 EDT V (70042728) gsm-nmea: IncomingLine: $GPRMC,110440.0,A,4514.850939,N,07555.324121,W,0.0,191.3,031020,,,A*79
2020-10-03 07:04:40 EDT D (70042728) time: gsm-nmea (stratum 2 trusted 1) provides time Sat Oct  3 11:04:40 2020 (000000us) UTC
2020-10-03 07:04:41 EDT V (70043758) gsm-mux: ProcessFrame(CHAN=1, ADDR=05, CTRL=ff, FCS=5c, LEN=79)
2020-10-03 07:04:41 EDT V (70043758) gsm-nmea: IncomingLine: $GNGNS,110441.0,4514.850937,N,07555.324121,W,AA,11,0.8,142.1,-36.0,,*5C
2020-10-03 07:04:41 EDT V (70043768) gsm-mux: ProcessFrame(CHAN=1, ADDR=05, CTRL=ff, FCS=bf, LEN=78)
2020-10-03 07:04:41 EDT V (70043778) gsm-nmea: IncomingLine: $GPRMC,110441.0,A,4514.850937,N,07555.324121,W,0.0,191.3,031020,,,A*76
2020-10-03 07:04:41 EDT D (70043778) time: gsm-nmea (stratum 2 trusted 1) provides time Sat Oct  3 11:04:41 2020 (000000us) UTC
2020-10-03 07:04:42 EDT D (70044768) events: Signal(vehicle.charge.stop)
2020-10-03 07:04:42 EDT D (70044768) pushover: EventListener: Handling event (vehicle.charge.stop)
2020-10-03 07:04:42 EDT I (70044778) pushover: Sending message Charge has stopped with priority -1
2020-10-03 07:04:42 EDT V (70044778) gsm-mux: ProcessFrame(CHAN=1, ADDR=05, CTRL=ff, FCS=5c, LEN=79)
2020-10-03 07:04:42 EDT V (70044788) gsm-nmea: IncomingLine: $GNGNS,110442.0,4514.850936,N,07555.324122,W,AA,11,0.8,142.1,-36.0,,*5D
2020-10-03 07:04:42 EDT V (70044788) gsm-mux: ProcessFrame(CHAN=1, ADDR=05, CTRL=ff, FCS=bf, LEN=78)
2020-10-03 07:04:42 EDT V (70044788) gsm-nmea: IncomingLine: $GPRMC,110442.0,A,4514.850936,N,07555.324122,W,0.0,191.3,031020,,,A*77
2020-10-03 07:04:42 EDT D (70044798) time: gsm-nmea (stratum 2 trusted 1) provides time Sat Oct  3 11:04:42 2020 (000000us) UTC
2020-10-03 07:04:42 EDT V (70044858) pushover: Msg: POST /1/messages.json HTTP/1.1||Host: api.pushover.net||Connection: close||Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8||Content-Length: 141||||token=af1jtp1xwum3ju1bc5nxdz88dhi23g&user=ups2nskoxvsvegpgmgvgwfjytjq3gs&message=Charge has stopped&priority=-1&title=2015LeafSV-1N4AZ&sound=
2020-10-03 07:04:42 EDT D (70044878) events: Signal(vehicle.charge.state)
2020-10-03 07:04:42 EDT D (70044878) pushover: EventListener: Handling event (vehicle.charge.state)
2020-10-03 07:04:42 EDT D (70044888) pushover: EventListener: No priority set -> ignore notification
2020-10-03 07:04:42 EDT D (70044888) events: Signal(vehicle.charge.mode)
2020-10-03 07:04:42 EDT D (70044888) pushover: EventListener: Handling event (vehicle.charge.mode)
2020-10-03 07:04:42 EDT D (70044908) pushover: EventListener: No priority set -> ignore notification
2020-10-03 07:04:42 EDT V (70045238) simcom: tx: f9 0d ff 3b 41 54 2b 43 52 45 47 3f 3b 2b 43 43 | ...;AT+CREG?;+CC
2020-10-03 07:04:42 EDT V (70045238) simcom: tx: 4c 4b 3f 3b 2b 43 53 51 3b 2b 43 4f 50 53 3f 0d | LK?;+CSQ;+COPS?.
2020-10-03 07:04:42 EDT V (70045238) simcom: tx: 0a cf f9                                        | ...             
2020-10-03 07:04:42 EDT V (70045258) gsm-mux: ProcessFrame(CHAN=3, ADDR=0d, CTRL=ff, FCS=69, LEN=111)
2020-10-03 07:04:42 EDT D (70045258) simcom: rx line ch=3 len=10  : +CREG: 1,5
2020-10-03 07:04:42 EDT D (70045268) simcom: rx line ch=3 len=29  : +CCLK: "20/10/03,07:04:38-16"
2020-10-03 07:04:42 EDT D (70045268) simcom: rx line ch=3 len=11  : +CSQ: 20,99
2020-10-03 07:04:42 EDT D (70045268) simcom: rx line ch=3 len=33  : +COPS: 0,0,"VIDEOTRON Hologram",2
2020-10-03 07:04:42 EDT D (70045268) simcom: rx line ch=3 len=2   : OK
2020-10-03 07:04:42 EDT V (70045718) gsm-mux: ProcessFrame(CHAN=1, ADDR=05, CTRL=ff, FCS=5c, LEN=79)
2020-10-03 07:04:43 EDT V (70045718) gsm-nmea: IncomingLine: $GNGNS,110443.0,4514.850936,N,07555.324122,W,AA,11,0.8,142.1,-36.0,,*5C
2020-10-03 07:04:43 EDT V (70045728) gsm-mux: ProcessFrame(CHAN=1, ADDR=05, CTRL=ff, FCS=bf, LEN=78)
2020-10-03 07:04:43 EDT V (70045728) gsm-nmea: IncomingLine: $GPRMC,110443.0,A,4514.850936,N,07555.324122,W,0.0,191.3,031020,,,A*76
2020-10-03 07:04:43 EDT D (70045728) time: gsm-nmea (stratum 2 trusted 1) provides time Sat Oct  3 11:04:43 2020 (000000us) UTC
2020-10-03 07:04:50 EDT V (70046718) gsm-mux: ProcessFrame(CHAN=1, ADDR=05, CTRL=ff, FCS=5c, LEN=79)
2020-10-03 07:04:50 EDT V (70046718) gsm-nmea: IncomingLine: $GNGNS,110444.0,4514.850933,N,07555.324122,W,AA,11,0.8,142.1,-36.0,,*5E
2020-10-03 07:04:50 EDT V (70046728) gsm-mux: ProcessFrame(CHAN=1, ADDR=05, CTRL=ff, FCS=bf, LEN=78)
2020-10-03 07:04:50 EDT V (70046728) gsm-nmea: IncomingLine: $GPRMC,110444.0,A,4514.850933,N,07555.324122,W,0.0,191.3,031020,,,A*74
2020-10-03 07:04:50 EDT D (70046728) time: gsm-nmea (stratum 2 trusted 1) provides time Sat Oct  3 11:04:44 2020 (000000us) UTC
2020-10-03 07:04:50 EDT D (70047678) events: Signal(vehicle.charge.start)
2020-10-03 07:04:50 EDT D (70047678) pushover: EventListener: Handling event (vehicle.charge.start)
2020-10-03 07:04:50 EDT D (70047688) pushover: EventListener: No priority set -> ignore notification
2020-10-03 07:04:50 EDT D (70047698) events: Signal(vehicle.charge.mode)
2020-10-03 07:04:50 EDT D (70047698) pushover: EventListener: Handling event (vehicle.charge.mode)
2020-10-03 07:04:50 EDT D (70047718) pushover: EventListener: No priority set -> ignore notification
2020-10-03 07:04:50 EDT V (70047728) gsm-mux: ProcessFrame(CHAN=1, ADDR=05, CTRL=ff, FCS=5c, LEN=79)
2020-10-03 07:04:50 EDT V (70047728) gsm-nmea: IncomingLine: $GNGNS,110445.0,4514.850931,N,07555.324122,W,AA,12,0.8,142.1,-36.0,,*5E
2020-10-03 07:04:50 EDT V (70047738) gsm-mux: ProcessFrame(CHAN=1, ADDR=05, CTRL=ff, FCS=bf, LEN=78)
2020-10-03 07:04:50 EDT V (70047738) gsm-nmea: IncomingLine: $GPRMC,110445.0,A,4514.850931,N,07555.324122,W,0.0,191.3,031020,,,A*77
2020-10-03 07:04:50 EDT D (70047738) time: gsm-nmea (stratum 2 trusted 1) provides time Sat Oct  3 11:04:45 2020 (000000us) UTC
2020-10-03 07:04:50 EDT D (70047738) events: Signal(vehicle.charge.state)
2020-10-03 07:04:50 EDT D (70047748) pushover: EventListener: Handling event (vehicle.charge.state)
2020-10-03 07:04:50 EDT D (70047748) pushover: EventListener: No priority set -> ignore notification
2020-10-03 07:04:50 EDT V (70048728) gsm-mux: ProcessFrame(CHAN=1, ADDR=05, CTRL=ff, FCS=5c, LEN=79)
2020-10-03 07:04:50 EDT V (70048738) gsm-nmea: IncomingLine: $GNGNS,110446.0,4514.850931,N,07555.324123,W,AA,12,0.8,142.1,-36.0,,*5C
2020-10-03 07:04:50 EDT V (70048738) gsm-mux: ProcessFrame(CHAN=1, ADDR=05, CTRL=ff, FCS=bf, LEN=78)
2020-10-03 07:04:50 EDT V (70048738) gsm-nmea: IncomingLine: $GPRMC,110446.0,A,4514.850931,N,07555.324123,W,0.0,191.3,031020,,,A*75
2020-10-03 07:04:50 EDT D (70048738) time: gsm-nmea (stratum 2 trusted 1) provides time Sat Oct  3 11:04:46 2020 (000000us) UTC
2020-10-03 07:04:50 EDT V (70049728) gsm-mux: ProcessFrame(CHAN=1, ADDR=05, CTRL=ff, FCS=5c, LEN=79)
2020-10-03 07:04:50 EDT V (70049728) gsm-nmea: IncomingLine: $GNGNS,110447.0,4514.850933,N,07555.324124,W,AA,12,0.8,142.1,-36.0,,*58
2020-10-03 07:04:50 EDT V (70049728) gsm-mux: ProcessFrame(CHAN=1, ADDR=05, CTRL=ff, FCS=bf, LEN=78)
2020-10-03 07:04:50 EDT V (70049738) gsm-nmea: IncomingLine: $GPRMC,110447.0,A,4514.850933,N,07555.324124,W,0.0,191.3,031020,,,A*71
2020-10-03 07:04:50 EDT D (70049738) time: gsm-nmea (stratum 2 trusted 1) provides time Sat Oct  3 11:04:47 2020 (000000us) UTC
2020-10-03 07:04:50 EDT V (70050728) gsm-mux: ProcessFrame(CHAN=1, ADDR=05, CTRL=ff, FCS=5c, LEN=79)
2020-10-03 07:04:50 EDT V (70050738) gsm-nmea: IncomingLine: $GNGNS,110448.0,4514.850935,N,07555.324126,W,AA,12,0.8,142.1,-36.0,,*53
2020-10-03 07:04:50 EDT V (70050738) gsm-mux: ProcessFrame(CHAN=1, ADDR=05, CTRL=ff, FCS=bf, LEN=78)
2020-10-03 07:04:50 EDT V (70050738) gsm-nmea: IncomingLine: $GPRMC,110448.0,A,4514.850935,N,07555.324126,W,0.0,191.3,031020,,,A*7A
2020-10-03 07:04:50 EDT D (70050738) time: gsm-nmea (stratum 2 trusted 1) provides time Sat Oct  3 11:04:48 2020 (000000us) UTC
2020-10-03 07:04:50 EDT V (70051238) v-nissanleaf: Range: ideal=110 km, est=92 km, full=94 km
2020-10-03 07:04:50 EDT D (70051238) v-nissanleaf: Poll state: 3

 

mdallaire
I just wanted to say I am

I just wanted to say I am seeing the same issue with my Leaf 2015 when starting the charge manually from the android app when there is also a charge schedule set. It will charge fully then keep charging until it reach my scheduled charge end time.

rysio
This seems to be happening to

This seems to be happening to me too. I think the charging effect is real as when this happened all night, and only shut off after my charge timer was off, when I drove to work in similar conditions as the day before, I had noticably more battery capacity left over. I worry this is then overcharging the battery which will lead to premature degradation.

2015 SL with 24kWh battery

I notice that whenever this happens, in my case the app/server reports 98% battery. Is it possible the app sees 98% decides the charge was interupted prematurely and tries to start again, the car shuts off at what it sees is 100% or over but app sees 98% so starts charge again etc? is it possible to set up the server to prevent it from sending a start charge command above say 95%?

I may have to disable commands writes from the server and use this only for monitoring, but that would be a bummer since I would loose a lot of the functionality that I wanted out of the OVMS. It's not worth it to risk premature degradation of the battery though!

I will try to catch my logs the next time this happens and hopefully someone wiser than me may have some insight.

If anyone has come across a cause or solution, please post it! I'm really not looking forward to having to disable my remote climate control and start charge!

jbeuree
Could just be coincidence,

Could just be coincidence, but I haven't had this happen since re-connecting the TCU, but without power. I was suspecting something to do with possibly having random canbus errors due to it not being terminated, so I reconnected it but with the power disabled. Really just a guess and the charging problem didn't happen often, so hard to judge if it actually made a difference.

As far as overcharging, not sure how much of a concern that would be. I've found the range seems slightly better if driven either right after charging, or even when interrupting a charge that's right at the end. Could just be a matter of having a warmer battery. Regardless, I'd still be worried about any wear affects this could have even just by constantly rebalancing the cells over and over.

Lenbok
Did anyone get to the bottom of this?

I installed my new OVMS into my 2014 Nissan Leaf a few days ago. I have only tried charging via OVMS twice, and neither I would consider it a sucess:

The first time, I had the leaf with it's internal charge limiter at 80%, and a scheduled charge set for the following day. OVMS does not have any charge limit set (either range or SOC). I plugged the charger in (it didn't initially start to charge, due to charge timer), and used the OVMS app to start the charge. I would expect that the car would charge to 80%, at which time the built-in charge limiter would kick in. What actually happened was when the charge got to 80% it entered the cycle of trying to charge over and over. Fail :-(

The second time, I set the leaf internal charge limiter to 100% and the OVMS charge limit to 75% SOC. Again, the next scheduled charge is set for a day later in the week. I plugged in the charger, and used OVMS app to start the charge. I would expect that OVMS should stop the charging once 75% is reached. Instead, charging continued until I manually stopped it at 79%.  (Edit: Answering my own question here -- while the documentation says that Leaf supports stopping charging, and the Web UI allows setting SOC/Range charge limits, it seems this feature to stop charging was only actually merged at the start of January, but my OVMS is running the most recent release, 3.3.001-33-g58d01654/factory/main, which predates that merge by a couple of weeks).

The Nissan TCU is unplugged (I did not disconnect 12v battery when unplugging, if this makes any difference and the car has some bogus state maintained).

Any ideas?

 

 

Drc38
Make sure your firmware is on

Make sure your firmware is on the latest 'edge' version and try again, the edge version has the ability to stop the charge based on the SoC set. Earlier versions didn't support stopping a charge from ovms.

Lenbok
Mostly worked this time

I updated to current edge firmware (3.3.001-282-gbd4919ca/ota_0/edge) and tested again. The car SOC is currently 79%, I set OVMS to stop charge at 81% SOC, and then started the charge using OVMS.

After the charge neared completion several minutes later I got a series of notifications/messages:

1: Target charge level reached (81%)

2: Charge Stopped (it included the SOC as 80%)

3: Charge level below target (80%)

4: Charging

5: Target charge level reached (81%)

6: Charge Stopped

7: Charge level below target (80%)

8: Charge stopped

 

The web UI battery config has an "Allow SOC Drop" option, which from my reading means that when enabled you can tell the leaf to re-start charging if the SOC gets below a particular level. I do not have this option set, so I would think that it shouldn't attempt to restart charging. Maybe there is a bug there?

 

 

 

 

Drc38
"Allow SOC Drop" is to

"Allow SOC Drop" is to prevent the behaviour you describe above, if you set it to say 5% then the SoC would have to drop below your setpoint - drop before it starts the charge again.

Log in or register to post comments