Mercedes Me Component

Hallo Rene,

I kind of confirmed your observation, as I restarted HA during the time my car was charging, and the sensor.XXX_charging_power was populated.

Regarding your question: For parameters that tend to change quickly and infrequent (i.e. charging power - jumping from none to 11kW, to 150kW or so), I would prefer a “0” as the default.
For parameters that tend to change slowly (i.e. (average) consumption), your idea of using the last known value seems the right idea.
Or could a “none” (or the HA equivalent) work here?

On a related note: I noticed that the attribute “chargingstatus” (inside sensor.XXX_range_electric) looks like an integer, but is coded as a string.
Is that something that the MB API spits out, or a conscious decision on your part? I’m good either way, just did cost me some hours figuring out why my comparison to 0 (as the number) failed.

Its working fine. I had to check this: Disable capabilities check
Then I could see alot more settings. Thanks one million for this add-on

Hi @kvast ,

thanks for the feedback. Could you give a little bit more background on what was missing before you enabled “Disable cap checks”? I implemented this option for US market some years ago and it should have no effect in Europe.

BR Rene

Hi @Thomas01

thanks for your feedback. Let me try to implement this, I will start with the “0”-Default Value sensors…

Regarding:

Yes, all the values should be strings as the MB-API delivers the values as string. (and the API gives also a hint regarding the type but I never found the energy or value to implement this) - Therefore: All attributes should be handled like strings.

BR
Rene

I could just see if car was locked, windows etc. Dont remember all, but now it works super

Hi,

just noticed the update of the integration, with the included buttons for the pre-entry climate.

I just want to share my previous solution, a simple toggle switch, and looking for both the commanded pre-entry climate, as well as the timer based one.

switch:
  - platform: template
    switches:
      eqs_precond:
        friendly_name: Pre-entry Climate Control
        value_template: "{{ state_attr('sensor.XXX_range_electric', 'precondNow') or state_attr('sensor.XXX_range_electric', 'precondActive') }}"
        icon_template: mdi:air-conditioner
        turn_on:
          service: mbapi2020.preheat_start
          target: {}
          data:
            type: '0'
            vin: W1Kxxx
        turn_off:
          service: mbapi2020.preheat_stop
          target: {}
          data:
            vin: W1Kxxx

Thanks for the continued work,

Thomas

2 Likes

Sorry but im new to HA. can you share on how I can create a button that starts the pre-heater and indicate the its on?

Put the code I shared into configuration.yaml (if you already have a section called “switch:”, put the code without the switch: part below your definition, before the next section starts).
Do not forget to change the sensor.XXX to your sensor name, and change the vin W1Kxxx to your VIN.

418, message=“I’m a teapot”,

The integration is not working right now. For some of you the teapot error is not new, means MB changed their APIs again and gave me a christmas present…

Update 1: The code in the master branch on github should work for Europe again. Working on the other regions and plan to push a release soon.

1 Like

I have published an Hotfix Release to address the teapot error. As always something new was in the making and is part of the release too. (Even it is not 100% final - but should work)
v0.9.8 - Teapots, Windows, Translations Latest

IMPORTANT

Please open your MB mobile app and check if you have to accept new terms & conditions.

Fixes

  • Teapot error message fix for (hopefully) all regions (fixed: #159) - Can’t test this for all regions but US and EU looks good
  • The option to reload the component in the frontend was removed for now - please restart HA in case of problems (fixed: internal)
  • FIN/VIN is masked in the homeassistant.log now

New

  • Some attributes of the Lock sensor have translated names and values now. This is in the frontend only and should have no impact on automations, scripts and so on. English only. Use the developer-tools/states function to see the original values if needed.

Internal

  • There is an early support for default value handling for sensors. Its disabled for now but should solve the “missing sensor at startup”-problem in the future. (In case you miss for example the chargingkw sensor, get in touch with me whenever you want to test this)

Great, will this on short term be pushed to HACS as well, or would you advice me to install this manually on HA?

You can click on “Update information” in HACS and then you should get a notification few seconds later about the new version.
image

1 Like

Hallo Rene,

thanks for the update.
Thanks for the quick fix. works again (german user).

There is an early support for default value handling for sensors. (…) get in touch with me whenever you want to test this)

Can I test this?

Hi Thomas,

I will send you a private message with some instructions over the weekend.

BR
Rene

1 Like

There are also geo-coordinates offered in the API. Is it planned to also transmit them to home assistant?

Hi @ssonder,

Welcome in this community and the MB thread.

The coordinates are published via the device tracker since several years already. Please check your available device trackers.

First check if the location data is available in your MB mobile app. If not check the purchased licenses.

On December 15th, my Mercedes Me (mbapi2020) all of a sudden stopped working: There is no error message in the integration or the device, but all entities are ‘unavailable’.
I don’t find error messages when I enable debug loggin on the intergation. Just these messages:

2023-12-20 11:01:12.885 DEBUG (MainThread) [custom_components.mbapi2020.websocket] Got notification: assigned_vehicles
2023-12-20 11:01:12.894 DEBUG (MainThread) [custom_components.mbapi2020.websocket] Got notification: apptwin_pending_command_request
2023-12-20 11:01:27.883 DEBUG (MainThread) [custom_components.mbapi2020.websocket] Got notification: assigned_vehicles
2023-12-20 11:01:27.892 DEBUG (MainThread) [custom_components.mbapi2020.websocket] Got notification: apptwin_pending_command_request

Can someone tell me how I should try to find and correct this issue?
Thanks in advance

Hi @WimG ,

In the 15th MB changed their API endpoints and a few hours later a new version of this component was released.

Check the postings in this thread and make sure you installed the latest version

BR
Rene

Hi Rene,
thanks for the reply.
One of the actions I did to try to solve the issue, was indeed to upgrade to the latest version. Both home-assistant and the MercedesMe2020 code.
I tried and tried again re-configuring the integration and never got it working. I did notice that the integration saw no problems but no entities were active.
In home-assistant.log (now already replaced by a new version), I noticed that the Mercedes cloud api reported no cars found, with the data sent to it.
In the end I deleted the configuration and the .mercedesme-token-cache and reconfigured everything. Than it worked and the car’s details all came back correctly, with the same name as before.
I don’t know what was at the root of all of this and I’m afraid the data to find out are already gone.
But I’m a happy user again.
Happy holidays,
Wim

1 Like

I have published a new minor release v0.9.9 to keep up with some changes in HA 2024.01.

Notable changes:

  • Sensor “Charging Power” gets created even if the API does not provide values at HA startup.

Fixes:
Removal of a couple of deprecation warnings that otherwise would appear in Home Assistant 2024.1.0

Notes:
The sensor “charging power” is created for all vehicles, even if the vehicle has no charging options. Please ignore or hide the sensor if needed. Thanks to @Thomas01 and @Markus76 for testing.

3 Likes