BMW ConnectedDrive Binding

Correct description by Ronald - thanks!

In the readme.md it’s described which value enables which channel group

CheckControl is valid for all cars but in principle off most of the time. I get these from time to time e.g. after changing to winter tyres the system demands a new RDC calibration. Perhaps you’ve to wait until wiper fluid runs dry. In this case you’ll receive a valid CheckControl message.

1 Like

Hi Bernd,
great work - I hope it will make it into the pool of bindings … I really had a hard time finding this !!

Please allow me two comments (using org.openhab.binding.bmwconnecteddrive-2.5.9-SNAPSHOT.jar):

  • typo in “unkown” for status of windows and doors
  • maybe you add into sitemap per item visibility=[i3DriverDoor!=“UNKNOWN”] to avoid the listing of none existing windows and sunroofs

Danke
Michael

BTW:
How to show a nice map of the vehicle location:

items:
Location i3Location “Standort BMW i3”

sitemap:
Frame label=“Position” {
Mapview item=i3Location height=10 icon=movecontrol
}

rules:
After:
i3LatLongElectric.sendCommand(latitudeNumber.floatValue+","+longitudeNumber.floatValue)
Add:
i3Location.sendCommand(latitudeNumber.floatValue+","+longitudeNumber.floatValue)

Hi,
I can confirm CheckControl is working (for at least one CheckControl message) as I have an active message showing up the car and also nicely in OpenHab: ‘Tyre pressure notification’.

1 Like

Works fine

Hello Guys,
I was trying to make this work with my bmw m8. I have an account registered to ConnectedDrive, as region i set North_America and no matter if i configure the binding via ui or via file creations I still get a error each time I try to add my bmw account

==> /var/log/openhab2/openhab.log <==
2020-12-01 06:42:05.158 [INFO ] [internal.handler.ConnectedDriveProxy] - Auth https://customer.bmwgroup.com/gcdm/usa/oauth/token
2020-12-01 06:42:06.387 [INFO ] [internal.handler.ConnectedDriveProxy] - Response Code 200 Message OK

==> /var/log/openhab2/events.log <==
2020-12-01 06:42:06.779 [hingStatusInfoChangedEvent] - ‘bmwconnecteddrive:account:6f721e38’ changed from UNKNOWN to OFFLINE (COMMUNICATION_ERROR): Unauthorized

I also tried selecting other regions and the error code changes.

Please advise, thanks!

Thanks,

typo in code is fixed. Also applied visibility changes in the sitemap. Nevertheless I’ve chosen INVALID instead of UNKNOWN . This is the value shown for e.g. the rear window of my car which doesn’t apply. With this sitemap update it disappeared!

Hi @Radu_Marius,

sorry for the late reply. It seems mid November again something was changed in the North America authorization. I fetched the changes from Bimmer Connected project and I also made a North America account for me to test it.

Please check the latest update and test if you receive your car informations.

@weymann
Thank you!
I used the latest version and the account worked with no errors.

1 Like

Will there come a version for OH3? :blush:

Yes, Pull Request for OH3 is raised, first reviews are done and I’m working now solving the review comments.

Preleminary Test Bundle is available here. There are already some changes due to review comments which I won’t port to 2.5.

  • Lists for CheckControl, Services and last destinations will be handled different
  • Location type is used instead of seperate latitude/longitude channels
  • troubleshoot fingerprint will be printed at startup and not longer via channels

Check for the adapted *.items file and you’ll see the changes.

1 Like

I’m trying out the latest OH3 binding. And at first sight, most is working out of the box. I just had to remove the car (thing), and let it recognize it again. Then it came online without issues.
I’ll check some extra things once I move the car around.

Maybe one extra for your bmw.rules? A convertion for the wind direction? A bit more human readable. :wink:

rule "BMW Heading"
when
        Item x1Heading changed
