Smart EQ contactor switching cycles glitch

[glynhudson]

I've just been made aware of a glitch on the Smart EQ which can cause the contactor cycle counter to reset to 0. This bricks the HV. Apparently, the glitch can happen if the 12V runs low, or if unknown devices are detected on the ODB2 port. There has been a recorded case of this happening to an OVMS user. Although it's unknown if OVMS was the cause of this issue, but I wonder out of caution should OVMS use should be discouraged on these vehicles?

Documented examples:

• https://www.smart-emotion.de/forum/thread/4407-bms-glitch-for-contactor-switching-cycles/
• https://youtu.be/9ln-2q_ExEQ?si=Bd0lsy_UMCF1rrz4

Potential Error codes:

P1D2771, P1D277, P1D2785, P1D2871, P1D2877, P1D2885, P0DE71C

Fix

It's possible to reset the counter on the BMS, but unfortunately the BMS needs to be removed from the battery pack to do this. The video above documents this process.

These companies are offering a service to reset the BMS once it's removed

• https://www.smart-emotion.de/shop/product/67-smart-453-bms-reset/
• https://evclinic.eu/product/smart-451-ed-bms-a7899010100-repair/

[dexterbg]

Pulling in @zorgms @Dimitrie78

I remember some smart OVMS user contacting me about an unusal click sound he had with the OVMS attached. I suggested to first try disabling CAN write access, and if that doesn't help unplug the module. Unfortunately haven't heard again from him.

I see you already read the contactor cycles and provide these in metric xsq.bms.contactor.cycles. Would it help to monitor the cycle count and raise an alert if the counter changes by a higher than expected rate, or drops below a critical threshold?

Or is the glitch of the kind where the remaining life time just instantly drops to zero? (That would mean you basically cannot attach any device to the OBD port without risking this to happen…?)

Also found this in the thread:
https://www.smart-emotion.de/forum/thread/4407-bms-glitch-for-contactor-switching-cycles/?postID=52027#post52027

The counter-zero thing was only ever observed with a permanently installed faulty OBD plug triggering them [faults] constantly.

Is that a dependable source & observation?

[dexterbg]

Btw, if you add a data notification for the cycle counts, I can provide an anonymized data collection over all smart EQ registered on my server. That would enable you to analyse the counter state distribution and look for outliers.

[dexterbg]

FYI, these are the currently retained xsq.bms.contactor.cycles states on my MQTT hub:

200000,197696
200000,195854
200000,192390
200000,193405
200000,195822
0,0
200000,190457
200000,182064
200000,194569
200000,91613
0,0
200000,192639
200000,190670
0,0
200000,185116
200000,196194
200000,196835
200000,195801
200000,183324
200000,185207
200000,196043
200000,188511
200000,188480
200000,0
200000,186474
200000,194734
200000,186194
200000,196049

Assuming 0,0 is the uninitialized metric state, clear outliers are 200000,91613 and 200000,0, the latter looking like the exact condition…?

[zorgms]

I'm on vacation until around Pentecost Sunday. Just a quick note about the OBD port: Smart prohibits its use because an OBD tachograph rapidly resets the counter to zero. A warning at a certain counter value makes sense. Anything below 180,000 indicates an irregularity.

[glynhudson]

Or is the glitch of the kind where the remaining life time just instantly drops to zero? (That would mean you basically cannot attach any device to the OBD port without risking this to happen…?)

From reading forum threads, that's my interpretation.

FYI, these are the currently retained xsq.bms.contactor.cycles states on my MQTT hub:

Interesting, does that mean there have been 28 Smart EQ OVMS users connected to your server? How many of these are currently 'live'?

Just a quick note about the OBD port: Smart prohibits its use because an OBD tachograph rapidly resets the counter to zero

In that case, it sounds like OVMS support for this vehicle should never have been added. Should we pull OVMS support for this vehicle and contact users to recommend disconnection?

[Dimitrie78]

My understanding is that over 1,000 Smart users utilize OVMS, and there have been no issues of this nature reported among them. The error occurred solely as a result of using a trip recorder. This is why Smart/Mercedes removed the use of the OBD port from their warranty terms and conditions.
The root of the problem lies with the OBD-based trip recorder devices, as they transmit continuous queries—behavior that can lead to these anomalies.
Since OVMS only sends queries when the CAN bus is active—and not when the car is in sleep mode—it should not trigger this specific problem.

Nevertheless, I need to review the code again; a few improvements may still be necessary.
For one thing, I have noticed that when write access is enabled, the module actively sends queries immediately after a reboot—something it should not be doing.
Secondly, the 12V battery monitoring trigger for starting the air conditioning should be disabled by default. In the case of a newly configured module—where the 12V monitoring has not yet been calibrated—this setting can cause the air conditioning to start repeatedly, leading to unnecessary power consumption and a premature depletion of the usage counter.

[glynhudson]

Since OVMS only sends queries when the CAN bus is active—and not when the car is in sleep mode—it should not trigger this specific problem.

There has been a reported case of an OVMS user experiencing the issue.

[Dimitrie78]

Then I think it's more likely due to the dying 12V battery. Unfortunately, the Smart EQ is somewhat sensitive in that regard. There's also a good reason why Smart replaces the 12V battery every 3 years.

It would certainly be advisable to include in the description that Smart prohibits the use of OBD devices, as this can lead to such a problem.

[Dimitrie78]

I don't think this is a problem with the OBD adapter itself, but rather something else. With the Smart ED, when the 12V battery dies, the Smart keeps charging it until the high-voltage battery is completely broken and then deeply discharged.

[zorgms]

—where the 12V monitoring has not yet been calibrated—this setting can cause the air conditioning to start repeatedly, leading to unnecessary power consumption and a premature depletion of the usage counter.

After every restart, the ADC calibration is checked; if the 12V reading deviates by more than 0.1V, it is recalibrated as soon as the 12V battery begins charging.

[dexterbg]

My understanding is that over 1,000 Smart users utilize OVMS

Confirmed, there are well over 1,000 smart EQ active on my V2 server alone at any given time.

My 2 cents: pulling support for the smart from the OVMS altogether seems premature based on the currently available info. If just using the OVMS was a trigger, there would be multiple cases now given the size of the OVMS "fleet". For contrast, there's a post on the Going Electric forum mentioning this glitch caused several (!) new smarts at a car sharing service to continuously trigger their contactors every second, despite the device connected to the OBD port being a commercial & registered hardware.

I remember the guy that contacted me about the clicking noise also told me he previously got a couple of low 12V alerts, so that matches Dimitries assumption. The OVMS could then even help avoiding the issue -- that is, if users listen to the 12V alerts… another smart driver just asked me how to turn the 12V alerts off, he found them annoying. One of his alerts was showing a voltage below 10V… you can't help everyone.

I've found the original Mercedes notice on the issue in a smart forum:

This also explicitly describes a faster countdown, not an immediate clearing:

The use of an unauthorized OBD device may impair the function of the high-voltage battery's contactor aging counter and cause the counter to count back to "0" within a short time.

So monitoring the countdown rate would make sense. Aside from the alert, the module could also stop all CAN writes when detecting something odd happening, just to be on the safe side.

I think we should add this warranty notice in the user manual page on the smart. This is a rather specific mentioning of third party OBD devices by a manufacturer, I've heard of no other similar case yet. Any use of the OVMS is generally at own risk, but we should be explicit about this specific case, we should be clear about the OVMS being an "unauthorized OBD device" in the sense of the notice.

We could also add all info collected on the potential triggers of the glitch, and what the OVMS does to help detecting & avoiding them.

Dimitrie & Zorg, do you want us to delay the 3.3.006 main release until you've finished the code checks and included the cycle counter monitoring?

[zorgms]

I don't see any urgent need for action. I could implement something regarding the meter installation by Monday evening. What Dimitrie78 is referring to—the active bus state after a restart—has actually been included since version 3.0.0.5; the data is read, and then the bus goes to sleep, provided that one of the two canwrite options is enabled.

[dexterbg]

I've re-queried the retained MQTT metrics and mapped the vehicles to the previous report:

[2026-05-19]       [2026-05-23]

200000,185116      200000,185096
200000,196043      200000,0
200000,186474      200000,186448
200000,196835      200000,0
200000,192639      200000,192616
200000,182064      200000,182056
-                  200000,197185
200000,190457      200000,190418
200000,186194      200000,186194
200000,190670      200000,190645
200000,188480      200000,188460
200000,183324      200000,183306
0,0                200000,192810
200000,196049      0,0
200000,193405      0,0
200000,188511      200000,188486
200000,0           200000,195967
-                  200000,0
200000,192390      200000,192362
200000,91613       200000,85563       ← !!!
200000,197696      200000,197693
-                  200000,195014
200000,195822      200000,195802
0,0                0,0
200000,194569      200000,194567
0,0                0,0
200000,185207      200000,185185
200000,194734      200000,194728
200000,196194      200000,196172
200000,195854      200000,195842
200000,195801      200000,0

The outlier's cycle count has dropped by more than 6,000 in four days, this seems to be clearly indicating the issue. With this rate continuing, the cycle count will drop to zero in 14 days.

The 12V level doesn't look bad on the vehicle though, find attached the anonymized metric dump. The module is running the 3.3.006-4 release. Zorg, Dimitrie, please have a look especially on the xsq metrics to see if you can find any additional clues.

I'll inform the user about this finding. Whatever the reason, the user needs to be aware of the issue and try to stop it. I'll ask him/her to join the discussion.

mqtt-outlier-260523.txt

[homek1978]

I was just informed that I have this issue. Was getting some battery errors for quite some time but Mercedes checked it supposedly (it might have been a scam as the charged my 800 EUR for a checkup where they replaced virtually nothing). I will replace the 12V ASAP.

[homek1978]

Now it is at

xsq.bms.contactor.cycles 200000;81561