Mercedes Me Component

So if i have 2 accounts, i can use my additional account for 18 hours and the official account for 6 hours as long as they both map to the same entities :thinking:

Yes, this should work - but I have not tested it.

tried adding a 2nd entry, and it gives an error The device is disabled by Config entry and all the entities become unavailable.

@jitesh_88 Did you read the whole thing, or did you just blindly act on it? :weary:

Can you adapt the integration to work with 2 accounts and automatically swap between the two?

I have deleted my first comment, it was not good enough…

@jitesh_88: In your screen, click on one of the “MercedesMe 2020”-entries on the left and enable one of the entries.

I tested it now and this approach should work.

To automate the process you need the custom component “spook”. You can find it in the HACS catalog. The documentation for this component is here.

Assuming you have added two mbapi2020 accounts. You need now the config_entry_ids. For example the diagnostic report has the id in the filename. (example: config_entry-mbapi2020-1a979817abf1b0628ee99f4b8fd4a0b6.json - the bold part is the config_entry_id)

Now you can use the new actions homeassistant.disable_config_entry or homeassistant.enable_config_entry. Use the yaml-Editor (the gui-mode does not support config_entry_ids)

Example:

action: homeassistant.disable_config_entry
data:
  config_entry_id: 1a979817abf1b0628ee99f4b8fd4a0b6

Hope this helps.

@firstcolle : For now, I’ll try to implement the Idea 3 shared above. When you want to go the 2 accounts way, you can use the discussed approach.

Yes i did, the way i understood it was not to use the official account as it will only work for 10hours, but i was only using it for testing 2 accounts and splitting the hours of a day between them.

i already had one of them enabled but it was still showing up as if they both are disabled. screenshot below. they both have different config_entry_ids in the hyperlink when i hover over it.

Can you implement a mechanism to look for activity on the car (engine running, car powered up, car driving), and during this time holding the data channel open?

1 Like

Updated the vehicle info card to 1.6.0 and having problems with cards opening. I’ve cleared the cache etc. Some of the output in Chrome:

vehicle-info-card.js?hacstag=810563350160:1 Uncaught (in promise) RangeError: Incorrect locale information provided
    at Date.toLocaleString (<anonymous>)
    at p (vehicle-info-card.js?hacstag=810563350160:1:2897)
    at f (vehicle-info-card.js?hacstag=810563350160:1:3132)
    at g (vehicle-info-card.js?hacstag=810563350160:1:3012)
    at ps._renderCustomCard (vehicle-info-card.js?hacstag=810563350160:3373:785)
    at ps.render (vehicle-info-card.js?hacstag=810563350160:3290:38)
    at ps.update (vehicle-info-card.js?hacstag=810563350160:22:238)
    at ps.performUpdate (vehicle-info-card.js?hacstag=810563350160:11:4887)
    at ps.scheduleUpdate (vehicle-info-card.js?hacstag=810563350160:11:4423)
    at ps._$ET (vehicle-info-card.js?hacstag=810563350160:11:4331)

Hi @gda1 what type of card are you trying to open?

@VietNgoc Just the default card, pressing any of the buttons - Trip data / Vehicle settings etc

Entities in the integration are available? The only thing I can think from the log is that the problem is in the entity of the last update, and the translation of the language for the render, if the last update time is unknown, it can cause this problem.

To debug, try creating a new card to see if the problem persists.

Let me give you an update on the current developments around the “HTTP429 - Account blocked” problem.

In the last post, I shared some ideas and thanks for the responses. I have, based on my testing and your feedback, now developed the following features and have been running these features successfully for 36 hours on my test system (5 cars).

  1. the connection is closed after 30 seconds if no update messages are received from the MB server. When a message is received, the 30 seconds restart.
  2. the connection is re-established after 60 seconds.
  3. all changes that have happened in the meantime are delivered by the MB systems.
  4. if an action, button or switch is triggered, the connection remains active for 120 seconds in order to receive long-running responses from the MB system.

So far I have no more HTTP-429 Too many requests in the environment.

Here is a first diagram of how the quota is now being used. The chart shows 24 hours. Please keep in mind that this is for five cars. All cars moved or were loaded during this time. “Normal accounts” with 1-2 cars should show even better results…

Time connected: 09h 06m
Time not connected: 14h 53m

image

I will test these changes until tomorrow and release a beta release for testing if successful.

PS: Thanks to the supporters!

