Dare @MartinOpenhabFan, I think many of us are using OH 3.4.5 still. would it be and extremely extra effort to build 3.4.5 version
Hi @Tomasz_W , I don’t know how many users are still using 3.4.5, but I can try to build a version within the next days.
Thank you @MartinOpenhabFan !!!
I use more than 20 bindings, and many of them are not working well in 4.1.0 yet.
Hi,
acutally i got this error message every few minutes in my logs from mileage item.
Any ideas?
19:03:01.684 [ERROR] [rd4j.internal.RRD4jPersistenceService] - Could not create rrd4j database file '/openhab/userdata/persistence/rrd4j/Mileage.rrd': Invalid file header. File [/openhab/userdata/persistence/rrd4j/Mileage.rrd] is not a RRD4J RRD file
This is the acutal state of the item:
15408000 m
It is no issue caused by the binding but the file is corrupted.
You can delete the file and rrd4j will create a new one.
1 Like
thank you!
The new 4.1.0 jar file on GitHub works for me… Status of bridge and verhicle is “online” and status updates from the car are received.
1 Like
Hi,
when I add current 4.1.0 jar file (updated 2 days ago) to my addons folder I get the this warning
2023-12-14 08:28:26.322 [WARN ] [org.apache.felix.fileinstall ] - Error while starting bundle: file:/usr/share/openhab/addons/org.openhab.binding.mybmw-4.1.0-SNAPSHOT-2023-12-12.jar
org.osgi.framework.BundleException: Could not resolve module: org.openhab.binding.mybmw [305]
Unresolved requirement: Import-Package: com.google.gson; version="[2.10.0,3.0.0)"
at org.eclipse.osgi.container.Module.start(Module.java:463) ~[org.eclipse.osgi-3.18.0.jar:?]
at org.eclipse.osgi.internal.framework.EquinoxBundle.start(EquinoxBundle.java:445) ~[org.eclipse.osgi-3.18.0.jar:?]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundle(DirectoryWatcher.java:1260) ~[?:?]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundles(DirectoryWatcher.java:1233) ~[?:?]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.doProcess(DirectoryWatcher.java:520) ~[?:?]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:365) ~[?:?]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:316) ~[?:?]
and my account thing shows HANDLER_MISSING_ERROR.
In my Console (OH 4.0.4) I see that I have GSON version 2.9.1 installed instead of 2.10.0.
bundle:list -s | grep gson
36 x Active x 80 x 2.9.1 x com.google.gson
I assume 2.9.1 is required for OH 4.0.4 and 2.10.0 might be introduced with OH 4.1.0.
Would it be possible / advisable to install 2.10.0 in parallel to 2.9.1 via “drop gson-2.10.jar in addons folder” without messing up my current OH 4.0.4?
Hi @jimmbimm I wouldn’t do that as I don’t know which side effects it would have. It’s the 4.0 SNAPSHOT not working anymore? Anyhow, it looks like 4.1.0 will be released soon…
Ok, thanks a lot for the feedback.
The 4.0 binding snapshot works in general, but the car thing goes offline sporadically.
That’s why I tried an earlier version of the 4.1 binding snapshot a couple of weeks ago which worked with my OH 4.0.4 system but with the car thing still going offline sporadically.
And now I was hoping that with the latest 4.1 binding snapshot version maybe the car thing would be more stable.
Yes 
, I wait for OH 4.1.0, thanks 
Hi all,
good news - the last changes were merged into the main OH branch and now OH 4.1 includes a working myBMW binding again 
The only major thing I couldn’t fix so far is the quota limit which the API got recently. I’ll try to provide a fix for that, but right now a possible solution is to add the vehicles by VIN manually as thing to OH and wait for recovery. Even if the bridge remains offline, the things should go online after some time, which could be sometimes almost about an hour.
Feedback very welcome
1 Like
I installed OH4.1 two days ago and the BMW binding is working for me.
Thanks Martin for your work!
1 Like
Hello Martin,
I am sorry but it is not working for me anymore after upgrade to 4.1.0. On 4.0.4 using the 4.1 snapshot everything was fine.
After a short while, I am not able to say when, I get following error:
2023-12-25 17:56:03.453 [ERROR] [internal.JSONResponseExceptionMapper] - Unexpected exception occurred while processing REST request.
java.lang.IllegalArgumentException: Duplicate channels mybmw:conv:3e4b4eac18:WBA6U510307E03830: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.setEnabled(ThingManagerImpl.java:1009) ~[?:?]
at org.openhab.core.io.rest.core.internal.thing.ThingResource.setEnabled(ThingResource.java:608) ~[?:?]
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:?]
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77) ~[?:?]
at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:?]
at java.lang.reflect.Method.invoke(Method.java:568) ~[?:?]
at org.apache.cxf.service.invoker.AbstractInvoker.performInvocation(AbstractInvoker.java:179) ~[bundleFile:3.6.2]
at org.apache.cxf.service.invoker.AbstractInvoker.invoke(AbstractInvoker.java:96) ~[bundleFile:3.6.2]
at org.apache.cxf.jaxrs.JAXRSInvoker.invoke(JAXRSInvoker.java:201) ~[bundleFile:3.6.2]
at org.apache.cxf.jaxrs.JAXRSInvoker.invoke(JAXRSInvoker.java:104) ~[bundleFile:3.6.2]
at org.apache.cxf.interceptor.ServiceInvokerInterceptor$1.run(ServiceInvokerInterceptor.java:59) ~[bundleFile:3.6.2]
at org.apache.cxf.interceptor.ServiceInvokerInterceptor.handleMessage(ServiceInvokerInterceptor.java:96) ~[bundleFile:3.6.2]
at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:307) ~[bundleFile:3.6.2]
at org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:121) ~[bundleFile:3.6.2]
at org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(AbstractHTTPDestination.java:265) ~[bundleFile:3.6.2]
at org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:234) ~[bundleFile:3.6.2]
at org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:208) ~[bundleFile:3.6.2]
at org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:160) ~[bundleFile:3.6.2]
at org.apache.cxf.transport.servlet.CXFNonSpringServlet.invoke(CXFNonSpringServlet.java:225) ~[bundleFile:3.6.2]
at org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:304) ~[bundleFile:3.6.2]
at org.apache.cxf.transport.servlet.AbstractHTTPServlet.doPut(AbstractHTTPServlet.java:234) ~[bundleFile:3.6.2]
at javax.servlet.http.HttpServlet.service(HttpServlet.java:520) ~[bundleFile:4.0.4]
at org.apache.cxf.transport.servlet.AbstractHTTPServlet.service(AbstractHTTPServlet.java:279) ~[bundleFile:3.6.2]
at org.ops4j.pax.web.service.spi.servlet.OsgiInitializedServlet.service(OsgiInitializedServlet.java:102) ~[bundleFile:?]
at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:799) ~[bundleFile:9.4.52.v20230823]
at org.eclipse.jetty.servlet.ServletHandler$ChainEnd.doFilter(ServletHandler.java:1656) ~[bundleFile:9.4.52.v20230823]
at org.ops4j.pax.web.service.spi.servlet.OsgiFilterChain.doFilter(OsgiFilterChain.java:100) ~[bundleFile:?]
at org.ops4j.pax.web.service.jetty.internal.PaxWebServletHandler.doHandle(PaxWebServletHandler.java:320) ~[bundleFile:?]
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143) ~[bundleFile:9.4.52.v20230823]
at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:600) ~[bundleFile:9.4.52.v20230823]
at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127) ~[bundleFile:9.4.52.v20230823]
at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:235) ~[bundleFile:9.4.52.v20230823]
at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1624) ~[bundleFile:9.4.52.v20230823]
at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:233) ~[bundleFile:9.4.52.v20230823]
at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1440) ~[bundleFile:9.4.52.v20230823]
at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:188) ~[bundleFile:9.4.52.v20230823]
at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:505) ~[bundleFile:9.4.52.v20230823]
at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1594) ~[bundleFile:9.4.52.v20230823]
at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:186) ~[bundleFile:9.4.52.v20230823]
at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1355) ~[bundleFile:9.4.52.v20230823]
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141) ~[bundleFile:9.4.52.v20230823]
at org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:234) ~[bundleFile:9.4.52.v20230823]
at org.ops4j.pax.web.service.jetty.internal.PrioritizedHandlerCollection.handle(PrioritizedHandlerCollection.java:96) ~[bundleFile:?]
at org.eclipse.jetty.server.handler.gzip.GzipHandler.handle(GzipHandler.java:722) ~[bundleFile:9.4.52.v20230823]
at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127) ~[bundleFile:9.4.52.v20230823]
at org.eclipse.jetty.server.Server.handle(Server.java:516) ~[bundleFile:9.4.52.v20230823]
at org.eclipse.jetty.server.HttpChannel.lambda$handle$1(HttpChannel.java:487) ~[bundleFile:9.4.52.v20230823]
at org.eclipse.jetty.server.HttpChannel.dispatch(HttpChannel.java:732) [bundleFile:9.4.52.v20230823]
at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:479) [bundleFile:9.4.52.v20230823]
at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:277) [bundleFile:9.4.52.v20230823]
at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:311) [bundleFile:9.4.52.v20230823]
at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:105) [bundleFile:9.4.52.v20230823]
at org.eclipse.jetty.io.ssl.SslConnection$DecryptedEndPoint.onFillable(SslConnection.java:555) [bundleFile:9.4.52.v20230823]
at org.eclipse.jetty.io.ssl.SslConnection.onFillable(SslConnection.java:410) [bundleFile:9.4.52.v20230823]
at org.eclipse.jetty.io.ssl.SslConnection$2.succeeded(SslConnection.java:164) [bundleFile:9.4.52.v20230823]
at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:105) [bundleFile:9.4.52.v20230823]
at org.eclipse.jetty.io.ChannelEndPoint$1.run(ChannelEndPoint.java:104) [bundleFile:9.4.52.v20230823]
at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:338) [bundleFile:9.4.52.v20230823]
at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:315) [bundleFile:9.4.52.v20230823]
at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:173) [bundleFile:9.4.52.v20230823]
at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:131) [bundleFile:9.4.52.v20230823]
at org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:409) [bundleFile:9.4.52.v20230823]
at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:883) [bundleFile:9.4.52.v20230823]
at org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.run(QueuedThreadPool.java:1034) [bundleFile:9.4.52.v20230823]
at java.lang.Thread.run(Thread.java:840) [?:?]
Any idea what I can do?
Hi @JuergSmo, that’s interesting. I was facing the same issue yesterday late in the night after upgrading. I removed the thing and added it again after a restart of OH and then the issue was resolved. Weirdly the JSON configuration looked the same afterwards… can you try this procedure as well?
Hi @MartinOpenhabFan,
I did some debugging now.
First of all I tried what you suggested, removing the thing and adding it again. This works fine. Then I monitored the log:
2023-12-26 07:39:02.880 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing ‘mybmw:conv:3e4b4eac18:’ changed from UNINITIALIZED (HANDLER_MISSING_ERROR): Handler factory not found to UNINITIALIZED (NOT_YET_READY)
2023-12-26 07:39:02.892 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing ‘mybmw:account:3e4b4eac18’ changed from UNINITIALIZED (HANDLER_MISSING_ERROR): Handler factory not found to UNINITIALIZED (NOT_YET_READY)
2023-12-26 07:39:05.420 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing ‘mybmw:conv:3e4b4eac18:’ changed from UNINITIALIZED (NOT_YET_READY) to UNINITIALIZED (BRIDGE_UNINITIALIZED)
2023-12-26 07:39:05.474 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing ‘mybmw:account:3e4b4eac18’ changed from UNINITIALIZED (NOT_YET_READY) to INITIALIZING
2023-12-26 07:39:05.494 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing ‘mybmw:account:3e4b4eac18’ changed from INITIALIZING to UNKNOWN
2023-12-26 07:39:05.519 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing ‘mybmw:conv:3e4b4eac18:’ changed from UNINITIALIZED (BRIDGE_UNINITIALIZED) to INITIALIZING
2023-12-26 07:39:05.526 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing ‘mybmw:conv:3e4b4eac18:’ changed from INITIALIZING to UNKNOWN
2023-12-26 07:39:05.535 [INFO ] [openhab.event.ItemStateUpdatedEvent ] - Item ‘bmw_220d_xDrive_Fahrzeug_Ansicht_’ updated to Vehiclestatus
2023-12-26 07:39:05.536 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item ‘bmw_220d_xDrive_Fahrzeug_Ansicht_’ changed from NULL to Vehiclestatus
2023-12-26 07:39:06.196 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing ‘mybmw:conv:3e4b4eac18:’ changed from UNKNOWN to OFFLINE (COMMUNICATION_ERROR): Vehicle State Update failed
2023-12-26 07:39:07.528 [WARN ] [ernal.handler.backend.MyBMWHttpProxy] - error retrieving the base vehicles for brand bmw: null
2023-12-26 07:39:17.795 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing ‘mybmw:account:3e4b4eac18’ changed from UNKNOWN to ONLINE
But 2 minutes later:
2023-12-26 07:41:18.234 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing ‘mybmw:conv:3e4b4eac18:’ changed from OFFLINE (COMMUNICATION_ERROR): Vehicle State Update failed to UNKNOWN
I go back to the thing configuration in the UI and just select “Save” without changing anything. And it got back online:
2023-12-26 07:41:18.962 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing ‘mybmw:conv:3e4b4eac18:’ changed from UNKNOWN to ONLINE
But after about 70 minutes later it again got offline:
2023-12-26 08:51:28.688 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing ‘mybmw:conv:3e4b4eac18:’ changed from ONLINE to OFFLINE (COMMUNICATION_ERROR): Vehicle State Update failed
After this I enabled TRACE log, select “Save” in the UI and it got back online. But again after about 45 minutes it got offline:
2023-12-26 09:35:41.410 [TRACE] [ybmw.internal.handler.VehicleHandler] - VehicleHandler.getData
2023-12-26 09:35:41.521 [DEBUG] [ernal.handler.backend.MyBMWHttpProxy] - ###### Request URL - BEGIN ######
2023-12-26 09:35:41.522 [DEBUG] [ernal.handler.backend.MyBMWHttpProxy] - https://cocoapi.bmwgroup.com/eadrax-vcs/v4/vehicles/state
2023-12-26 09:35:41.523 [DEBUG] [ernal.handler.backend.MyBMWHttpProxy] - ###### Request Body - BEGIN ######
2023-12-26 09:35:41.524 [DEBUG] [ernal.handler.backend.MyBMWHttpProxy] -
2023-12-26 09:35:41.525 [DEBUG] [ernal.handler.backend.MyBMWHttpProxy] - ###### Response Data - BEGIN ######
2023-12-26 09:35:41.526 [DEBUG] [ernal.handler.backend.MyBMWHttpProxy] - { “statusCode”: 403, “message”: “Out of call volume quota. Quota will be replenished in 00:24:19.” }
2023-12-26 09:35:41.527 [DEBUG] [ernal.handler.backend.MyBMWHttpProxy] - ###### Response Data - END ######
2023-12-26 09:35:41.527 [DEBUG] [ybmw.internal.handler.VehicleHandler] - NetworkException [url=https://cocoapi.bmwgroup.com/eadrax-vcs/v4/vehicles/state, status=403, reason={ “statusCode”: 403, “message”: “Out of call volume quota. Quota will be replenished in 00:24:19.” }, body=]
It seems to me that BMW change the quota. I now increased the request interval to 20 minutes in the thing configuration and hope that this will work for me.
If you have a better idea or I can test anything else you are welcome.
It is still working for me without any issues.
Hi @JuergSmo ,
Thanks for the feedback and for testing. I checked my debug logs and I can see each hour some entries regarding the quota are shown. I have two cars which I’m fetching data each 5 mins. I don’t know exactly what’s the allowed quota, but it looks like setting the default interval to 15-20mins should be better… maybe I’ll do that for the next release. I’ll try now with 15mins…
Dear Martin,
Appreciate help … I have set the interval now to 30min so most of the time my 2 cars are online … but when I try to use start climate command … 3 out of 4 times it produces an Error …
Item ‘iX3RemoteState’ changed from climate-now-start initiated to climate-now-start error 403
sometimes it will work…
2024-01-04 12:45:10.034 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'iX3RemoteState' changed from climate-now-start initiated to climate-now-start error 403
==> /var/log/openhab/openhab.log <==
2024-01-04 12:45:40.715 [WARN ] [al.handler.auth.MyBMWTokenController] - Authorization Exception: URL: https://customer.bmwgroup.com/gcdm/oauth/token, Error: 400, Message: {"error": "invalid_request", "error_description": "The request is missing a required parameter, includes an unsupported parameter value (other than grant type), repeats a parameter, includes multiple credentials, utilizes more than one mechanism for authenticating the client, or is otherwise malformed"}
2024-01-04 12:45:40.715 [WARN ] [al.handler.auth.MyBMWTokenController] - Authorization failed!
==> /var/log/openhab/events.log <==
2024-01-04 12:45:40.775 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'mybmw:conv:4711:BMWX3' changed from ONLINE to OFFLINE (COMMUNICATION_ERROR): Vehicle State Update failed
2024-01-04 12:45:45.601 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'mybmw:bev:4711:BMWiX3' changed from ONLINE to OFFLINE (COMMUNICATION_ERROR): Vehicle State Update failed
Let me know if I shall track some binding detailed log when I try to use the command …
openHAB 4.1.0 - Release Build
https://cocoapi.bmwgroup.com/eadrax-vrccs/v3/presentation/remote-commands/eventStatus?eventId=c8d
{ "statusCode": 403, "message": "Out of call volume quota. Quota will be replenished in 00:08:20." }
I assume it is related to the out of Quota issue also for commands
Would there be any chance for a manual poll e.g. I would like to have fresh data when I plug in the charging cable … then I could set the refresh to e.g. even 1h
Hi @christoph_kowatschik , thanks for the information. I tried to trigger a command and get the same issue. The problem is that the command is triggered, then an ID is returned and the add-on then checks in a loop if the command was executed successfully. And this check fails here. For me it is now failing at the first time when I fire the command 
I just found a discussion at HA (don’t blame me for Googling ): https://github.com/home-assistant/core/issues/83128 they have the same issue and some recommendations how to reduce the severity of this issue.
What we could do is to implement a channel to trigger the sync manually. This would not prevent to reach the limit, but then we could create a rule to sync only on demand…
1 Like
Thank you Martin,
I have changed my refresh to 120 min … now it seems I can execute at least one command …
When I try another command it will already run into OUt of call quota within the one hour …
Currently it looks like one command per hour max 
I will continue to test and report
It looks like the Quota will reset every full hour … anyhow sometimes still commands get executed but couldnt find any logic / pattern … and stupid enough even the command get executed in reality (flash lights) the event Status will be “Out of call volume quota”
10:53 Quota will be replenished in 6 Min
11:32 Command 1 : "Executed"
11:33 Command 2 : "Executed"
11:34 Command 3 : "Out of Quota .. replenished in 26 min" / not executed
11:36 Command 4 : "Executed" ... strange enough time of replenishment not expired
11:38 Command 5 : "Executed" ... strange enough time of replenishment not expired
11:39 Command 6 : "Out of Quota .. replenished in 20 min" / not executed
11:40 Command 7 : "Out of Quota .. replenished in 19 min" / not executed
11:41 Command 8 : "Out of Quota .. replenished in 18 min" / not executed
11:48 Command 9 : "Out of Quota .. replenished in 11 min" / strange enough still executed
11:51 Command 10: "Executed" who knows why
11:55 Command 11 : "Out of Quota .. replenished in 11 min / strange enough still executed
1 Like