Awesome work, Bernd! I just tested it with my X1 PHEV, it‘s perfect!!!
Will the binding be directly installable with openHAB 3.1?
I still hope it will be included in OH3.1 update. We worked on all open issues from the last review and waiting for the final approval.
2 Likes
today the pullrequest was merged ! 
2 Likes
Thanks @ntruchsess for your great contribution! Besides all the review trouble we really achieved a great first version of this BMW binding and I truely belive many users will benefit.
6 Likes
Many thanks for your efforts to create this binding, which will replace a self-written script!!! 
Would it be possible to make following information available as channels as well:
- webapi/v1/user/vehicles → vehicleStatus → updateReason (reason why last update occured)
- webapi/v1/user/vehicles → vehicleStatus → maxRangeElectric (maximum range with full battery)
- webapi/v1/user/vehicles → vehicleStatus → connectionStatus (connection status)
- webapi/v1/user/vehicles → vehicleStatus → chargingStatus (charging status)
- api/vehicle/navigation → socmax (energy capacity of battery)
As far as I can read the code, some of these information are already requested from API and stored in the data modell, but not made available as channel.
When I started some of these information seemed not really benefical for any use case in my mind. But this is only my opinion, perhaps you’ve something specific in mind
- chargingStatus this is in
- connectionStatus if cable is connected or not is superfluous to chargingStatus. If cable is connected and e.g. charge is delayed due to a ChargeProfile chargingStatus reports wait for charging or in case of a roblem error status is reported
- updateReason I don’t have a list of all possible reasons. Most time I see Vehicle Shutdown or Door State Changed. Might be something for UI display but to be honest I don’t see how this info can be used anywhere.
- maxRangeElectric Maybe a candidate for adding. For now I see it as a derived value - if you take remainingRangeElectric / chargeLevel * 100 you’ll have nearly the same value
- socmax this is a static value and from my official review experience there will be the request to add this to the Thing Properties instead of a Channel - it will only change if the car gets a new battery
Don’t misunderstand me - I’ve no problems adding these infos technically to the binding. But we already have an overwhelming amount of Channels and we should only add information which is beneficial for some use cases.
Thanks for your replay… Sorry that I didn’t see the chargingStatus. Some thoughts and information from my side for further discussions.
connectionStatus
- This information gets interesting if you are using a smart Wallbox, which only charges when solar power is available. In such cases chargingStatus and connectionStatus are not linked anymore as car might not be charging although it is connected.
- Possible use case: If vehicle at home (according to location information) and connectionStatus != CONNECTED, send a reminder “Forgot to connect the car to Wallbox?”
updateReason
- Possible values are (not all occured in my use case): CHARGING_DONE, CHARGING_INTERRUPED, CHARGING_PAUSED, CHARGING_STARTED, CYCLIC_RECHARGING, DISCONNECTED, DOOR_STATE_CHANGED, NO_CYCLIC_RECHARGING, NO_LSC_TRIGGER, ON_DEMAND, PREDICTION_UPDATE, TEMPORARY_POWER_SUPPLY_FAILURE, UNKNOWN, VEHICLE_MOVING, VEHICLE_SECURED, VEHICLE_SHUTDOWN, VEHICLE_SHUTDOWN_SECURED, VEHICLE_UNSECURED
- So far I have seen one usecase: if value = VEHICLE_MOVING, then car is in use. But there might be more other use cases too.
maxRangeElectric
- You are right, this might be possible to calculate, but maybe the “car takes some more information into consideration” (e.g. temperature, heating, air con). I would say, why calculate values manually if a value exists from API.
socmax
- From my point of investigation this is not a static value. I track this value since 9 months (for my PHEV) and it decreased from 9,0 kWh (new car/battery in summer) to 8,1 kWh (in winter) and now increases again.
Are you sure? I once had a script that was able to pull the current max Ah capacity of the Battery. Maybe this is meant by socmax.
Very very interesting value since you can monitor the degradation of your Battery.
2 Likes
yes would be good if this socmax would be implemented. I also had with the script. many thanks
1 Like
I see: You know what you’re talking about These points are really valid.
The soc_max value mentioned by you, @sdda and @leiweke sounds really interesting. Unfortunately I cannot access the navigation API. Response says 403 forbidden but maybe this is caused that I don’t have the BMW Navigation package anymore.
Can you please check this binding snapshot in your environment? I placed some info messages so just check your logs regarding response.
1 Like
Thanks for taking my/our ideas into consideration and creating a snapshot in short time.
Tried to install the SNAPSHOT file, but didn’t get it to work. Downloaded it to /usr/share/openhab/addons on my 3.1.0.M4 installation, chown done as well. But the snapshot was not loaded or activated. Unfortunately my openhab developement/test skills are limited 
But did some experiments with the API. I assume you are using the authentication via https://b2vapi.bmwgroup.com/gcdm/oauth/token, correct? I think the responded token has not rights to access the navigation API.
Some time ago I found (somewhere in the WWW, sorry I don’t know the link anymore) a way to get a token via https://customer.bmwgroup.com/gcdm/oauth/authenticate. With this token it is possible to access the navigation information including the socmax value.
The OAUTH call with curl looks like this:
curl -X “POST” “https://customer.bmwgroup.com/gcdm/oauth/authenticate?client_id=dbf0a542-ebd1-4ff0-a9a7-55172fbfce35&redirect_uri=https://www.bmw-connecteddrive.com/app/default/static/external-dispatch.html&username=YOURUSERNAME&response_type=token&state=FOOBAR&scope=authenticate_user%20vehicle_data%20remote_services%20fupo&password=YOURPASSWORD&locale=en-en&state=FOOBAR” -v -H “User-Agent=okhttp/2.60” -d “Content-Length: 0”
The token then is included in the response, there should be a line like this:
Location: https://www.bmw-connecteddrive.com/app/default/static/external-dispatch.html#state=[FOOBAR, FOOBAR]&access_token=abcdefghijklmnopqrstuvwxyz&token_type=Bearer&expires_in=7199
I’m aware that this way of getting the token is not that nice compared to the other one, but it seems it’s the only way to get the socmax value.
Are you using this OAuth mechanism currently in your scripts? End of last year this method was not working anymore and I switched to the same OAuth as implemented in bimmer_connected repo. I use this as a reference because they are always up to date with their implementation.
Using their software I get the same response
DEBUG:bimmer_connected.account:The BMW Connected Drive portal returned an error: UNKNOWN_ERROR (received status code 403 and expected 200).
DEBUG:bimmer_connected.account:
DEBUG:bimmer_connected.state:Service NAVIGATION failed
I wonder why installing doesn’t work on your side. Did you install the BMW binding in the UI? If yes
- uninstall the binding in Settings but keep your Things / Items and all of that
- Things will appear Uninitialized with Handler missing error after this action.
- place the snapshot in addons folder - Things shall be online again and the snapshot is used
- Maybe also a restart with systemctl restart openhab because sometimes OH3 is quite picky when changing the binding during runtime.
- Check if you can find the update reason in the channels.
Yes, this method is in use here and if you give it a try with the mentioned CURL command you will get a token. But be careful when Copy&Pasting, that normal " are used, otherwise there might be errors.
Unfortunately it doesn’t work here… After uninstall, copy of snapshot to /usr/share/openhab/addons and restart of OH3 BMW things are shown as UNINITIALIZED. After re-installation of binding via UI it goes ONLINE again.
Ok, this was quite a nightmare.
Authenticate method is working like described but somehow java is doing something different. Jetty Client doesn’t answer properly so I used standard libs from java and I receive now the soc-max values for Rest of World. But it seems it doesn’t work for North America at all and it’s hard for to investigate this.
When checking your update problem I switched to 3.1 Milestone 4 and this caused a big headache. All of my development binding don’t work anymore. I raised an issue and this seems to be a known problem. Switching to last release 3.0.2 also didn’t help. So I patched my development binding to be able to run it from addons folder.
Long story short: Yes the binding snapshot in the previous link didn’t work - no problem on your side. Give the updated binding from the above link another try.
1 Like
I would like to thank you for the add-on! Works perfectly on my i3 providing all the details (just installed and tested on the 3.1.0 M4). The only thing “missing” for me (so I would dismantle my existing phyton script) is socmax which shows the battery health over the period of time. It would be really helpful to have this value available as a channel. Below is an example how this value is changing (usually depending on the temperature):
Did you check the updated binding just in the post before?
I cannot say because I rolled back from 3.1M4 due to many problems on my other installed bindings. Also there are problems providing test bindings for the current Milestone. Just uninstall the BMW binding in OH UI - Settings and drop the snapshot from the previous post in the addons folder.
Please give me hint if this is working or not.
Thanks for your efforts… Installation of snapshot worked now.
I can see channels about connectionStatus, updateReason, maxRangeElectric and socmax now. And on first look they work well. I’ll use the snapshot binding the next days and will let you know, if I see any issues.
Great job!!!
P.S. Messages in log look like this (hopefully as you expected):
2021-05-17 01:03:30.668 [INFO ] [ternal.handler.VehicleChannelHandler] - {“latitude”:xx.xxxxxx,“longitude”:xx.xxxx,“auxPowerRegular”:1.0,“auxPowerEcoPro”:1.0,“auxPowerEcoProPlus”:1.0,“soc”:45.0,“pendingUpdate”:false,“vehicleTracking”:true,“socmax”:8.24}
Can that be, that I am still using the wrong snapshot? I took this one and stored to the addons folder. I cleared the OH cache and tmp directories to assure that there are no file clashes. I am on 3.1.0 M4 just in case it is relevant.
Looks like the jar is also loaded:
I am still unable to find the socmax channel.
For me it was necessary to remove the car thing (not the bridge) and create new to see the additional channels.
Just removed and created the car again - same result, the channel is not listed. I am OK to wait till this binding is merged into M5 (?) so I can test it again. Not sure what else could be of help.