PSS: And yes, the scaling of the chart is not perfect but should give you an idea how the result will look like.

3 Likes

Thank you so much! I can’t wait to test this version. With these changes, would it be possible to use a single account? Considering that I rarely use the app on my phone, there shouldn’t be any issues, right? Also, I have a gate that opens when I’m near home (I use the tracker and not the app’s geofence zones). When the car is in motion, does the channel stay open all the time, or does it follow the rules you described here as well?

This depends on your usage profile. My sugestion will be still “one account - per environment”.

Yes, the connection will be kept open when the ignition state is on for at least one car of this account.

1 Like

I have published a test release “v.0.21.0-beta.1 - New connection handling”.

IMPORTANT:

  • This is a test release and it contains a new logic for the connection handling. Please be aware of potential bugs and provide feedback.
  • It can take 24 hours until the new logic is effective. During this time, you might experience account blocks, particularly if you update the component in the afternoon. (See here for some test results)
  • Please check the homeassistant.log and/or enable the debug logging before you file an issue. (The help page is using MQTT as an example, please replace MQTT with MBAPI2020)

Main goal: Prevent the account blocking with a new connection handling

New connection handling:

  • the connection is closed after 30 seconds if no update messages are received from the MB server. If a message is received or a car’s ignition state is on, the 30 seconds window restarts.
  • the connection is re-established after 60 seconds.
  • changes that have happened in the meantime are delivered by the MB systems. (the latest values, not all)
  • if an action, button or switch is triggered, the connection remains active for 120 seconds in order to receive long-running responses from the MB system.

Other fixes:

  • New capability modes for auxHeat (fixes: #288, some cars reporting that the command capabilities for auxheat are not available, but at the same time the car reports the capability auxHeat. We check “auxHeat” also now.)

PS: Thanks to the supporters !

QA:
Q: Why do you keep the connection open based on ignition state only and not based on charging?
A: If the charging is active, we get an update message every 15-20 seconds, and the connection will stay open automatically based on rule 1.

Please share your test result:

  • Yes, it works as expected.
  • No, it does not work. (create a Github issue please)
0 voters
1 Like

Hi Rene! First of all - thanks for your hard work! :+1: How can I install the Beta for testing?

EDIT: Figured it out! I will test it!

I have published a new test version v0.21.0-beta.2.

fixes:

  • wrong access_token check (fixes: #292, this could happen when the MB servers delivers empty key material)

Please read the complete release notes.

First of all Thank You Rene for your awesome work. I installed 0.21.0-beta1 yesterday and it worked fine. Today i upgraded to beta2 and no problems yet.

I have a question reg. openWB and maybe someone can help.
I can set the SoC to e.g. 42 via Home Assistant Terminal using this command:

curl -k -s -X POST --data '{"topic": "openWB/set/vehicle/1/get/soc", "message": 66}' https://192.168.1.8:8443/v1/ | jq

But of course i want to set the SoC to the value of the sensor “sensor.x_xx_1234_e_state_of_charge” of the MercedesME integration. How can i put a variable into it?

i tried this, but it is not working:

curl -k -s -X POST --data '{"topic": "openWB/set/vehicle/1/get/soc", "message": {{ states('sensor.x_xx_1234_e_state_of_charge') }}}' https://192.168.1.8:8443/v1/ | jq

If this is done, can i then just define a Shell Command in the configuration.yaml and use it in my automation?

Thanks for the test.

Here one idea:


#!/bin/bash

TOKEN=""
HA_URL="http://localhost:8123"
ENTITY="x_xx_1234_e_state_of_charge"
EXTERNAL_URL="https://192.168.1.8:8443/v1/"

# load sensor value from HA
SENSOR_STATE=$(curl -s -X GET -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" "$HA_URL/api/states/$ENTITY" | jq -r '.state')

# send value to openweb
if [[ "$SENSOR_STATE" =~ ^[0-9]+(\.[0-9]+)?$ ]]; then
  # Proceed only if it's a valid number
  curl -k -s -X POST --data "{\"topic\": \"openWB/set/vehicle/1/get/soc\", \"message\": $SENSOR_STATE}" $EXTERNAL_URL | jq
else
  echo "Invalid sensor value"
  exit 1
fi

To create the token:

  1. Go to your profile page (lower left corner)
  2. Tab “Security”
  3. Scroll down.
  4. Create a long-lived-access-token

PS: Updated to prevent command injection…