Thank you very much, now I’m really reaching my limits 
Where do I insert this script?
Can I use it directly in my automation, or does it have to go into configuration.yaml?
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.
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.
restart HA after every change 
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
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)
Thanks to the supporters!
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
2 Likes
Do you still see account blockings after version 0.21.0?
- Yes
- No
0
voters
I had no problem even before the update 
1 Like
Lucky human
I even use my main account again for the integration and have no problems.
Since I couldn’t change the display order in the car, the additional account really bothered me and I’m glad that it’s now even possible to use an account in the app and in the Home Assistant at the same time again.
1 Like
No problem here with main account in ha and mb app.
Many thanks
1 Like
No account problems at all, not in previous versions and not now. Thanks for providing this add-on!
I am still using v0.20.3 with only one account, I also had a blockage every now and then, but for a few days now it has been running without any problems again
I’m seeing this error attempting to remote start the car in HA using the custom card or a seperate button
Failed to perform the action mbapi2020/engine_start. 'NoneType' object has no attribute 'closed'
locking and unlocking the car shows the same issue.
The ME app is fine though, so I don’t think it’s a server issue. This started happening after updating to 0.21. Restarted HA, re-added my account to the component, double checked my account isn’t blocked by mercedes. Logs are just showing this error
here’s the error in the log
Logger: homeassistant.components.websocket_api.http.connection
Source: components/websocket_api/commands.py:245
integration: Home Assistant WebSocket API (documentation, issues)
First occurred: December 11, 2024 at 5:21:54 PM (37 occurrences)
Last logged: 8:17:14 PM[547184318432] Unexpected exception
[547222992304] Unexpected exception
[546893874944] Unexpected exception
[546791162784] Unexpected exception
[547260158672] Unexpected exception
Traceback (most recent call last):
File “/usr/src/homeassistant/homeassistant/components/websocket_api/commands.py”, line 245, in handle_call_service
response = await hass.services.async_call(
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File “/usr/src/homeassistant/homeassistant/core.py”, line 2802, in async_call
response_data = await coro
^^^^^^^^^^
File “/usr/src/homeassistant/homeassistant/core.py”, line 2845, in _execute_service
return await target(service_call)
^^^^^^^^^^^^^^^^^^^^^^^^^^
File “/config/custom_components/mbapi2020/services.py”, line 116, in doors_lock
await domain[_get_config_entryid(call.data.get(CONF_VIN))].client.doors_lock(call.data.get(CONF_VIN))
File “/config/custom_components/mbapi2020/client.py”, line 982, in doors_lock
await self.execute_car_command(message)
File “/config/custom_components/mbapi2020/client.py”, line 1593, in execute_car_command
await self.websocket.call(message.SerializeToString(), car_command=True)
File “/config/custom_components/mbapi2020/websocket.py”, line 159, in call
if self._connection.closed:
^^^^^^^^^^^^^^^^^^^^^^^
AttributeError: ‘NoneType’ object has no attribute ‘closed’
Ignore this, I cleared the pin and deleted the auth token from the configure menu, delted car again, and restarted HA. Everything works now!
Hello
I have an issue with the trunk open image and cowl
Trunk code:
mba_trunk:
friendly_name: "Trunk"
icon_template: mdi:car-door
value_template: >
{% if state_attr('sensor.myCar_lock', 'doorlockstatusdecklid') %}
unlocked
{% elif state_attr('sensor.myCar_lock', 'decklidstatus') %}
open
{% else %}
closed
{% endif %}
YAML
- type: image
entity: sensor.mba_trunk
state_image:
open: local/177000_trunk_openNEW.png
unlocked: local/177000_trunk_unlock.png
closed: null
style:
top: 0%
left: 0%
transform: none
As you can see trunk was opened and work in official app, and also cowl in the official app worked but not in my home assistant.
Do you know why?
Thanks
From my perspective, the template config is wrong. Here is an adjusted template code.
{% if state_attr('sensor.myCar_lock', 'doorlockstatusdecklid') and not state_attr('sensor.myCar_lock', 'decklidstatus') %}
unlocked
{% elif state_attr('sensor.myCar_lock', 'decklidstatus') and state_attr('sensor.myCar_lock', 'doorlockstatusdecklid') %}
open
{% else %}
closed
{% endif %}
You can use the attribute “engineHoodStatus” of the sensor “lock” to visualize the cowl/engine hood.
Create a sensor:
mba_cowl:
friendly_name: "Cowl"
icon_template: mdi:car-door
value_template: >
{% if state_attr('sensor.myCar_lock', 'engineHoodStatus') %}
open
{% else %}
closed
{% endif %}
Image:
- type: image
entity: sensor.mba_cowl
state_image:
open: local/177000_cowl.png
closed: null
style:
top: 0%
left: 0%
transform: none