Mercedes Me Component

Share your Projects! Custom Integrations
2257

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
2258

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)
2259

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

2260

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

2261

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.

2262

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
2263

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?

2264

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
2265

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
2266

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!

2267

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.

2268

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?

2269

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…

2270

Thank you very much, now I’m really reaching my limits :slight_smile:
Where do I insert this script?
Can I use it directly in my automation, or does it have to go into configuration.yaml?

2271

Here is a better approach. Create the rest_command integration in your configuration.yaml

Example:

rest_command:
  send_vehicle_soc:
    url: "https://192.168.178.61:8002/v1/"
    method: POST
    verify_ssl: false
    content_type: "application/json"
    payload: >
      {
        "topic": "openWB/set/vehicle/1/get/soc",
        "message": {{ states('sensor.x_xx_1234_e_state_of_charge') }}
      }

Restart HA

in your automation you can have a action:

actions:
  - action: rest_command.send_vehicle_soc

Whenever the action gets called, the rest command with the actual value of your sensor is executed.

2272

Thanks again.
I suspect the IP address behind URL: must be my openWB address. I will then replace the 192.168.178.61 with 192.168.1.8.

What confuses me now is that it says 8002 as the port. Shouldn’t that be port 8443?

Addition:
I can’t use the action “send_vehicle_soc” in my automation. It seems the rest_command is not created.

2273

restart HA after every change :wink:

2274

You have to replace these values based on your scripts.

There is a service rest_command.reload - execute this one after each change in the yaml

2275

I have published a new release “v0.21.0 - New Strategy against account blocking”.

Main goal: Prevent the account blocking with a 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 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.
  • 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)

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.)
  • Polish and Spanish translation improvements (#291, #293 - Thanks @piotrgt and gallegonovato)

New

  • The Device overview and the diagnostic report contains more information about the hardware and software stack of the car. This could be helpful to diagnose different behaviors of the MB-API (see here fore more details)
    image

Thanks to the supporters!

2276

I can report a success. Although I am 100% sure that I have restarted the HA several times, I could not find the Rest Command. Now, after about 4 hours, it is suddenly there. I don’t understand it, but I’m happy that it works now.

So I finally reached my goal: Sending the SoC and Range to the openWB without an MQTT bridge. Here is my complete solution if someone wants to rebuild it.
Please replace the IP-address 192.168.1.8 with the IP-address of your openWB box and replace the sensor names (part x_xx_1234) with your sensor name license plate.

Entry in the configuration.yaml:

# Senden des SoC und Range an das Fahrzeug
rest_command:
  send_vehicle_soc:
    url: "https://192.168.1.8:8443/v1/"
    method: POST
    verify_ssl: false
    content_type: "application/json"
    payload: >
      {
        "topic": "openWB/set/vehicle/1/get/soc",
        "message": {{ states('sensor.x_xx_1234_e_state_of_charge') }}
      }
  send_vehicle_range:
    url: "https://192.168.1.8:8443/v1/"
    method: POST
    verify_ssl: false
    content_type: "application/json"
    payload: >
      {
        "topic": "openWB/set/vehicle/1/get/range",
        "message": {{ states('sensor.x_xx_1234_e_range_electric') }}
      }

This is my automation as yaml:

alias: State of Charge an openWB senden
description: ""
triggers:
  - entity_id:
      - sensor.x_xx_1234_e_state_of_charge
    trigger: state
conditions: []
actions:
  - action: rest_command.send_vehicle_soc
    data: {}
  - action: rest_command.send_vehicle_range
    data: {}
mode: single

Thank You again Rene for your endless help :slight_smile:

2 Likes