Thanks, Rene! After some testing: Solution was to disable and enable back the digital services. After that all sensors a updated again. Was too easy! Thanks again!
Hi Rene,
thanks for the great work ![]()
I haven’t used the integration for a while, so I updated to v0.28 recently.
The recent car data seems to be avaialble (odometer, average speed is up to date), but all entities are not available somehow and I cannot use them:
Any idea what the reason could be?
Thanks
Markus
Hi Markus,
I propose that you enable the debug log (click on the three dots on the integration page upper right corner). Click then on reload the integration. Wait two minutes. Disable the debug and you will get a log file. Send me the log via email [email protected]
Or open a issue on GitHub and share all the requested data.
Thanks @ReneNulschDE for the great work to keep that integration alive! Works stably again since the last v0.28 update.
But there is one point bothering me for a while, about charging status. Until the latest trouble it worked well by evaluating the Chargingactive/Chargingstatus attributes of the ‘Range Electric’ sensor, but for some reason sticks to ‘False’ resp. ‘3’ for a while. Independent if charging or not, values do never change.
Do others see the same effect? Do I miss something and there is a new way to evaluate the charging status?
Hi,
Please see the latest posts. In all the cases it helped to deactivate and reactivate the digital services in the official mb app.
Any news here ? Can I access the raw json data somehow to pull out the data via json sensor ?
I have answered your mail on 07-23. you need to enable the sensors again.
Hi Rene,
I was about to send you the logs, but surprisingly – everything is working now! Not sure what changed, but it seems to have resolved itself.
Thanks a lot anyway for your help!
Markus
I have published a new version v0.29.0 - Release No.: 115…
What’s New
New sensor "Selected Charge Program" (click for more details)
| Internal value | UI value |
|---|---|
| 0 | Standard |
| 2 | Home |
| 3 | Work |
New sensor "Charging Status" (click for more details)
| Internal value | UI value |
|---|---|
| 0 | charging |
| 1 | charging ends |
| 2 | Charge break |
| 3 | unplugged |
| 4 | failure |
| 5 | slow |
| 6 | fast |
| 7 | discharging |
| 8 | not charging |
| 9 | slow charging after reaching trip target |
| 10 | charging after reaching trip target |
| 11 | fast charging after reaching trip target |
| 12 | unknown |
Fixes
- Max Soc gets not updates when the selected charge program changed (esp. when location based charge program changes happen)
- Warning in the HA-Log after update to HA 2025.08 (
Detected that custom integration 'mbapi2020' relies on ContextVar) - (Binary)-Sensors get created on runtime now whenever the MB API delivers initial sensor values after the load of the component was completed already.
- Change debug log / diagnostic report to exclude two new cases introduced in v0.28
China is still not available. I got some input and will try to bring it back in one of the next releases.
Special thanks to all the sponsors (BuyMeACoffee, Github) and everyone who starred the repository.
Hi Rene,
Since around 19:00 Bulgarian time today, my lock entity (lock.e1070hk_lock) started showing as Unknown in Home Assistant.
• Remote lock/unlock commands still work fine from HA and from the official Mercedes Me app.
• The problem is only with the status not updating in HA (always unknown).
• Tried full HA restart, reloading the integration, and complete reconfiguration (re‑auth), but the issue persists.
• I’m on version 0.29 of the integration, but also tested rolling back to 0.28 – same result.
• Other entities (fuel, odometer, etc.) still update normally.
Environment:
• Home Assistant Core: 2025.7.4
• Supervisor: 2025.07.3
• Operating System: 16.0
• Frontend: 20250702.3
• Integration: mercedesmeapi v0.29 (tested v0.28 too)
• Install method: HACS
• Vehicle: C220 Facelift W205 - 2018 year
Could there be a change in the Mercedes Me API affecting only lock status reporting? Or do you have any suggestions for debugging why the status would remain unknown while remote control still works?
Thanks for your great work on this integration!
Same here, but a bit later (22:01:46 CEST to be exact). I assume it’s an issue with the Mercedes backend.
Lock status sensor is functioning normally and accurately reporting its current state. At present, it is in the Locked state, and status updates are being successfully received in Home Assistant — in contrast to the remote control, which is currently experiencing issues.
Thanks for reporting - I see this issue in my environments too. Let me analyse it.
Solution:
I have published a bugfix release v0.29.1. See here for more details.
Analysis:
- Since 2025-08-04 5am (GMT) the attribute “doorLockStatusOverall” is not reported by the API anymore.
- This attribute is used to initialise the LOCK and show the current status
- Whenever the attribute is not available the lock is not created.
Workaround:
Use the states of the lock sensor and use the HA-services/actions to execute lock/unlock actions…
Hi René,
First of all, thank you for your great work on the Mercedes integration for Home Assistant.
I’m seeing a repeatable issue where triggering the lock/unlock entities from HA appears to put the Mercedes backend into a bad state. After a few HA-triggered lock/unlock commands, the remote controls (Lock/Unlock, Flash lights, etc.) stop working even in the official Mercedes me app, until Mercedes support “fixes/reset” something on their side.
Vehicle/Setup
- Car: Mercedes C-Class W205, facelift (09/2018), 4G TCU (Hermes)
- Region: EU (Bulgaria, UTC+3)
- HA: Home Assistant OS (Green), version:
- Integration: Mercedes me 2020 by René, version:
What happens
- Remote controls work normally in the official app.
- I use HA lock/unlock a few times (via
lock.e1070hk_lock). - Shortly after, remote commands fail in the Mercedes me app as well. Status updates still come through quickly, but commands don’t execute (backend error).
- Mercedes support confirmed there was a “backend activation logic error” for my VIN; after they fixed it, everything worked again.
- After a few uses via HA, the issue reappeared the same way.
Notes from Mercedes support
- They asked me not to re-activate services on my side.
- They suggested driving ~20 minutes and then trying another remote command.
Request
- Could you please check if there have been any API/backend changes that might affect how the integration sends lock/unlock (e.g., endpoints, wake-up/MT-SMS flow, throttling/rate limits)?
- Is there recommended throttling or a “safe interval” for lock/unlock to avoid tripping backend protections?
- Would it help to temporarily disable lock/unlock in the integration until this is clarified?
I can provide precise timestamps (UTC+3) for failed and successful attempts, plus HA debug logs and my VIN via DM if needed.
Thanks a lot for looking into this!
Best regards,
Konstantin
Hi,
Thanks for this report. I have never seen this and I’m unlocking/lock my car always with my watch (the car is a little bit younger but not that much.
Yes, I will check the API communication again - and it would be great if you could enable the debug log (via email to [email protected]). Please try it to reproduce this in the official app too…
It is always good to check the car-sensor - this sensor has some attributes with the latest status updates of a command execution.
I will come back…
Best Rene
@kkapchin : I have checked the API Call. It’s the same like in the app. Do you have the debug log or checked the app?
Feature request: Add sensors to assist in determining whether the data is fresh.
I’d like to have a better sense of whether I can trust the status of the door locks and other entities because they have been recently updated or the integration still has an active connection to the server. While traveling recently, my vehicle was offline for over a week but the MB integration was none the wiser and continued to show stale data which was kind of confusing.
For the moment, I’m using the car sensor’s last_message_received attribute to determine when the last communication occurred. If it is recent then I have more confidence in the information. I just show this in my dashboard as a badge that shows the duration since the last message and it is colored green, yellow, or red according to how long ago the message was.
For better accuracy, I’d like to check whether the integration is even able to communicate with the server but I don’t see a sensor or attribute for that. It might be sufficient to report the value of websocket.connection_state somewhere. I can see that the MB integration publishes the connection state as system health information but it doesn’t seem to do publish it as an entity.
I think I might be able to infer the connection state by checking whether the door lock or signal position entity is unavailable but that’s feels a bit indirect. And maybe there’s a more convenient way to signal freshness that others would find useful too.
What do you suggest?
Thanks!
Addendum
Here’s the little template sensor I just created to assess freshness.
{% set connected = states('button.signal_position') is not none %}
{% set time = state_attr('sensor.car', 'last_message_received') | as_datetime(none) %}
{% set delta = none if time is none else now() - (time | as_local()) %}
{% if not connected or delta is none %}
none
{% elif delta < timedelta(minutes = 5) %}
fresh
{% else %}
stale
{% endif %}
Hi,
Its not so easy to show this in one sensor.
We have different scenarios:
- The HA-component → MB-Server connection is not possible → last_message_received is a good indicator (But I can add a diagnostic sensor that shows the websocket/fallback-possible state)
- The connection between the car and the MB-servers is not possible → there is no “one”-flag for this in the messages that we receive via the API. I see the following options:
- create a new (diagnostic)-sensor that shows the highest update timestamp from all attributes (The API delivers for each value the latest_update ts)
or
Im down again. Wont authenticate. I logged into mbusa web app, so I know my email and password are correct. I correctly set North America. I deleted the integration and reinstalled the newest iteration 29.1 and restarted. All per instructions. INVALID AUTH… I hate posting this to you as I know you are just hammered working on this. I appreciate your help and support as always. Respectfully, Phil
The Auth server is answering with “GOTO_LOGIN_LEGAL_TEXTS” in the US. Could you please try to login with this account on the official website and check if you have to accept new data privacy rules? I can’t check in detail right now as I’m sitting in a train. (if the mbusa site does not show the dialog, try to login in the German version www.mercedes-benz.de - here I see the confirmation dialog with an us-account)





