Welcome to Tesla Motors Club
Discuss Tesla's Model S, Model 3, Model X, Model Y, Cybertruck, Roadster and More.
Register

Open Vehicle Monitor System (OVMS) - Technical Discussion

This site may earn commission on affiliate links.
When the car is plugged in, but not charging, if I slide the "Slide to begin charging" thing on the icon of the charging connector on the Battery page in OVMS, it doesn't start charging, it just goes into the "Charging -- Prepare" state (according to the "stat" command) but never actually charges.
I should also say that if the OVMS app can cause the charging to start by doing whatever it does when Wakeup is triggered then it should also do that same operation when you slide the switch on the charge connector icon. I'll take a look at the code.
OK, after a couple of months delay, I have implemented a fix for this in the OVMS firmware. I've tested it on my Roadster 1.5 but I'd appreciate further testing by others, especially 2.x cars. You can flash my build with this change from here. If it doesn't work satisfactorily in some way you can switch back to the other OTA partition. If you'd prefer to build your own firmware, you can fetch my changes from the roadster-wakeup branch on GitHub.

In order to make a valid test, the car needs to be plugged in and ready to charge but waiting for a scheduled start time. If you've just plugged in the cable, you need to then wait for the car to go to sleep (that is, for the coolant pump to stop).

As proposed, the fix required issuing a "wakeup" CAN message first, but then before issuing the "start charge" message the firmware needs to track the car stepping through a sequence of states while it checks whether the pilot signal from the charge cable is present. During that time the status messages sent to the app need to not include the true status as indicated by CAN messages that indicate no pilot signal because that would cause the app to hide the charge connector icon. Instead the status is faked to keep the app happy until the car detects that the pilot signal is actually present, then we can issue the "start charge" message. With my new code the charge connector icon should show "PREPARE" for some seconds as the car gets ready, then charging should start. You can then stop the charge by sliding the slider on the app or the real one on the car if you don't want the charge to happen at that time. You might try repeating the test after the car goes back to sleep. You could also try a test when the car is already awake; that should start charging with less delay.
 
OK, after a couple of months delay, I have implemented a fix for this in the OVMS firmware. I've tested it on my Roadster 1.5 but I'd appreciate further testing by others, especially 2.x cars. You can flash my build with this change from here. If it doesn't work satisfactorily in some way you can switch back to the other OTA partition. If you'd prefer to build your own firmware, you can fetch my changes from the roadster-wakeup branch on GitHub.

In order to make a valid test, the car needs to be plugged in and ready to charge but waiting for a scheduled start time. If you've just plugged in the cable, you need to then wait for the car to go to sleep (that is, for the coolant pump to stop).

As proposed, the fix required issuing a "wakeup" CAN message first, but then before issuing the "start charge" message the firmware needs to track the car stepping through a sequence of states while it checks whether the pilot signal from the charge cable is present. During that time the status messages sent to the app need to not include the true status as indicated by CAN messages that indicate no pilot signal because that would cause the app to hide the charge connector icon. Instead the status is faked to keep the app happy until the car detects that the pilot signal is actually present, then we can issue the "start charge" message. With my new code the charge connector icon should show "PREPARE" for some seconds as the car gets ready, then charging should start. You can then stop the charge by sliding the slider on the app or the real one on the car if you don't want the charge to happen at that time. You might try repeating the test after the car goes back to sleep. You could also try a test when the car is already awake; that should start charging with less delay.
OK, I just tested this on my 2.0 (0693) and it did the job, but it required me to swipe the virtual charging slider twice. After the first swipe, the charging plug icon disappeared like before, but this time, it came back a moment later with the slider back in the left position and the car woke up. Status was "charging stopped". I waited a minute to see what the car would do, and once I was satisfied that it wasn't going to do anything other than be awake, I slid the slider to the right again and that time it began the charging cycle.

This two-step process is a huge improvement over what it used to do (which was to disable charging completely until I physically disconnected the charging cord and plugged it back in).

Thanks for working on this bug.

I'm running the app on Android FWIW.
 
@rudholm, the behavior you describe sounds just like what I experienced with the original code before my changes, so I wonder if somehow you are not running the new code. It should work better than that. I saw one time where the first slide did nothing at all, as if the app didn't really send anything, while the second worked as expected. But other tests worked the first time.
My firmware version is 3.2.016-240-g001b3182-dirty, but I see now that it was built before the commit and push so that is the same tag as the master branch would show.
Another explanation would be that the sequence of status changes on your car is enough different from what I saw and programmed for on my car that the faking of the status isn't complete. The charging plug icon disappears when the car reports no pilot signal, which is what my new code avoids. A third explanation would be some difference between the iPhone and Android apps.
Do you have an SD card installed in OVMS and would you be able to issue console commands to turn on some logging to a file there?
Thanks for testing.
 
@rudholm, the behavior you describe sounds just like what I experienced with the original code before my changes, so I wonder if somehow you are not running the new code. It should work better than that. I saw one time where the first slide did nothing at all, as if the app didn't really send anything, while the second worked as expected. But other tests worked the first time.
My firmware version is 3.2.016-240-g001b3182-dirty, but I see now that it was built before the commit and push so that is the same tag as the master branch would show.
Another explanation would be that the sequence of status changes on your car is enough different from what I saw and programmed for on my car that the faking of the status isn't complete. The charging plug icon disappears when the car reports no pilot signal, which is what my new code avoids. A third explanation would be some difference between the iPhone and Android apps.
Do you have an SD card installed in OVMS and would you be able to issue console commands to turn on some logging to a file there?
Thanks for testing.
I guess I should have included this:
Firmware: 3.2.016-240-g001b3182-dirty/ota_1/main (build idf v3.3.4-845-gd59ed8bba-dirty Jun 28 2021 09:06:51)

