Since 2 days i have the same problem with the 429 error and would like to implement the detection and an automatic restart.
The first part with creating the automation is easy, but i am struggeling with the second part:
How do i have to do this?
Do i just have to copy those 2 lines of code in the configuration.yaml or what do i have to do?
Sorry, i am a beginner 
My question to the third step is: Where can i find the number for the “entry_id”?
Regards,
Stefan
Yes. Just copy this two lines in your configuration.yaml. In case you have the line system_log: aleady in the file, just add fire_event: true.
As I said, we have to wait until we/I understood the issue. An automated reload makes no sense. I’m still working on it.
Until now i always was able to get the device running again with a simple reload. This is how i want to do it:
actions:
- action: persistent_notification.create
metadata: {}
data:
message: MB-API access blocked. HTTP 429
- delay:
hours: 1
minutes: 0
seconds: 0
milliseconds: 0
- action: homeassistant.reload_config_entry
data:
entry_id: "12345"
So i want to wait 60 min (have to test if that is enough) until the automatic reload happens.
I just need the answer how to find the right entry_id number.
Can you answer this, too, please?
Click on this link:
and you can see the ID in the url-field of the browser:
and you have to extend your action and add an entity-id:
action: homeassistant.reload_config_entry
data:
entry_id: ...
target:
entity_id: sensor.XXXX_car
Replace XXXX with your sensor naming
Thanks, will try now next time the device is stuck.
sorry if this question is already ask but i cannot find my answer.
I would like to find all the entity state codes to create my own automtion
something like this
# Codes for open/unlocked/venting of doors and sunroof (sensor.XXX_lock):
# doorlockstatus*: true: unlocked, false: locked
# doorstatus*: true: open, false: closed
# sunroofstatus: 0: closed, 1: open, 2: vent, 7: opening, 8: closing, 11: open vent, 12: closing vent
# Codes for open/venting of windows (binary_sensor.XXX_windows_closed):
# windowstatus*: 1: open, 2: closed, 4: vent, 5: moving
Any idea where i can find this information?
I was using this entity to open automatically my gate but in the last couple of days it is not working any more.
I have noted that GP058TC Ignition State is now frozen as “Locked”
I’m using this custom add on and the Mercedes Vehicle Card to show it on love lace. I can’t get the information of where my car is (map function).
Is it available with my EQB and in Germany?
On my Mercedes Me App (Android) I got this information. Can anyone help me?
Check the configuration of the card. Go to the Map section and select the device tracker of your car.
thank you. It works now
Now I have lost the integration on two different Pi’s after upgrading to the lastest Hass version. 
This is the error message on startup:
Loggdetaljer (FEIL)
Logger: homeassistant.config_entries
Kilde: config_entries.py:635
Førs oppstått: 14:27:44 (1 hendelser)
Sist logget: 14:27:44
Error setting up entry mastiff@*****.no (Region: Europe) for mbapi2020
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/config_entries.py", line 635, in __async_setup_with_context
result = await component.async_setup_entry(hass, self)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/config/custom_components/mbapi2020/__init__.py", line 207, in async_setup_entry
raise HomeAssistantError(
homeassistant.exceptions.HomeAssistantError: No car information registered for this account. Check the MB website with the same account. Giving up...
I have not changed the mail address for this Mercedes Me account since I got it in 2020, and the account and the car shows in the Mercedes app. But that has been very flakey the last weeks as well, it may be related.
Here is a pre-publication of the release notes of the upcoming release. (hopefully tomorrow):
A few days ago, the MB team made some changes to their backend environment. As a result, accounts may be blocked in cases of extensive use. In the context of this integration, extensive use can happen after multiple restart/reloads per day. When blocked, access with this component and all official MB apps will no longer be possible. The account is unblocked at midnight (GMT).
To reduce the risk of your account being blocked, please follow these recommendations:
If an account is blocked (HTTP 429), the system will now automatically attempt to re-establish the connection after midnight (GMT) The retry delay is based on the following formula Retry delay = 15 seconds × (retry count)². When the reconnect was successful a reload of the component is initiated.
Q: Why do you not act like the official app and reuse the application-id to prevent blocking?
A: Only with a new app-id, the component gets a full-data update from the MB-servers on start/reload. A full dataset is currently needed to create the sensors as I decide based on this full update which sensors are available for the car.
Q: How can I see the details?
A: Enable the debug logging of this component to see all the details like wait time or other output.
Aha… That’s probably what happens. And why my and my wife’s apps are not updating as they should. I will create one account each for my Hass instances, I have three different instances using this, and I’m guessing the restart of all Pi’s at four every night is one of the reasons for the problem. And I have been doing a lot of work to my setups the last week, and that means that I restart Hass more than I usually do. Thank you!
Thanks!
I order to use the second account in my HA instance, first I had to completely remove the existing account from the integration. Just disabling the existing account created the entities of the car, however in a disabled state.
Not sure if this is a common issue.
I’m using beta3 of the integration and HA 2024.11.3
I have published “v0.20.0 - Account blocking” now.
A few days ago, the MB team made some changes to their backend environment. As a result, accounts may be blocked in cases of intensive use. In the context of this integration, extensive use can happen after multiple restart/reloads per day. When blocked, access with this component and all official MB apps will no longer be possible. The account is unblocked at midnight (GMT).
To reduce the risk of your account being blocked, please follow these recommendations:
HTTP 429), the system will now automatically attempt to re-establish the connection after midnight (GMT) The retry delay is based on the following formula Retry delay = 15 seconds × (retry count)². When the reconnect was successful a reload of the component is initiated. (Fixes #279, #282)Q: Why do you not act like the official app and reuse the application-id to prevent blocking?
A: Only with a new app-id, the component gets a full-data update from the MB-servers on start/reload. A full dataset is currently needed to create the sensors as I decide based on this full update which sensors are available for the car. I’ll try to address this in one of the next releases.
Q: How can I see the details?
A: Enable the debug logging of this component to see all the details like wait time or other output.
You can support the development.
I had to revert back to 0.19.1 to remove the authorization token. In 0.20 it throws an error ‘Unknown error occured’.
I have re-authorized with a specific HA user under 0.19.1, then upgraded to 0.20
After re-authorizing with the new account I was confused to see the old account mail address re-appear. I now understand that this is the name of the created hub and thus can easily be updated. I mention this in case someone else would also wonder.
Thanks, I need to fix it - this was a change to prep for HA 2024.12 - and not well tested - Sorry.
I have published a Bugfix release v0.20.1
fixes: