Mercedes Me Component

thanks for pointing me in the right direction. It works and is really a big benefit! Where can I buy you a beer?

1 Like

Hi, is it possible to disable a scheduled preconditioning with the integration? I used

preheat_start_departure_time

to activate it, but I am not sure how to disable it.

Hi @lordofthewinds ,

This is not possible with the current release. The next release will have a new service “preheat_stop_departure_time”.

The code is part of the master branch already, feel free to test.

BR
Rene

Hi @modem-man-gmx ,

sorry, I missed your message - I’m not so deep in the different docker deployment options as I’m running my environments with the plain core. However, the component has only one dependency to protobuf and this is supported on armv8.

You will have to use HACS as I’m not providing a container for this.

BR
Rene

Hallo Rene,

I noticed that (at least on my car), the sensor.XXX_charging_power seems to stop working (around 27 November 2023).
Curiously, the attribute ChargingPower inside sensor.XXX_range_electric still lists the charging power correctly.

Any idea what’s going on? I know that Mercedes had some outages of their Mercedes Me services a couple of days ago.

Thanks,

Thomas

Hi Thomas,

This could happen when the charging power information is not delivered via the api on HA-startup. Give me some time to check this with my cars.

The attributes are dynamic and added whenever the info becomes available. But this is not the case for sensors currently. I have an idea of how to solve this.

BR
Rene

1 Like

Hi there, just a quick question, will a 2018 model in Norway work?

Hi, yes - should work. Available features are depending on the purchased services. BR Rene

1 Like

I have released a new minor release v0.9.7 with some new stuff and some fixes too…

But great things first: Thanks for your 100 Github Repo stars.

New:

  • New Buttons for starting/stopping the preconditioning of a car (preheat, Mode “Now”)
  • New Service “SERVICE_PREHEAT_STOP_DEPARTURE_TIME” to stop a preheating/preconditioning that was initiated by departure time

Fixes:

  • Wrong status of Binary Sensor “Windows Closed” (fixed: #155)

  • Integration reload is disabled for now (needs a fix of the websocket handling to prevent duplicate events)

  • Websocket connection loop (fixed: #153)

  • minor improvements

Hi @Thomas01 ,

I can’t reproduce this for the charging_power sensor but see this for the “Electric consumption start” sensor currently.

I shared the reason already in my first answer.

My idea would be to integrate “Default values” for sensors like charging_power (0 in this case). For sensors like “Electric consumption start” the latest recorded status could be the right default. What is your opinion?

BR
Rene

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)