Mercedes Me Component

Share your Projects! Custom Integrations
2229

status nearly after 24 hours.

I waited a lot more over midnight. I had deactivated the integration.

Then i updated to 0.20.2 with a reinstall.

At first only 8 entities showed up. Then i loggede on the Mercede Me website and reloaded the integration and now it all works :smiley: - thanks for a great integration and not at least a great support :smiley:

2230

Same here, seems to be fully working again with v0.20.2!

Thx a lot!

2231

I upgraded to v0.20.2 (just overriding previous disabled version) yesterday and got no problem neither yesterday nor today. Still using same account for mercedes.me app and your integration, which I understand is discouraged. :smiling_face_with_three_hearts:

2232

Since the change of the MB API behaviour I’m encounting issues to change the target SOC:

`This error originated from a custom integration.

Logger: custom_components.mbapi2020.client
Source: custom_components/mbapi2020/client.py:773
integration: MercedesME 2020 (documentation, issues)
First occurred: 07:17:32 (8 occurrences)
Last logged: 07:25:13

Car action: CHARGEPROGRAMCONFIGURE failed. error_code: RIS_EMPTY_VEHICLE_API_QUEUE, error_message: None
Car action: CHARGEPROGRAMCONFIGURE failed. error_code: RIS_COULD_NOT_SEND_COMMAND, error_message: None`

Anyone else having similar issue?

2233

Probably a silly question, but following the advice to create a new account for HA, how do I reauthicate with the new account? Or do I have to delete the existing connection and add a new one?

2234

You can delete the authentication information in the “Configure”-Dialog of the integration, restart HA and then re-auth with the new account.

2235

Thank you. Looked at that dialog several times and missed that :grinning:.

2236

Hi @ragsna,
what happens when you call the service MercedesME 2020: Battery max soc configure and set the max-soc directly instead of setting the charge program? And does it works in the official app?

@all: Does anyone else has the same problem?

2237

Has the Lock been removed by Mercedes?
I got this after I updated right now.

IMG_0070
IMG_00701206×2354 107 KB

2238

Don’t know why, but not it’s working again. Thanks anyhow.

2239

No, please check the error log.

2240

Ok, you are right. It’s working, but the log shows still some error warning, even by using direct the service now:

This error originated from a custom integration.

Logger: custom_components.mbapi2020.client
Source: custom_components/mbapi2020/client.py:773
integration: MercedesME 2020 (documentation, issues)
First occurred: 07:17:32 (13 occurrences)
Last logged: 16:55:21

Car action: CHARGEPROGRAMCONFIGURE failed. error_code: RIS_EMPTY_VEHICLE_API_QUEUE, error_message: None
Car action: CHARGEPROGRAMCONFIGURE failed. error_code: RIS_COULD_NOT_SEND_COMMAND, error_message: None
Car action: CHARGEPROGRAMCONFIGURE failed. error_code: CMD_REJECTED_BY_QUEUE, error_message: None
2241

Do you get the same error when you use the battery_max_soc_configure? And what means it is working? Did you checked if the car has received the new charge program? You can check the attribute SelectedChargeProgram of the range_electric sensor. The errors are from the MB backend.

2242

Short update on the “429 - Too many requests”-topic:

After we got a high-level solution with v0.20.2 so that the component can live with the blocking from MB-side, I had checked multiple scenarios and have to correct some of the initial statements.

Before I start, the “use a separate account”-statements is still true.

Based on my tests, my current assumption is:

  • The blocking happens after keeping the websocket connection to the MB-servers open for more than 20 hours per day measured based on UTC and this is per account. (In total)
  • For example, I kept the Mercedes App open on an Android device on for 24 hours with some automatic interactions → block happend after around 20 hours
  • So the official app has the same limitation like this integration
  • I see a consistant behavior, when I keep the official app open and at the same time use the integration with the same account. The block will happen after around 10 hours

What could we do know?:

  • Idea 1: We stop the integration in the night hours, for example from 1am to 4am - the result would be that the daily block will happen from midnight until 1am. (for all users in the MEZ timezone, for GMT the stop would be from midnight to 4am.) - For users in other timezones, we have to prepare some sliding to keep the integration off between midnight and 4am in the respective timezone.
  • Idea 2: We stop the integration for 240 min splitted over the whole day. would mean that in 10min per hour the integration is not active. I’m not sure here, I assume that I would like to close/open my car in the minute where the integrations is offline
  • Idea 3: We open the connection to the server every minute only to get the current status and close it after we received the data. We open the connection, whenever we have to send a command. This should reduce the overall usage below 20h. negative part here that it is more effort and the near to realtime update is getting lost
  • Other ideas? Share your opinion or ideas below…
1 Like
2243

Just a crazy idea:
We all create 2 additional accounts and use them for 12 hours a day, one after the other.

2 Likes
2244

#3 looks ok to me. I presume that’s similar to how the official app manages to work without outages?

2245

Can we put an automation in HA to reload the app daily after every 12hours. Would that reset the websocket counter?

2246

Yes, we can create such automation. (Scroll up a little bit) - but it would not help as the counter gets resetted at midnight (GMT).

2247

Oh right, missed that. So the websocket timer of 20hours is from midnight

2248

yes, but from midnight in UTC/GMT - So when you live in Amsterdam then it is at 1am (at least in winter-time)
Update: And for China the time could be different, as they have their own infrastructure for the websocket connection.

1 Like