Need to know from which version you updated. Since Aug. 2023 especially the bridge (account) is stable and the setup procedure doesn’t changed since then.
Sounds curious, are you setting up bridge with UI or textual config?
So… I just cleared the cache, restarted everything and then I got the bridge online.
I just couldn’t activate the old BEV thing. So I created a new BEV.
Now I have all the channels too.
Is there a description of what status messages in the channels say? I’m still looking for the channel when the charging plug is plugged in.
Otherwise everything works fine.
Thank you very much. A very good job.
Great to see it’s running.
Check in group charge the coupler mappings .
Thanks. I couldn’t find this exact page yesterday. I’ve searched for 2 hours. The world can be so easy… if you know something more. 
I guess I need some help! The binding always worked, but only with the warning: “2025-01-02 14:43:09.827 [WARN ] [et.common.message.MessageInputStream] - MessageInputStream closed without fully consuming content WebSocketSession[websocket=JettyAnnotatedEventDriver[org.openhab.binding.mercedesme.internal.server.MBWebsocket@a69ff8] …”. This was on OH 4.1.X. I did used Version 4.3.0.202410201446.
Now updated to the latest OH release - 4.3. I first tried the official Binding version. The Binding connects to online, but the Things does not! I also tried the youngest SNAPSHOT 4.3.1.
I changed the Bindingversion on the run, via reboot also cleared the cache but without success. The Only Version which works is 4.3.0.202410201446, but with the warning from above!
Any hint, how to get the actual Bindings to work?
What does it mean “binding connects online”? Does Bridge (Account) and Thing (Vehicle) both stay offline?
Would be helpful to enable trace level to see any problems.
There’s nothing additional inside. @RedTiger observed in his previous posts commandes towards vehicle were failing which is solved in Marketplace binding.
After changing form Version 4.3.0.202410201446 to the Marketplace binding, the Bridge (Account) is online and the Thing (Vehicle) stays unknown (Yellow).
result Trace with two BEV vehicles:
2025-01-03 08:50:57.242 [TRACE] [esme.internal.handler.AccountHandler] - IOException decoding message While parsing a protocol message, the input ended unexpectedly in the middle of a field. This could mean either that the input has been truncated or that an embedded message misreported its own length.
2025-01-03 08:51:09.184 [TRACE] [esme.internal.handler.AccountHandler] - IOException decoding message Protocol message contained an invalid tag (zero).
2025-01-03 08:51:21.171 [TRACE] [rcedesme.internal.server.MBWebsocket] - Websocket stop
2025-01-03 08:51:42.794 [TRACE] [rcedesme.internal.server.MBWebsocket] - Websocket start wss://websocket.emea-prod.mobilesdk.mercedes-benz.com/v2/ws
2025-01-03 08:51:42.993 [TRACE] [esme.internal.handler.AccountHandler] - MB Debug Message: Registering User with ciamID: xxxxxxxxxxxxx and App-UUID: xxxxxx-xxxx-xxxx-xxxx-xxxxxxxx
2025-01-03 08:51:42.997 [TRACE] [esme.internal.handler.AccountHandler] - MB Debug Message: app twin actor was initialized
2025-01-03 08:51:43.112 [TRACE] [esme.internal.handler.AccountHandler] - IOException decoding message Protocol message tag had invalid wire type.
2025-01-03 08:51:47.115 [TRACE] [esme.internal.handler.AccountHandler] - IOException decoding message Protocol message contained an invalid tag (zero).
2025-01-03 08:51:51.915 [TRACE] [esme.internal.handler.AccountHandler] - IOException decoding message Protocol message end-group tag did not match expected tag.
2025-01-03 08:51:57.676 [TRACE] [esme.internal.handler.AccountHandler] - IOException decoding message Protocol message end-group tag did not match expected tag.
2025-01-03 08:52:04.590 [TRACE] [esme.internal.handler.AccountHandler] - IOException decoding message Protocol message tag had invalid wire type.
2025-01-03 08:52:12.895 [TRACE] [esme.internal.handler.AccountHandler] - IOException decoding message Protocol message end-group tag did not match expected tag.
2025-01-03 08:52:22.853 [TRACE] [esme.internal.handler.AccountHandler] - IOException decoding message Protocol message contained an invalid tag (zero).
2025-01-03 08:52:34.801 [TRACE] [esme.internal.handler.AccountHandler] - IOException decoding message Protocol message had invalid UTF-8.
2025-01-03 08:52:42.818 [TRACE] [rcedesme.internal.server.MBWebsocket] - Websocket stop
Hi,
Rene von der HomeAssistant-MB-Component hier…
Würde gern mal eine Idee zum erwarteten Auth-Thema besprechen wollen. Wenn Du Interesse hast, schreib mir ne Mail an mbdev@nulsch.de
Grüße
I am running Version 4.3.2 of openhab. I now get the following Error. After that both Things are offline.
[rcedesme.internal.server.MBWebsocket] - onError Failed to upgrade to websocket: Unexpected HTTP Response Status Code: 429 Too Many Requests
Any hint?
I have been seeing these problems intermittently, with the bridge flapping between offline and online every few hours, since Thursday January 9. I am running OH 4.3.1 but this “Too Many Requests” looks more like some form of connection throttling by the Mercedes server side…
@Boris_Fierlings @F18i
Yes, had this too yesterday for some hours with respone 429 - too many requests. Came “out of the blue”, nothing changed in system. Self healed in the evening.
Yes, looks like it’s gone. Have had the Errors the Last 3 days. What ever happend in the Mercedes Cloud.
Yesterday I set up an alert with notification on status changes for the bridge and I can still see it flapping from online to offline every ~2 hours.
So unfortunately it doesn’t seem like the problem was temporary and it did not really go away. It still definitely seems an issue on the Mercedes server side.
Is there anything that can be changed on the bridge connection code to make it more tolerant of this particular error? Maybe implement or tweak the retry logic? Thanks in advance!
I cannot confirm this from my side.
If thing goes OFFLINE the connection raises an error. Can you activate loglevel TRACE to get some logs and see the error code?
Thanks Bernd,
I enabled tracing level logging and it really does not show a lot more than what we already knew, i.e. the “429 Too Many Requests” warning.
However, I also found out that I originally set the Bridge “Refresh Interval” to 5 minutes. Since I changed that back to a more conservative 10 minutes this morning, I have not seen any disconnect. So my hypothesis is that some requests to the backend remain in flight for more than 5 minutes and the following one gets rejected with that 429 error, causing the bridge to disconnect.
Anyway, for now it appears like my problem has gone away. If we all see this coming up again, I suggest experimenting with the refresh interval parameter.
My logs look the same. I have 5min refresh. What do you have?
Yesterday I set the refresh interval to 10 minutes and, since then, I have not seen any more disconnects.
Today again issues arised with Mercedes Server. I personally got HTTP Error 412. Home Assistant users observed similar behavior.
Fixing is ongoing, I just wanted to post this in beforehand in order to avoid many problems related to this topic - just give this post a heart if you observed the same connection problems!
Just a short confirmation: “onError Failed to upgrade to websocket: Unexpected HTTP Response Status Code: 412 Precondition Failed”.
Mine is:
2025-01-30 17:12:13.213 [ERROR] [core.thing.internal.ThingManagerImpl] - Exception occurred while initializing handler of thing 'mercedesme:bev:8fdf62fca7:c387a58d2c': A JSONObject text must begin with '{' at 0 [character 1 line 1]
at org.openhab.binding.mercedesme.internal.handler.AccountHandler.getCapabilities(AccountHandler.java:470) ~[?:?]
at org.openhab.binding.mercedesme.internal.handler.AccountHandler.getStringCapabilities(AccountHandler.java:437) ~[?:?]
at org.openhab.binding.mercedesme.internal.handler.AccountHandler.discovery(AccountHandler.java:423) ~[?:?]
at org.openhab.binding.mercedesme.internal.handler.AccountHandler.registerVin(AccountHandler.java:274) ~[?:?]
at org.openhab.binding.mercedesme.internal.handler.VehicleHandler.initialize(VehicleHandler.java:163) ~[?:?]
And when i try to re-auth i just get “Something went wrong”
Stopped working today around 10:00 CET