I do have console but I don't have an SD card installed.
 
I guess I should have included this:
Firmware: 3.2.016-240-g001b3182-dirty/ota_1/main (build idf v3.3.4-845-gd59ed8bba-dirty Jun 28 2021 09:06:51)

I do have console but I don't have an SD card installed.
It is also possible to collect the CAN log over the network as an alternative to the SD card if the following instructions would work for you:
On the console enter the following command: can log start tcpserver transmit crtd :3000
If you have a Mac or Linux computer, receive the CAN log stream with the following command:
nc 192.168.1.74 3000 | tee canlog.crtd
where the IP address is that of your OVMS unit. There may be a Windows-ish way to do this but I don't know the details.
On the console enter the following command: log level info ovms-server-v2
This shows what is being sent to the app.
Then do the test of starting the charge while the car is asleep.
Stop the logging with these commands:
can log stop
log level none ovms-server-v2
Collect the console output and the canlog.crtd file to send to me via PM or email.
 
Welcome to TMC @Botbldr13. Not sure if the cooldown command has been ported over to v.3 yet, right @slcasner? At least, not yet as of Feb '19 here...

Those parameter settings in the app remain from the v2 implementation of OVMS and not all of it has been ported over to the v3 implementation. In particular, ACC is not there yet. I've done some work on this, but that got deferred by another project. Planning to get back to it now...
 
Welcome to TMC @Botbldr13. Not sure if the cooldown command has been ported over to v.3 yet, right @slcasner? At least, not yet as of Feb '19 here...
Correct, fully automated cooldown, for example upon plugin at a particular location, is not implemented yet. However, ...
I am on OVMS V2 - With the car plugged in, in OVMS messages, I type (without the quotes) "charge cooldown".
This is implemented in OVMS v3. In the OVMS app, touch the Messages tab at the bottom, then enter the message "charge cooldown" (without the quotes). You should make sure the car is awake first, which it would be if you just plugged in the cable.
 
Correct, fully automated cooldown, for example upon plugin at a particular location, is not implemented yet. However, ...

This is implemented in OVMS v3. In the OVMS app, touch the Messages tab at the bottom, then enter the message "charge cooldown" (without the quotes). You should make sure the car is awake first, which it would be if you just plugged in the cable.
I have OVMS v3. I just plugged in the car and typed in charge cooldown right after I plugged it in and got a message back "error: could not start cooldown". I tried it again after I heard the sounds of it working (sounded like cooldown)--same message. BUT--I hadn't been driving. I wonder if the car needs to be hot to work? Will try again.
 
I have OVMS v3. I just plugged in the car and typed in charge cooldown right after I plugged it in and got a message back "error: could not start cooldown". I tried it again after I heard the sounds of it working (sounded like cooldown)--same message. BUT--I hadn't been driving. I wonder if the car needs to be hot to work? Will try again.
That error message is returned for any of three conditions: the battery is already cool enough, or the car is ON, or the chargport is shut. For your test scenario, it would have been the first one. The default threshold for cooldown is 30 C = 86 F. The sounds you heard must have been the start of normal charging as a consequence of plugging in (assuming you don't have a scheduled start time set for that location.)
 
  • Like
Reactions: Timothy
Well, I just plugged it in and after figating a DCM FW: HCS Failed Warning….. reducing amperage and calling for “charge cooldown”….. 992 slipped into Range Charge at 12 a and is doing ok for last fifteen minutes.
I have been in this forum since 2011 under name Botbldr45 (they won’t let me use my name anymore.. go figure) and have always respected the participants and posts. Occasional trolls or shorts excluded I thank you all for your help.
 
That error message is returned for any of three conditions: the battery is already cool enough, or the car is ON, or the chargport is shut. For your test scenario, it would have been the first one. The default threshold for cooldown is 30 C = 86 F. The sounds you heard must have been the start of normal charging as a consequence of plugging in (assuming you don't have a scheduled start time set for that location.)
I'll try again when the car is hot after a drive. Thanks!
 
Well, I just plugged it in and after figating a DCM FW: HCS Failed Warning….. reducing amperage and calling for “charge cooldown”….. 992 slipped into Range Charge at 12 a and is doing ok for last fifteen minutes.
Range Charge at 12A is the expected behavior for the cooldown algorithm, so that looks good. I have found that the cooldown was not always effective on my car, though. It ran through several cooling cycles without getting the temperature down below the threshold. Instead I made the mod to add a switch that activates the solenoid to send cooling to the battery. After getting back from a drive where the battery is hot I leave the car running, turn on the A/C and flip that switch. The battery cools down pretty quickly without using too much charge.
 
The cooldown algorithm cycles in and out of Range mode at 12 amps because that seems to cause the car to cool the battery more aggresively so that all of the energy goes to cooling rather than filling the battery. It's a bit of hokus-pokus, though. The motivation is to cool the battery while using the minimum amount of energy, presuming that this cooldown may be requested during the afternoon/evening hours when electricity rates are higher. Then the charging to fill the battery would be done as a separate scheduled charge later.
 
Range Charge at 12A is the expected behavior for the cooldown algorithm, so that looks good. I have found that the cooldown was not always effective on my car, though. It ran through several cooling cycles without getting the temperature down below the threshold. Instead I made the mod to add a switch that activates the solenoid to send cooling to the battery. After getting back from a drive where the battery is hot I leave the car running, turn on the A/C and flip that switch. The battery cools down pretty quickly without using too much charge.
Wow, good idea.... can you PM specs, diagram...... how you did it. Its been pretty hot up here in Sedona and that idea sounds great.