Mercedes Me

after update to latest version acc. link the channel “adblue level” is still not visible/available, also not as advanced channel and restart of oh.
Any hint?

Update: It’s there, my mistake. Sorry and thx for your support.

1 Like

No problem, let’s check.

I tested with combustion vehicles. You should see in your trace something like this

2024-11-12 14:05:55.460 [INFO ] [core.thing.internal.ThingManagerImpl] - Updating 'mercedesme:combustion:87a338be3f:6be1a4431a' from version 2 to 3

Is it perhaps a hybrid vehicle with battery and combustion support?

Log into openHAB console and change level to TRACE via
log:set TRACE org.openhab.binding.mercedesme

“Normal” websocket update looks like this:

2024-11-15 13:39:56.257 [TRACE] [rcedesme.internal.server.MBWebsocket] - Websocket start wss://websocket.emea-prod.mobilesdk.mercedes-benz.com/v2/ws
2024-11-15 13:39:56.452 [TRACE] [rcedesme.internal.server.MBWebsocket] - MB Debug Message: Registering User with ciamID: myknm5f5wpegugcb and App-UUID: 1455d2bc-f3c4-4ea2-8da6-60c98f4de8a9
2024-11-15 13:39:56.467 [TRACE] [rcedesme.internal.server.MBWebsocket] - MB Debug Message: app twin actor was initialized
2024-11-15 13:40:56.275 [TRACE] [rcedesme.internal.server.MBWebsocket] - Websocket stop
2024-11-15 13:40:56.278 [DEBUG] [rcedesme.internal.server.MBWebsocket] - Disconnected from server. Status 1006 Reason Disconnected

Your command did not work:
grafik

But I changed changed the log level in the log4j.xml and it got picked up accordingly.

I have another vehicle for which I have not created a thing handler. That explains the message below. Other than that no luck:

2024-11-15 15:05:12.200 [TRACE] [ding.mercedesme.internal.utils.Utils] - Cannot transform Display Value 17:58 into Double
2024-11-15 15:05:12.205 [TRACE] [esme.internal.handler.VehicleHandler] - No home location found
2024-11-15 15:05:12.208 [TRACE] [esme.internal.handler.AccountHandler] - No VehicleHandler available for VIN WDD12345678901234
2024-11-15 15:05:13.610 [TRACE] [ding.mercedesme.internal.utils.Utils] - Cannot transform Display Value 17:58 into Double
2024-11-15 15:05:13.618 [TRACE] [esme.internal.handler.VehicleHandler] - No home location found
2024-11-15 15:05:13.620 [TRACE] [esme.internal.handler.AccountHandler] - No VehicleHandler available for VIN WDD12345678901234
2024-11-15 15:05:22.065 [TRACE] [ding.mercedesme.internal.utils.Utils] - Cannot transform Display Value 17:58 into Double
2024-11-15 15:05:22.096 [TRACE] [esme.internal.handler.VehicleHandler] - No home location found
2024-11-15 15:05:22.099 [TRACE] [esme.internal.handler.AccountHandler] - No VehicleHandler available for VIN WDD12345678901234
2024-11-15 15:05:24.966 [TRACE] [rcedesme.internal.server.MBWebsocket] - IOException Protocol message had invalid UTF-8.
2024-11-15 15:05:32.060 [TRACE] [rcedesme.internal.server.MBWebsocket] - IOException Protocol message had invalid UTF-8.
2024-11-15 15:05:42.011 [TRACE] [ding.mercedesme.internal.utils.Utils] - Cannot transform Display Value 17:58 into Double
2024-11-15 15:05:42.016 [TRACE] [esme.internal.handler.VehicleHandler] - No home location found
2024-11-15 15:05:42.019 [TRACE] [esme.internal.handler.AccountHandler] - No VehicleHandler available for VIN WDD12345678901234
2024-11-15 15:05:46.131 [TRACE] [rcedesme.internal.server.MBWebsocket] - IOException Protocol message had invalid UTF-8.
2024-11-15 15:05:46.132 [WARN ] [et.common.message.MessageInputStream] - MessageInputStream closed without fully consuming content WebSocketSession[websocket=JettyAnnotatedEventDriver[org.openhab.binding.mercedesme.internal.server.MBWebsocket@33ee6517],behavior=CLIENT,connection=WebSocketClientConnection@3216a864::DecryptedEndPoint@3cd14056{l=/192.168.0.36:44950,r=websocket.emea-prod.mobilesdk.mercedes-benz.com/20.67.76.32:443,OPEN,fill=-,flush=-,to=4112/840000},remote=WebSocketRemoteEndpoint@38eec314[batching=true],incoming=JettyAnnotatedEventDriver[org.openhab.binding.mercedesme.internal.server.MBWebsocket@33ee6517],outgoing=ExtensionStack[queueSize=0,extensions=[],incoming=org.eclipse.jetty.websocket.common.WebSocketSession,outgoing=org.eclipse.jetty.websocket.client.io.WebSocketClientConnection]]
...
... the same messages repeat over and over
...
2024-11-15 15:08:58.252 [DEBUG] [rcedesme.internal.server.MBWebsocket] - Disconnected from server. Status 1001 Reason null
2024-11-15 15:08:59.224 [TRACE] [rcedesme.internal.server.MBWebsocket] - Websocket stop

