thanks a lot for all your effort!
Now, I finally installed openhab 4.1.1…
But I am using the official release branch (“openhab”) and not the “main” branch. You wrote that your latest binding was merged into the “main OH branch”.
Do I need to switch to the “main” branch to get the latest binding?
Currently my car is going offline again and again for long time periods (“Vehicle State Update failed”).
The refresh is set to 2 minutes. (I would even like to reduce it to 1 min. again to trace the car )
The new binding is included in the official release of OH 4.1.x, so everything should be done on your side. But you can see above that since some time everybody has an issue because BMW defined a quota for the number of requests per client and this issue hits you now. I set the interval to 15 minutes and it looks like most of the time the requests are successful. You just can’t trigger many commands.
The vehicle-states are the most important and I would like to refresh them as often as possible.
Charging-statistics and -sessions are not so important and once per day would be enough.
Is there a possibility to refresh those only once a day?
Or am I able to exclude this data from the request?
This is a good point. As I don’t have an EV those requests are not triggered in my installation. Maybe I could create separate interval configurations for state and charging info and in addition a channel for actively triggering each type of request… right now this is unfortunately not possible.
But I still do not trust the “out of quota”-error. I have the feeling it is randomly created. Of course more often, when the refresh rate is shorter.
When the “out of quota”-error is triggered the error massage says that the “quota” will be reset in the next full hour. But the next refresh is most of the time possible even before reaching the full hour.
e.g.: error massage at 11:35:10. quota will be reset in 00:24:50.
But even 5 minutes later with the next refresh it is possible to query the data again…
Furthermore I cannot identify a pattern when it appears.
I just noticed that 3 (x3) requests per 10 minute (refresh rate = 3 minutes) will raise the error.
I created a new SNAPSHOT version which can help to resolve the quota issue.
Main changes:
allow to set the refresh-interval to 0 to avoid automated updates
introduce new channels for forcing the API updates, separated by state, charging and image requests.
This means you can now use the switches to control the API updates via Openhab rules. The switches will be automatically set to OFF when you set them to ON
@Tomasz_W, I created a 3.4.5 version as well, sorry for taking so long. I could test it successfully in a sandbox installation, just for existing vehicles the new channels were not added. If you remove the vehicle and trigger the discovery to get it again, you should get the new channels.
Anyhow, please create a backup before using the new version.
thanks a lot for providing this update! It is great!
I set the update interval to 0 and created a rule running every 2 minutes updating the vehicle status.
The image will only be updated if openhab restarted or once at midnight.
Charging status will only be updated on request.
It is just running for a few minutes but I was able to refresh the status 5 times in 10 minutes without complains from the server.
Thanks a lot again! I will continue monitoring it and even set the the interval to 1 minute.
that’s weird. I see the same in my 3.4.5 installation and no errors in the logs. I just copied the source code from 4.2.x to 3.4.x as I’m not really aware that there were significant changes in the code regarding discovery, but I could be wrong.
Nevertheless if you have a vehicle configured before upgrading, then at least in my installation I see these channels on top:
After some testing I changed the status-refreshrate to 3 minutes.
From time to time it still shows an out-of-quota-error (2-3 times per hour).
Update: But I created a rule running every minute triggering an update if the last successful update is older than the defined refresh rate:
if (now.toLocalDateTime() >= (BMW_Status_Last_Fetched.state as DateTimeType).getZonedDateTime().plusMinutes((BMW_Refreshrate.state as Number).intValue).minusSeconds(3).toLocalDateTime()) {
BMW_Update_State.sendCommand(ON)
}
Now I am able to reach a stable refresh rate of 3-4 minutes.
charging-update is updating the charging statistics and the charging sessions, image is updating just the vehicle image (can be cached), the state update is fetching all other channels/properties.
Yes, thank you… This information should be added to documentation as well.
Another question:
Which of the three update categories is now reflected in the status#last-update channel?
Does it make sense to include one of such a channel per update group?
The documentation is updated, just not completely taken over in the SNAPSHOT repo…
The last-update timestamp comes from BMW and is only available in the status response…
I am not able to connect to the server since Friday evening.
It said: not_ready_yet
I disabled the car-thing and tried to enable it again but it does not let me and shows: Error while disabling or enabling: Server Error
The account-thing is connected.
Anyone else has the same issue?
I was able to solve it by removing the car-thing and creating it again.
Yesterday I updated the system via openhab-config. Maybe this was causing the issue…
Really glad to see that there is activity arround this binding. For a few weeks now I own a 550e PHEV and would love to use this binding.
I run OH 4.1.1 and installed the 4.1.2 SNAPSHOT from Github adding it manually to the OH Add-ons folder.
I was successfully able to setup the Bridge (BMW Benutzerkonto) but don’t get the “Plug-in-Hybrid Elektrofahrzeug” to work. It says COMMUNICATION_ERROR Vehicle State Update failed.
(Scan did not discover the vehicle, I added it manually picking the phev template)
Was trying to create a fingerprint, but it says:
Start fingerprint
Account 1
Vehicles base for brand bmw
Fingerprint failed, network exception:
End account 1
Exception zipping fingerprint: /var/lib/openhab/mybmw/20240306.zip (No such file or directory)
Fingerprint has been written to files in directory: /var/lib/openhab/mybmw/20240306
End fingerprint
Any idea what I did wrong? Any information I can provide to gain more insight?
Nice that you want to use the binding! So the bridge thing shows the status online? Maybe stupid question, but is the car available in the myBMW app and can you see all the data there?
I’m wondering why the discovery failed. This network exception looks a bit suspect to me.
Did you install the binding before already from the official repo? I faced an issue that after putting the jar file to the addons folder OH was still using the old version. What happens if you restart OH?
You could as well enable the debug logging in the addon configuration in the UI and check the error message in the log files.
Hi Martin, thanks for you quick response. Based on your comments I uninstalled the binding, stopped OH, reinstalled the binding and restarted OH. …. and guess what …. it functions!
Thanks again for your replay and challenging me with questions! Best Arnostrong text
The binding version 4.1.1 seems to have a strange bug…
The car wont come online and just sits in “Not yet ready”.
When disabling the thing, i can´t enabled it because it throws an error.
The same happens when you try to remove the thing, it just stays on “removing” and nothing happens…
2024-03-07 14:34:23.766 [WARN ] [core.thing.internal.ThingManagerImpl] - Channel types or config descriptions for thing 'mybmw:conv:m340i:WBA...' are missing in the respective registry for more than 120s. In case it does not happen immediately after an upgrade, it should be fixed in the binding.
2024-03-07 14:34:23.767 [ERROR] [core.thing.internal.ThingManagerImpl] - Checking/initializing thing 'mybmw:conv:m340i:WBA...' failed unexpectedly.
java.lang.IllegalArgumentException: Duplicate channels mybmw:conv:m340i:WBA...:status#last-fetched
at org.openhab.core.thing.util.ThingHelper.ensureUniqueChannels(ThingHelper.java:135) ~[?:?]
at org.openhab.core.thing.util.ThingHelper.ensureUniqueChannels(ThingHelper.java:127) ~[?:?]
at org.openhab.core.thing.util.ThingHelper.ensureUniqueChannels(ThingHelper.java:123) ~[?:?]
at org.openhab.core.thing.binding.builder.ThingBuilder.withChannel(ThingBuilder.java:123) ~[?:?]
at org.openhab.core.thing.internal.update.UpdateChannelInstructionImpl.doChannel(UpdateChannelInstructionImpl.java:140) ~[?:?]
at org.openhab.core.thing.internal.update.UpdateChannelInstructionImpl.lambda$0(UpdateChannelInstructionImpl.java:101) ~[?:?]
at java.util.Arrays$ArrayList.forEach(Arrays.java:4204) ~[?:?]
at org.openhab.core.thing.internal.update.UpdateChannelInstructionImpl.perform(UpdateChannelInstructionImpl.java:101) ~[?:?]
at org.openhab.core.thing.internal.ThingManagerImpl.lambda$17(ThingManagerImpl.java:1095) ~[?:?]
at java.lang.Iterable.forEach(Iterable.java:75) ~[?:?]
at org.openhab.core.thing.internal.ThingManagerImpl.checkAndPerformUpdate(ThingManagerImpl.java:1095) ~[?:?]
at org.openhab.core.thing.internal.ThingManagerImpl.registerAndInitializeHandler(ThingManagerImpl.java:918) ~[?:?]
at org.openhab.core.thing.internal.ThingManagerImpl.checkMissingPrerequisites(ThingManagerImpl.java:1124) ~[?:?]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:539) [?:?]
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:305) [?:?]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:305) [?:?]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136) [?:?]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635) [?:?]
at java.lang.Thread.run(Thread.java:840) [?:?]
2024-03-07 14:34:05.160 [DEBUG] [ernal.handler.backend.MyBMWHttpProxy] - ###### Request URL - BEGIN ######
2024-03-07 14:34:05.161 [DEBUG] [ernal.handler.backend.MyBMWHttpProxy] - https://cocoapi.bmwgroup.com/eadrax-vcs/v4/vehicles
2024-03-07 14:34:05.161 [DEBUG] [ernal.handler.backend.MyBMWHttpProxy] - ###### Request Body - BEGIN ######
2024-03-07 14:34:05.161 [DEBUG] [ernal.handler.backend.MyBMWHttpProxy] -
2024-03-07 14:34:05.161 [DEBUG] [ernal.handler.backend.MyBMWHttpProxy] - ###### Response Data - BEGIN ######
2024-03-07 14:34:05.161 [DEBUG] [ernal.handler.backend.MyBMWHttpProxy] - { "statusCode": 403, "message": "Out of call volume quota. Quota will be replenished in 00:25:55." }
2024-03-07 14:34:05.162 [DEBUG] [ernal.handler.backend.MyBMWHttpProxy] - ###### Response Data - END ######
2024-03-07 14:34:05.162 [WARN ] [ernal.handler.backend.MyBMWHttpProxy] - error retrieving the base vehicles for brand mini: null
2024-03-07 14:34:05.179 [DEBUG] [ernal.handler.backend.MyBMWHttpProxy] - ###### Request URL - BEGIN ######
2024-03-07 14:34:05.179 [DEBUG] [ernal.handler.backend.MyBMWHttpProxy] - https://cocoapi.bmwgroup.com/eadrax-vcs/v4/vehicles/state
2024-03-07 14:34:05.179 [DEBUG] [ernal.handler.backend.MyBMWHttpProxy] - ###### Request Body - BEGIN ######
2024-03-07 14:34:05.179 [DEBUG] [ernal.handler.backend.MyBMWHttpProxy] -
2024-03-07 14:34:05.180 [DEBUG] [ernal.handler.backend.MyBMWHttpProxy] - ###### Response Data - BEGIN ######
2024-03-07 14:34:05.180 [DEBUG] [ernal.handler.backend.MyBMWHttpProxy] - { "statusCode": 403, "message": "Out of call volume quota. Quota will be replenished in 00:25:55." }
2024-03-07 14:34:05.180 [DEBUG] [ernal.handler.backend.MyBMWHttpProxy] - ###### Response Data - END ######
2024-03-07 14:34:05.180 [TRACE] [.internal.handler.MyBMWBridgeHandler] - MyBMWBridgeHandler.vehicleDiscoveryError
==> /var/log/openhab/events.log <==
2024-03-07 14:34:05.181 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'mybmw:account:home' changed from UNKNOWN to OFFLINE (COMMUNICATION_ERROR): Request vehicles failed
)
