Has the Lock been removed by Mercedes?
I got this after I updated right now.
Don’t know why, but not it’s working again. Thanks anyhow.
No, please check the error log.
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
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.
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
Just a crazy idea:
We all create 2 additional accounts and use them for 12 hours a day, one after the other.
2 Likes
#3 looks ok to me. I presume that’s similar to how the official app manages to work without outages?
Can we put an automation in HA to reload the app daily after every 12hours. Would that reset the websocket counter?
Yes, we can create such automation. (Scroll up a little bit) - but it would not help as the counter gets resetted at midnight (GMT).
Oh right, missed that. So the websocket timer of 20hours is from midnight
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
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 
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.
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