???
Check with
bundle:list -s | grep binding

There needs to be the binding listed exactly with the above name.

329 │ Active │  80 │ 4.3.0.202411061346    │ org.openhab.binding.mercedesme

I never use the console so I don’t know the mechanics. :person_shrugging:
Changing the level through the file worked as shown in the post above.
grafik

Me neither but this could explain why the command doens’t work if you fixed the settings in log4j.xml.

So you’ve 2 vehicles, even if one isn’t handledd in openHAB it doesn’t do any harm. Nevertheless more updates are coming through websocket and this is showing me a design flaw in the binding implementation. Currently websocket thread is doing all the updates and this needs to be fixed.

I changed code and in 24 hours testing I could get rid of all these invalid UTF-8 exceptions. Would like to see your results on the updated binding in top post!

But I only added the file entry after the command did not work!


I’ve installed the new version

330 │ Active │  80 │ 4.3.0.202411161852    │ org.openhab.binding.mercedesme

Looks good:

2024-11-17 05:05:51.805 [TRACE] [rcedesme.internal.server.MBWebsocket] - Websocket start wss://websocket.emea-prod.mobilesdk.mercedes-benz.com/v2/ws
2024-11-17 05:05:52.139 [TRACE] [esme.internal.handler.AccountHandler] - MB Debug Message: Registering User with ciamID: 0314011e9eaf8238 and App-UUID: 27ef70bf-332c-41b0-b19f-82973986c774c
2024-11-17 05:05:52.142 [TRACE] [esme.internal.handler.AccountHandler] - MB Debug Message: app twin actor was initialized
2024-11-17 05:05:52.626 [TRACE] [esme.internal.handler.AccountHandler] - IOException decoding message Protocol message end-group tag did not match expected tag.
2024-11-17 05:05:56.216 [TRACE] [esme.internal.handler.AccountHandler] - IOException decoding message Protocol message end-group tag did not match expected tag.
2024-11-17 05:06:01.017 [TRACE] [esme.internal.handler.AccountHandler] - IOException decoding message Protocol message tag had invalid wire type.
2024-11-17 05:06:06.779 [TRACE] [esme.internal.handler.AccountHandler] - IOException decoding message Protocol message contained an invalid tag (zero).
2024-11-17 05:06:13.693 [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.
2024-11-17 05:06:21.989 [TRACE] [esme.internal.handler.AccountHandler] - IOException decoding message Protocol message tag had invalid wire type.
2024-11-17 05:06:31.943 [TRACE] [esme.internal.handler.AccountHandler] - IOException decoding message Protocol message contained an invalid tag (zero).
2024-11-17 05:06:43.889 [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.
2024-11-17 05:06:51.824 [TRACE] [rcedesme.internal.server.MBWebsocket] - Websocket stop
2024-11-17 05:06:51.826 [DEBUG] [rcedesme.internal.server.MBWebsocket] - Disconnected from server. Status 1006 Reason Disconnected

1 Like

No I have another problem (or probably the same):
My items were not receiving updates so I removed the thing and the binding.
Then I installed the latest market place binding again.
Now the bridge thing is online, but the vehicle thing is stuck in state “unkown”.

2024-11-22 13:18:00.333 [TRACE] [rcedesme.internal.server.MBWebsocket] - Websocket start wss://websocket.emea-prod.mobilesdk.mercedes-benz.com/v2/ws
2024-11-22 13:18:00.535 [TRACE] [esme.internal.handler.AccountHandler] - MB Debug Message: Registering User with ciamID: 0314011e9eaf8238 and App-UUID: 27ef70bf-332c-41b0-b19f-82973986c774c
2024-11-22 13:18:00.538 [TRACE] [esme.internal.handler.AccountHandler] - MB Debug Message: app twin actor was initialized
2024-11-22 13:18:00.619 [TRACE] [esme.internal.handler.AccountHandler] - IOException decoding message Protocol message contained an invalid tag (zero).
2024-11-22 13:18:03.099 [TRACE] [esme.internal.handler.AccountHandler] - IOException decoding message Protocol message contained an invalid tag (zero).
2024-11-22 13:18:07.902 [TRACE] [esme.internal.handler.AccountHandler] - IOException decoding message Protocol message tag had invalid wire type.
2024-11-22 13:18:08.517 [TRACE] [esme.internal.handler.AccountHandler] - IOException decoding message Protocol message tag had invalid wire type.
2024-11-22 13:18:09.143 [TRACE] [esme.internal.handler.AccountHandler] - IOException decoding message Protocol message tag had invalid wire type.
2024-11-22 13:18:17.432 [TRACE] [esme.internal.handler.AccountHandler] - IOException decoding message Protocol message end-group tag did not match expected tag.
2024-11-22 13:18:18.996 [TRACE] [esme.internal.handler.AccountHandler] - IOException decoding message Protocol message contained an invalid tag (zero).
2024-11-22 13:18:29.101 [TRACE] [esme.internal.handler.AccountHandler] - IOException decoding message Protocol message end-group tag did not match expected tag.
2024-11-22 13:18:39.059 [TRACE] [esme.internal.handler.AccountHandler] - IOException decoding message Protocol message contained an invalid tag (zero).
2024-11-22 13:18:49.185 [TRACE] [esme.internal.handler.AccountHandler] - IOException decoding message Protocol message contained an invalid tag (zero).
2024-11-22 13:18:58.940 [TRACE] [esme.internal.handler.AccountHandler] - IOException decoding message Protocol message contained an invalid tag (zero).
2024-11-22 13:19:00.364 [TRACE] [rcedesme.internal.server.MBWebsocket] - Websocket stop

Is this the whole trace or just some cut-outs? From this trace your vehicle will stay offline because no update is delivered. At least one Distributed VEPUpdate true is needed to get thing online.

2024-11-26 18:30:17.345 [TRACE] [esme.internal.handler.AccountHandler] - MB Debug Message: app twin actor was initialized
2024-11-26 18:30:18.038 [TRACE] [esme.internal.handler.AccountHandler] - Distributed VEPUpdate true

What worries me are the errors decoding mercedes messages. But it isn’t possible to find root cause in the logs. I prepared a debug binding but I wouldn’t distribute it on Marketplace yet.

It contains

  • some statistics how many successful / failed message decoding happend (trace 1)
  • for failed decoding a file is created. Location and name is printed in log (trace 2)

If you can zip them together and send to me via direct message I can try to analyze.

2024-11-26 19:53:58.413 [DEBUG] [rcedesme.internal.server.MBWebsocket] - Vehicle Decoder Stats {Vehcile Updates W1NXXXXXXXXX=4, Debug Messages=8, Vehcile Pending Commands=32, Vehcile Assignment W1NXXXXXXXXX=4}
2024-11-26 20:12:49.456 [DEBUG] [esme.internal.handler.AccountHandler] - Write proto file into /var/lib/openhab/tmp/mercedesme-good-12927043746759011241.proto

Hi,
I moved to OpenHAB 4.3, before using the latest marketplace binding successfully.

My Bridge/Thing (EQV BEV) is setup and working (states getting received) but I cannot sent any commands e.g. Lock the Doors (which worked before great!):

2024-12-24 11:23:40.127 [TRACE] [esme.internal.handler.AccountHandler] - Distributed VEPUpdate true
2024-12-24 11:23:54.614 [TRACE] [esme.internal.handler.VehicleHandler] - Received command class org.openhab.core.library.types.DecimalType 0 for mercedesme:bev:4711:eqv:vehicle#lock
2024-12-24 11:23:54.616 [TRACE] [esme.internal.handler.VehicleHandler] - Door Lock not supported

Reason seems to be that “Door Look not supported” because the Thing Properties are empty.
When setting up the Thing I get following errors in log:

 2024-12-24 11:30:40.727 [TRACE] [ding.mercedesme.internal.utils.Utils] - Cannot transform Display Value 02:30 into Double
2024-12-24 11:30:40.741 [TRACE] [esme.internal.handler.VehicleHandler] - No Charge Program property available for mercedesme:bev
2024-12-24 11:30:40.743 [TRACE] [rcedesme.internal.server.MBWebsocket] - WebSocket - keep alive start

Checking the available commands I get:

"commandName":"DOORS_LOCK","isAvailable":true,"parameters":null}

Any known workarounds or hints I get back the Thing Properties so Lock/Unlock Doors will work?
Thanks so much - would be a great christmas present by the way :wink:

Stay on official delivered MercedesMe binding. All changes are integrated in 4.3 release. so there are no further fixes or additional features.

Absolutely correct analysis. I still wonder why Thing properties are empty, should work also in OH upgrade cases.
Please try first with official delivered MercedesMe binding as mentioned above. If problem stays let’s continue analysis.

Thanks weymann. Maybe I gave wrong information.

  1. I was on 4.1.1 AND used the Marketplace Mercedes Me Binding successfully
  2. I moved to 4.3 AND using the built in (Mercedes Me Binding 4.3)
    So it should be fine!

I already purged my cache two times, recreated Bridge AND Things / Items from scratch - unfortunately always the same problem…

Ok, I can reproduce now. Existing things don’t have this problem while a setup from scratch is not properly working. Looks like Mercedes removed the message which is triggering discovery. That’s why the vehicle isn’t discovered after setting up the bridge and properties are not updated.

Long story short:

  • Keep MercedesMe Bridge & Things
  • uninstall official binding
  • install binding from Marketplace, it contains the fix now

Your vehicle thing shall now have the updated properties!

If you can provide a PR with this fix now, I’m ready to review it, and it might just make it into 4.3.1. :slightly_smiling_face:

1 Like

Perfect!
PR is raised for main branch and you can cherry pick it for 4.3.1

Excellent! Works like a charm! Thanks for quickly fixing it! :slight_smile:

1 Like

By the way, is there an Mercedes API where I can do a route calculation based on my EV car settings to get the SOC state at destination?

Background: I would like to implement in my smart car charging algo a mode;

  1. check my calendar entries, extracts the location of my appointment
  2. calculates a route to its destination with SOC forecast
  3. if SOC forecast < current SOC do a PV steered charging till deperature time (also in calendar)

I guess with ABRP this might be possible BUT also mercedes seems to have this routing/navigation services in the app, so is this easy accessible?

Sadly no. Mercedes doesn’t have it officially and we (openHAB and Home Assistant) doesn’t have access to the routing API provided in the App. Please note this binding is reverse engineered and is not relying onto any public API!

Fine, just note you can send the destination via sendPOI to your vehicle which you can use as destination.

Just my opinion - claculate in kWh, not SoC. Depending on season 50% SoC means for me ~200 km in summer time and ~150 km in winter time.

You can place an educated guess with your trip computer average consumption and distance to destination. I’m personally dealing with openrouteservice.

A professional guess is dealing with much more information

  • official announced construction sites
  • traffic jams due to accidents and daily commute times
  • occupation of EV chanrging stations

But this information isn’t accessible for free.

As said I’m not dealing with SoC. Take your needed kWh for the trip plus your reserve you want to have at the end of your drive.

After the old Mercedes binding no longer worked, I have now installed the new version.
I also installed OH 4.3

Unfortunately, when setting up the bridge (the account) I always get the error message “HANDLER_MISSING_ERROR”

How do I get access to the Mercedes-me account fixed again?