Welcome to Tesla Motors Club
Discuss Tesla's Model S, Model 3, Model X, Model Y, Cybertruck, Roadster and More.
Register
  • Want to remove ads? Register an account and login to see fewer ads, and become a Supporting Member to remove almost all ads.
  • Tesla's Supercharger Team was recently laid off. We discuss what this means for the company on today's TMC Podcast streaming live at 1PM PDT. You can watch on X or on YouTube where you can participate in the live chat.

Open Vehicle Monitor System (OVMS) - Technical Discussion

This site may earn commission on affiliate links.
That's exactly, what I was looking for. Thanks:)

One can setup the depth of the history in the settings. Max number is 10, unfortunately all these stupid door ajar messages erased the meager I was looking for:(

You can also set it up to send you text messages. That will queue up messages better (the door ajar messages aren't sent there).
 
Quick ACC question/issue:

I just updated the firmware on my OVMS to the latest version with ACC control -- previously it was running the latest version without ACC support.

Should I still be able to manually initiate a charge either from the VDS or OVMS if the car is at an ACC location and that location is enabled? At the moment, it appears the answer is no. From the VDS and from the OVMS app/SMS a charge will start and then the VDS will almost immediately display charge ended manually.

In the above scenario, it also appears that disabling the ACC location still prevents me from manually initiating a charge. To be able to manually initiate a charge, I had to disable then reset the module -- this doesn't seem right?

Am I missing something? Is it possible I've something configured wrong?

Thanks!
 
If ACC is enabled at a location, it will take over the charging. For example, if SOC limit is 90%, SOC is 91%, and you try to manually charge, acc will stop the charge.

Disabling acc for the location should be immediate. But, you should do that before plugging in (or unplug, disable, plug back in).
 
If ACC is enabled at a location, it will take over the charging. For example, if SOC limit is 90%, SOC is 91%, and you try to manually charge, acc will stop the charge.

Disabling acc for the location should be immediate. But, you should do that before plugging in (or unplug, disable, plug back in).

The disable response is immediate, but it appears to continue enforcing the policy until I reset the module. It didn't occur to me to try cycling the plug. Is the unplug-replug requirement a technical limitation in the vehicle or just the way OVMS is handling it?

Basically I'm looking to use ACC for winter storage instead of (in addition to?) Storage Mode. I dislike how low Storage Mode lets the pack get -- I've seen it down to 21%. I'd rather the pack go no lower than the 40s-50s, in case there were a prolonged power outage. Up to now I've been doing this manually using with a combination of Storage Mode and occasional manually initiated charging.

My plan was to use ACC to keep it at 50, which should work fine.

But I also wanted the option to manually fully charge the pack for balancing or prior to heading out to get the car. Since the car is offsite, unplug-{en|dis}able-replug isn't an option. However, it seems like disable, reset OVMS might be..?

Perhaps I'm over thinking it.

Thanks again for the help
 
I think it examines the disable/enable flag whenever a state transition occurs (eg; parked, driving, charging, etc). Closing the charge port should be sufficient to get it out of waiting-to-charge states. No need to reset.
 
Hi Mark et al,

I have a Roadster 2.0 and varsion 2 OVMS whose firmware is quite out of date (pre-ACC). I have had two instances now where it SEEMS that initiating a change in charging mode from the iOS app caused the Roadster to enter a fault state that prevented it from charging. In this state, it throws a 287 fault and the charge port light goes red. The OVMS can still see the car.

Tesla got involved the first time this happened a couple weeks ago. They replaced my HV controller, but the problem persisted. I delivered the car to them to work on, but as soon as they got it to the shop and plugged it in, the problem disappeared! The second time, yesterday/today, I debugged it myself. I was able to get the car back to normal by some combination of resetting the charge settings to "default" on the VDS, and also driving the car to a J1772 charger nearby and charging successfully there. That charger presents a 24A pilot signal, which is different from the 40A pilot presented by my RFMC at home. When I returned home, the RFMC would then charge the car normally.

As a precaution, I also removed the OVMS module from the car, and I am preparing to upgrade its firmware (which I have not yet done, but have the stuff necessary).

So my question is: does this hypothesis seem reasonable? Is there a known possibility of mismatch between some versions of Roadster firmware and OVMS firmware? Is this documented anywhere? I have just skimmed through this whole thread and saw no mention of anything like this.
 
Vger,

We had an issue several years ago where you could issue the command to start the charge when the car wasn't plugged in. That would put the car in a strange state where it thought it was charging. The workaround was to open and close the charge port door. The OVMS firmware itself was changed a few years ago, to add a validation check that pilot was present before sending the charge start command.

That is the only thing I've heard similar to your problem.

In general, OVMS just acts as a remote VDS. It simply sends the same commands that the VDS does. The top-up button on the VDS is the same function/command as start charge from OVMS.
 
Vger,

We had an issue several years ago where you could issue the command to start the charge when the car wasn't plugged in. That would put the car in a strange state where it thought it was charging. The workaround was to open and close the charge port door. The OVMS firmware itself was changed a few years ago, to add a validation check that pilot was present before sending the charge start command.

That is the only thing I've heard similar to your problem.

In general, OVMS just acts as a remote VDS. It simply sends the same commands that the VDS does. The top-up button on the VDS is the same function/command as start charge from OVMS.

Thanks, Mark. I will update the firmware in the OVMS, then try what I believe might have been the problematic sequence and check again. It is still possible, of course, that this is a red herring, but both times it happened, I had used the OVMS to put the car into storage mode remotely.

We shall see. If I can reproduce the issue after the firmware update, I will certainly let you and the community know. I leave for a couple of trips tomorrow, so I will not get to all of it for a couple weeks.

Thanks again!
V
 
I'm not certain the issues with OVMS starting charging are worked out. I just had a bad experience with that. Monday morning I woke around 4a.m. and thought... I'm going to be doing a long drive tomorrow. I should do a range charge because it's been a couple months since I have. So I picked up my phone and saw my car was plugged in and standard charged to full. So I changed to range mode and set 32A, then pressed the charge slider and I got the error that the car's charge port was closed, even though it was not. Going to the car screen it showed the charge port as white but earlier that night the standard charge had finished. I've noticed that changing the charge mode causes the app to report strange stuff for awhile. But in this case it was stuck not showing that the car was connected to the charger. I took the app to the settings/control screen to 'reset OVMS Module' and that took awhile but the app still would not recognize that the car was plugged in. I gave up and went back to sleep. Waking hours later the app was still not showing the car plugged in.
Versions are... (oh there is another bug... the vehicle info screen shows... Server 2.6.5/TR/V1 Car 2.6.5/TR/V1 App 3.2.2 (20140628) and it's android. I know the server and car versions are different but sometimes they show the same.)
 
I'm not certain the issues with OVMS starting charging are worked out. I just had a bad experience with that. Monday morning I woke around 4a.m. and thought... I'm going to be doing a long drive tomorrow. I should do a range charge because it's been a couple months since I have. So I picked up my phone and saw my car was plugged in and standard charged to full. So I changed to range mode and set 32A, then pressed the charge slider and I got the error that the car's charge port was closed, even though it was not. Going to the car screen it showed the charge port as white but earlier that night the standard charge had finished. I've noticed that changing the charge mode causes the app to report strange stuff for awhile. But in this case it was stuck not showing that the car was connected to the charger. I took the app to the settings/control screen to 'reset OVMS Module' and that took awhile but the app still would not recognize that the car was plugged in. I gave up and went back to sleep. Waking hours later the app was still not showing the car plugged in.
Versions are... (oh there is another bug... the vehicle info screen shows... Server 2.6.5/TR/V1 Car 2.6.5/TR/V1 App 3.2.2 (20140628) and it's android. I know the server and car versions are different but sometimes they show the same.)
If the charge port light was white, then it lost the pilot signal. You'd need to slide the connector back to reestablish communications.
 
OVMS unresponsive for 5 minutes after Parking?

I haven't found any mention of this, but it's a minor annoyance which has been bugging me for a while.

My OVMS generally works great. It does everything as advertised, and being able to set charging to end at a given time is the best feature for me.

The last few times I've gone to an EV-related car show, I have been asked for my mileage while filling out registration forms. Naturally, I whipped out my phone and sent a "STAT" SMS message. If less than five minutes had passed since parking, though, I would get no response. Further testing shows that OVMS is always unresponsive for five minutes after Parking.

Is anyone else seeing this?

Version info: Roadster 1.5, OVMS v2, Firmware 2.6.5 (Roadster-specific)