then
        if (x1Heading.state < 22.5 | "°" )                      { x1HeadingHuman.postUpdate("North") }
        else if (x1Heading.state < 22.5 | "°"  + 45 | "°" )     { x1HeadingHuman.postUpdate("NorthEast") }
        else if (x1Heading.state < 22.5 | "°"  + 90 | "°" )     { x1HeadingHuman.postUpdate("East") }
        else if (x1Heading.state < 22.5 | "°"  + 135 | "°" )    { x1HeadingHuman.postUpdate("SouthEast") }
        else if (x1Heading.state < 22.5 | "°"  + 180 | "°" )    { x1HeadingHuman.postUpdate("South") }
        else if (x1Heading.state < 22.5 | "°"  + 225 | "°" )    { x1HeadingHuman.postUpdate("SouthWest") }
        else if (x1Heading.state < 22.5 | "°"  + 270 | "°" )    { x1HeadingHuman.postUpdate("West") }
        else if (x1Heading.state < 22.5 | "°"  + 315 | "°" )    { x1HeadingHuman.postUpdate("NorthWest") }
end

@weymann I just wanted to ask if it might be possible to update the “Charge Window Start Time” and “Charge Window End Time” values from within openhab? I want to make a rule that can update those values each day as I’m switching to a daily variable energy tarrif so my ideal charge time will change. I can update the values from within the BMW app so I guess that means there might be hope? No worries if it isn’t possible, just thought I’d ask!

Hi @Matt_Cholawo, got the same request a while ago via direct message with the correspondig API calls. So there’s more than hope - it will be implemented.

1 Like

@Matt_Cholawo: I was missing this feature as well, so I did add additional channels for all hour and minute-values plus the corresponding command-handling-code to allow easy update of all charge-profile properties. Sending the updated charging-profile to the car is also implemented.
@weymann Please see the pull-request I sent you:

Anybody interested in testing can get the compiled binding here:

2 Likes

regarding my pullrequest - I did add a whole bunch of new channels. One StringType Channel per Timer and Day, Two Number-type channels (hour + minute) per Timer and time, same for times of preferedChargingWindow.
That eases use of existing widgets (SetPoint and Switch) to modify everything from the UI without any additional Rules. In fact I can now use a simple Sitemap in BasicUI and do everything I can do in the original BMW app just using of-the-shelf widgets.
Of course that can be done differently - make the existing String-type channels accept updates as simple (but complex formated) String-commands. While you cannot update those with standard widgets the transformation of hour+minute and concatination of individual Weekdays can be done with rules. I could move that transformation-code into an Action-module so one might use this to link Switch and Number-items to the complex-typed channels with configuration only. I’m not sure what is the prefered way in the openhab community which way to go.

I see that there’s big demand on editing the charge profile. Thanks to @ntruchsess who started already a Pull Request on OH3. I started implementing this feature on 2.5 a while ago and it turned out it’s not that easy as I thought.

I documented everthing in the readme.md so please take some minutes and check the notes.
Take the newest bundle and update items and sitemap example - it contains all required items to edit the charge profile in UI.

Let me highlight 2 things which I observed during development:

Single Timer
It isn’t working at all on my side. This Timer also doesn’t work in the My BMW App. It results into Http Status 500 - Internal Server errors. Maybe you’ll observe the same behavior. As said this isn’t a flaw of the binding

Rules
Already mentioned in readme but really important. If you’re using rules + editing in UI you need to be aware about the timeframe of execution. If you and a rule are editing the charge profile at the same time you’ll get mixed up results!

I’m looking forward to get your feedback!

1 Like

regarding the single Timer: my observation is: you always have to include all timers (including the ‘override timer’. For me the override-timer is not good for anything - to schedule a single-shot timer I have to schedule a timer that has no days set. In the car it will execute a single time and deactivate afterwards. (I do own an i3 from 2020 (NBT Evo ID6). In my previous i3 from 2017 (NBT ID4) the behavior was the same).

EDIT: reviewing your latest commits on branch ‘bmw-connected-drive-test’ I guess I found what you refer to as ‘newest bundle’ ;-). So I guess my PR is obsolete then and I should rather see what I can contribute to this branch?

Hi,

as I’m very new to openhab I’m struggling with installing this binding.
Could someone please help me on how to install it.

Thx you very much for your support!

BR
Mathias

Hi Mathias,

this isn’t an official released binding so you need to install it manually => Installation of Add-ons | openHAB
Basically: Drop the jar from the top post into the addons folder.