same for me, the BMW account thing and also the specific BMW model thing, both show a communication error. Is there anyone willing to have a look?
I can confirm on my OH 3.4 M6 setup as well. Looks like it is the case since yesterday. The trace shows, that already the first call to the BMW API fails. Also all others after this one fail as well (500 - Internal Server Error).
HTTP Error https://cocoapi.bmwgroup.com/eadrax-chs/v1/charging-statistics?vin=WBXXXXX¤tDate=2022-12-13T23%3A38%3A12.000344 - 400 - Bad Request{vin=vin=[WBXXXXX], currentDate=currentDate=[2022-12-13T23:38:12.000344]}
My OpenWB Wallbox can read the data via API. So looks like a specific issue in OH. May be some HTTP client specific things like headers are needed?
I have tried to use bimmerconnect and it is still working, all data could be seen.
bimmerconnected uses the URL seen above but without the question mark.
I have no knowledge to create a new binding, can anyone?
It looks like, that BMW stopped support of some v1 API calls.
After rebuilding the mybmw binding and replacing this URL from …/v1/… to …/v2/… I get the binding up and running again:
public static final String API_VEHICLES = "/eadrax-vcs/v2/vehicles";
but then the call to “https://cocoapi.bmwgroup.com/eadrax-chs/v1/charging-statistics” to query the charging-statistics failed with error 400.
Does anybody have a debug log of the mybmw binding from former times were everything worked fine, so that I can compare the differences?
Alternative: Has anybody a bimmerconnected call to charging-statistics which succeeded and can provide a log of this?
Disabled the not working calls like charging-statistics etc., but still no luck.
Seems the /v2/vehicles call returns different json content compared to how it looked like in former times with /v1/vehicles.
Therefore some rework is most likely required to the Java class Vehicle etc. to make the mapping from json content to the classes of the binding work again.
Does anybody know if BMW provides a good description or swagger about their API?
@weymann : Any additional hints to this topic, or are you willing to address these issues?
1 Like
Sorry for my ignorance, but I found that bimmerconnected which is working, uses
OCP_APIM_KEYS = {
Regions.NORTH_AMERICA: “MzFlMTAyZjUtNmY3ZS03ZWYzLTkwNDQtZGRjZTYzODkxMzYy”,
Regions.REST_OF_WORLD: “NGYxYzg1YTMtNzU4Zi1hMzdkLWJiYjYtZjg3MDQ0OTRhY2Zh”,
and mybmw binding uses
public static final String OCP_APIM_KEY_NORTH_AMERICA = “31e102f5-6f7e-7ef3-9044-ddce63891362”;
public static final String OCP_APIM_KEY_ROW = “4f1c85a3-758f-a37d-bbb6-f8704494acfa”;
The url seemed to be equal. Any idea
1 Like
@Dieter_Jannsen That is not the problem. The strings in the binding are already encoded. The first steps of the authentication work, but it fails in later steps. I can’t figure out where the difference is between bimmer connected and the binding.
Also, another observation: I did multiple tries with the bimmer connected cli. It works at first. But when you do a few tries with the same id, it starts blocking at the same step (first POST to https://customer.bmwgroup.com/gcdm/oauth/authenticate) as in the binding. Trying another ID then still works. Also the mobile app then seems to be lagging on refreshes. I can still control something, and then it will refresh, but a simple refresh request doesn’t do anything. They may be agressively blocking requests if they suspect unusual traffic from a source.
1 Like
so it looks like the v1 API is not working anymore as you get the error 500 in the log of myBmw binding.
If you look at the debug output of bimmer_connected cli sequence, you will recognize that they use v1 only for the first request, all subsequent requests are v2.
There you can as well see that now there are two requests for getting the vehicle details: /vehicles and afterwards /vehicles/{vin}/state.
I quickly implemented an extension to the MyBmwProxy class and got it working in a unit test, but the response looks completely different to the v1 one - so it will be a lot of mapping work to do 
You can find v1 JSON responses in the source code of the myBMW binding in src/test/resources/responses folder for comparison.
Maybe I find some time during the next evenings to get it working again…
5 Likes
@MartinOpenhabFan Great to see you are looking into this. I intended to start analyzing and coding as well. Let me know if I can help.
1 Like
Hi all,
I suspect it’s gonna take a while untill someone can fix this but I found out I can’t do anymore without at least the state of charge of our electric BMW in Openhab. So here’s a little workaround that sends the battery state of charge to mqtt.
Install bimmerconnected.
Put this in a shell script and run it periodically with a cronjob:
/path/to/bimmerconnected status user@domain "password" rest_of_world | grep chargingLevelPercent|sed 's/[^0-9]*//g' | mosquitto_pub -l --topic /bimmer/soc -h 192.168.xx.xx -p 1883
Now you can pick up the value with the mqtt binding.
Hope this is helpfull for someone. Happy Holidays
2 Likes
I came some steps further. But unfortunately I don’t have a PHEV or BEV available, so it would be good if somebody could send me the JSON output of bimmer_connected cli of such a vehicle.
VIN and location can be set to any value for anonymization.
1 Like
Hey guys, how is it going, any updates? Can you already estimate when the bindings works again?
Greets
Hi, I’m about to perform the last tests and if they are successful I will share the new jar the next days
10 Likes
Hi, finally I got everything working fine for my vehicles, so I’m sharing the first beta version with you here: GitHub - martingrassl/openhab-mybmw. The source code can be found here: GitHub - martingrassl/openhab-addons at 14065_fix_connected_v2_issues.
If you want to test the new version there are some things to consider:
- I didn’t want to change the plugin configuration of the Openhab things in my version, so currently only km are supported and not miles. I’m planning to add this configuration setting in the next days. The API changed, so I have to change the HTTP requests for that differentiation.
- I have only ICE vehicles, so I couldn’t test EV and PHEV
- I have tested successfully parsing the responses of an electric vehicle, but I couldn’t test charge statistics and charging sessions. So I don’t know if they are working
- there was a channel “motion” in the old API which I couldn’t find in the responses I have, so I deleted it.
- Although I didn’t change the channels, I observed that my sitemap mappings were not working correctly anymore as the image viewports changed. If you use the Main UI you should not recognize these changes.
- I don’t know if the commands were correct in the original version, but I observed that light-flash and horn-blow were wrong so I fixed them
- I successfully executed all the commands, I just observed that stop climate is not working, although the API responds with EXECUTED. If I stop via the myBMW app, it immediately stops
I installed the plugin to my productive environment and it looks like it is working fine since yesterday without any issues for my ICE vehicles
Installation
I had some errors with the authentication and the activation of my version, so I followed these steps:
- disable my vehicle things
- delete my bridge
- uninstall the binding
- copy the jar file to the addons folder
- check the logs (before I set the log level to debug) for entries like
bundle org.openhab.binding.mybmw:3.4.2.202301142226to check if the version 3.4.2 is loaded - create the bridge and set my credentials
- check in the logs if the discovery is successful
- enable the things of the vehicles
all channels were working fine like before.
It would be great if somebody could share with me the fingerprints of EV and PHEV vehicles for base vehicle, vehicle state, charging statistics and charging sessions. You can share with me the whole log file, but please be aware that the VIN is not anonymized in the URLs (difficult to identify the VIN part).
For those who are used to Java programming, you can clone my repo and run this unit test openhab-addons/MyBMWProxyBackendIT.java at 14065_fix_connected_v2_issues · martingrassl/openhab-addons · GitHub. It just executes all implemented backend requests and prints out the responses in the console. You have to set the BMW username and password either via environment variables, or you edit the file and enter them directly.
6 Likes
I have a 2er Grand Tourer (an ICE) and had been using your binding with a textual configuration:
Bridge mybmw:account:stephen "MyBMW Account" [userName="x.y@z.de",password="MYBMWPORTALPASSWORD",region="ROW"] {
Thing conv grandtourer "BMW 2er GT" [ vin="MYLONGVIN",refreshInterval=10,vehicleBrand="BMW"]
}
… and updated to your new version with this adapted procedure:
- commented out the bridge and my vehicle thing in my things file (=
grandtourer, see above) - uninstalled the old MyBMW binding
- copied your new jar file to the addons folder
/srv/openhab-sys/addons - immediately followed the logs and saw org.openhab.binding.mybmw:3.4.2.202301142226 being loaded!
- uncommented bridge and the thing
grandtourer… - … following the logs and seeing the items being populated with up-to-date values! Success!
I will try the lights, the honk and the heating the next days!
Keep up the good work! Thank you! Stephen
1 Like
Many thanks for your great work. Also for me (2er from 2019) all values are back.
1 Like
Many thanks for the changed binding. All data and the picture are up to date again. (BMW Z4 2021).
1 Like
I had some trouble with step 2 and 3 because the MainUI just wouldn´t perform the actions.
I had to force the removal of the bridge and uninstall the binding from the openhab-cli.
After that it was no problem to add your binding and get it running.
My 3 series from 05/2022 is working fine
Thanks for your work!