Almost everything in this release was contributed by the community — a big thank you to @Maxooo and @paludi for building, testing and submitting these changes.
What’s Changed
New (Experimental): Window control via cover entities
Contributed by @Maxooo in #423 — thank you very much for this feature!
This feature is experimental. It has only been tested on a small number of vehicles so far. Entity states, reported positions and the behavior of the commands may change (or be removed again) in a future release. Please report your experience — good or bad — in the issues or forum.
Adds a new cover platform with up to five entities per car:
Windows – all windows at once
Window front left / front right / rear left / rear right – individual windows
What you can do:
Open / Close – uses the existing WINDOWS_OPEN / WINDOWS_CLOSE commands
Set position – only for cars that report the variableOpenableWindow capability
Notes and known limitations:
A security PIN must be configured — opening or moving windows raises a validation error without it.
Entities are only created if the car reports the required capabilities. With the Disable capability check option enabled, all entities are created regardless (North America).
The reported position is an approximation of the car’s window status, not a real percentage: closed → 0, ventilating → 10, intermediate → 50, open → 100.
After a command the entity shows the expected position for a short confirmation period until the car reports its new status.
If you don’t want these entities, you can disable them individually in Home Assistant (Settings → Devices & Services → Entities).
Bug Fixes
Contributed by @paludi in #425 — thank you for tracking this down and fixing it!
Preclimate status is reported correctly again on the new vehicle_status_updates (VSU) data path introduced in v0.38. VSU delivers precondNow as an enum and precondState as a nested message instead of the plain booleans the legacy VEP path used, and proto3 omits default values in JSON — both cases are now handled, so the preclimate sensor no longer stays off while preconditioning is running. (@paludi, #425)
Removed
SSL workaround from v0.38.2 removed. Mercedes-Benz has fixed the certificate chain on their servers, so the bundled Let’s Encrypt cross-signed root and the custom SSL context are no longer needed. Nothing changes for you — connections keep using the standard system trust store. (@ReneNulschDE)
i have published a bugfix release v0.39.1 to fix one bug with the new covers:
Bug Fixes
Windows cover shows the correct state again. The summary Windows entity reported the exact opposite of reality: it showed the windows as fully open while they were closed, and as closed as soon as a window was opened. The individual window entities were not affected. (#427, reported by @AmyKincaid in #426)
Window entities no longer show a made-up position for cars that don’t report a status for all four windows.
Note
The window cover entities are still experimental — please keep reporting anything that looks wrong in the issues or the forum.
I just installed this component for our Mercedes GLC SUV 200 4MATIC Star Edition.
Unfortunately there is no indication if the rear door that opens the luggage/cargo area is open or closed. Is that not possible? It would be very nice to have this to be able to check to make sure that the garage car port isn’t closed when this read door is closed. I don’t see it for the other doors also but that is not that important. Only for the roof I can see the status.
My car started discharging if the cable is plugged in to the car. But it would not if I stopped the charging from the app. So I tried to find a way to do that from the HA integration, but was unable to do so.
I also found that i was unable to set the maximum SOC for charging (That was in my attempts to pause the charging). Looks like a bug.
At the end Claude and me (Claude for the coding and me to steer) worked out how i could do it but it required some changes to the code.
I can now:
Set my GLC400e SOC for the different charging modes
Stop charging by unlocking the cable from the car.
Resume charging by activating the door lock again.
I can create an issue in github with the patch file and detailed explanation attached?
P.S. The workshop had a slot at the end of the month, so it should get fixed as it’s not normal.
New action mbapi2020.charge_coupler_stop. It ends the running charging session and unlocks the charging cable, the same way the “stop charging” button in the Mercedes me app does. Your security PIN is required. (#436, contributed and tested on a GLC 400e by @johanvdk1, from #433)
Bug Fixes
Setting the charge target no longer switches your charge program. Asking for a maximum state of charge without naming a program used to quietly move the car to Standard, even if it was running Home or Work. It now keeps the program the car is currently on. Please read the note below — this changes behaviour for existing automations. (#434, reported by @josephdouce in #229)
Setting the charge target now works on cars that previously refused it. Some vehicles — for example the GLC 400e — rejected the action with a “feature not available” warning even though the car can set a charge target perfectly well. (#435, contributed and tested on a GLC 400e by @johanvdk1)
The new action is now shown with a proper name and description in all supported languages instead of an internal identifier.
Window cover entities show the correct position again while a window is in the intermediate airing position. (#432)
Entities are no longer set up twice after a slow start.
Also new
Binary sensors for the deck lid. (#431)
[!IMPORTANT] Breaking change: check your charge target automations
This only affects you if you use the Set maximum state of charge action (mbapi2020.battery_max_soc_configure) without filling in the Charge program field.
Before: the action always applied to charge program Standard (0) and switched the car to it.
Now: the action applies to whichever program the car is currently running, and leaves that program active.
What to do:
If you only ever use Standard anyway, or you already fill in the Charge program field: nothing to do.
If you have an automation that relied on the old behaviour — that is, you were using this action to force the car back to Standard — set the Charge program field to 0 explicitly. That restores exactly what you had before.
Note that the car always activates whichever program you configure. There is no way to change an inactive program’s target and leave it inactive — that is how the Mercedes service works, not something this integration can change.
[!NOTE] About stopping charging and the charging cable
When you run the new Stop charge coupler action, the car ends the session and unlocks the cable so you can unplug it. Left alone, it stays stopped — it does not restart on its own.
**There is no “resume charging” action, ** but one workaround has been reported: if the cable is still plugged in, sending the ordinary Lock doors action re-engages the cable latch and charging resumes. This was observed on a single vehicle (a 2023 GLC 400e) and is not an officially supported function, so please try it on your own car before relying on it in an automation. If it works — or doesn’t — on your model, a short note in the issues would be very welcome.
As with every command that can affect the car physically, your security PIN must be set in the integration options or passed to the action.
New (Experimental): Window control via cover entities
Bug Fixes
Removed
New: stop charging and release the cable
Also new