Preview and Beta: Amazon Echo Control

Great. There are still more than 70 null warnings to be addressed, after taht is done, I’ll upload a new jar, so we can get it merged soon. Would be great if you could test again.

3 Likes

Looks very good!!! The discovered devices start off as unknown but then when added they become online and the channels for the devices appear correctly- this may well have been how it always was
You are truly a legend @J-N-K

I have left everything alone and not touched it since first installing the r3 .jar file and everything is still working nicely! There are a few bundleFile errors in the log but you may already know about these:

2020-06-23 07:29:01.530 [ERROR] [nal.common.AbstractInvocationHandler] - An error occurred while calling method 'ThingHandler.handleCommand()' on 'org.openhab.binding.amazonechocontrol.internal.handler.EchoHandler@3fe7b6de': POST url 'https://alexa.amazon.com/api/behaviors/preview' failed: Too Many Requests
org.openhab.binding.amazonechocontrol.internal.HttpException: POST url 'https://alexa.amazon.com/api/behaviors/preview' failed: Too Many Requests
	at org.openhab.binding.amazonechocontrol.internal.Connection.makeRequest(Connection.java:647) ~[?:?]
	at org.openhab.binding.amazonechocontrol.internal.Connection.executeSequenceNode(Connection.java:1316) ~[?:?]
	at org.openhab.binding.amazonechocontrol.internal.Connection.executeSequenceCommand(Connection.java:1301) ~[?:?]
	at org.openhab.binding.amazonechocontrol.internal.Connection.executeSequenceCommandWithVolume(Connection.java:1291) ~[?:?]
	at org.openhab.binding.amazonechocontrol.internal.Connection.textToSpeech(Connection.java:1269) ~[?:?]
	at org.openhab.binding.amazonechocontrol.internal.handler.EchoHandler.startTextToSpeech(EchoHandler.java:724) ~[?:?]
	at org.openhab.binding.amazonechocontrol.internal.handler.EchoHandler.handleCommand(EchoHandler.java:577) ~[?:?]
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:1.8.0_252]
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[?:1.8.0_252]
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:1.8.0_252]
	at java.lang.reflect.Method.invoke(Method.java:498) ~[?:1.8.0_252]
	at org.eclipse.smarthome.core.internal.common.AbstractInvocationHandler.invokeDirect(AbstractInvocationHandler.java:152) [bundleFile:?]
	at org.eclipse.smarthome.core.internal.common.InvocationHandlerSync.invoke(InvocationHandlerSync.java:59) [bundleFile:?]
	at com.sun.proxy.$Proxy654.handleCommand(Unknown Source) [?:?]
	at org.eclipse.smarthome.core.thing.internal.profiles.ProfileCallbackImpl.handleCommand(ProfileCallbackImpl.java:74) [bundleFile:?]
	at org.eclipse.smarthome.core.thing.internal.profiles.SystemDefaultProfile.onCommandFromItem(SystemDefaultProfile.java:48) [bundleFile:?]
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:1.8.0_252]
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[?:1.8.0_252]
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:1.8.0_252]
	at java.lang.reflect.Method.invoke(Method.java:498) ~[?:1.8.0_252]
	at org.eclipse.smarthome.core.internal.common.AbstractInvocationHandler.invokeDirect(AbstractInvocationHandler.java:152) [bundleFile:?]
	at org.eclipse.smarthome.core.internal.common.Invocation.call(Invocation.java:52) [bundleFile:?]
	at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:1.8.0_252]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:1.8.0_252]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:1.8.0_252]
	at java.lang.Thread.run(Thread.java:748) [?:1.8.0_252]
2020-06-23 08:18:18.982 [ERROR] [handler.BroadlinkRemoteModel2Handler] - rm2:34-ea-34-43-35-97[^]: Could not get status: {}
java.net.ProtocolException: Incoming packet from device is null.
	at org.openhab.binding.broadlink.internal.BroadlinkProtocol.decodePacket(BroadlinkProtocol.java:191) ~[bundleFile:?]
	at org.openhab.binding.broadlink.handler.BroadlinkRemoteModel2Handler.getStatusFromDevice(BroadlinkRemoteModel2Handler.java:37) [bundleFile:?]
	at org.openhab.binding.broadlink.handler.BroadlinkBaseThingHandler.updateItemStatus(BroadlinkBaseThingHandler.java:202) [bundleFile:?]
	at org.openhab.binding.broadlink.handler.BroadlinkBaseThingHandler$1.run(BroadlinkBaseThingHandler.java:75) [bundleFile:?]
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [?:1.8.0_252]
	at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308) [?:1.8.0_252]
	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180) [?:1.8.0_252]
	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294) [?:1.8.0_252]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:1.8.0_252]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:1.8.0_252]
	at java.lang.Thread.run(Thread.java:748) [?:1.8.0_252]
2020-06-23 08:18:18.983 [ERROR] [handler.BroadlinkRemoteModel2Handler] - rm2:34-ea-34-43-35-97[^]: Problem getting status. Marking as offline ...
2020-06-23 08:18:18.983 [ERROR] [handler.BroadlinkRemoteModel2Handler] - rm2:34-ea-34-43-35-97[^]: updateItemStatus: Online -> Offline
2020-06-23 08:18:52.002 [WARN ] [nal.discovery.DeviceRediscoveryAgent] - DeviceRediscoveryAgent - Beginning Broadlink device scan for missing BroadlinkDeviceConfiguration [ipAddress=192.168.1.239 (static: false), port=80, mac=**redacted**, pollingInterval=30, mapFilename=broadlink.map, authorizationKey=**redacted**]
2020-06-23 08:18:52.005 [WARN ] [internal.discovery.DiscoveryProtocol] - Beginning async Broadlink device scan; will wait 5000ms for responses
2020-06-23 08:18:52.018 [WARN ] [internal.discovery.DiscoveryProtocol] - Broadlink device scan waiting for 5000 ms to complete ...
2020-06-23 08:18:52.041 [INFO ] [nal.discovery.DeviceRediscoveryAgent] - We have a match for target MAC 34:ea:34:43:35:97 at 192.168.1.239 - reassociate!
2020-06-23 08:18:52.042 [INFO ] [handler.BroadlinkRemoteModel2Handler] - rm2:**redacted**[v]: Rediscovered this device at IP 192.168.1.239
2020-06-23 08:18:57.021 [WARN ] [internal.discovery.DiscoveryProtocol] - Device scan: wait complete ...
2020-06-23 08:18:57.022 [WARN ] [internal.discovery.DiscoveryProtocol] - Ended Broadlink device scan...
2020-06-23 08:18:57.023 [INFO ] [link.internal.socket.BroadlinkSocket] - Socket closed
2020-06-23 08:18:57.024 [INFO ] [link.internal.socket.BroadlinkSocket] - Receiver thread ended
2020-06-23 09:13:17.981 [ERROR] [handler.BroadlinkRemoteModel2Handler] - rm2:**redacted**[^]: Could not get status: {}
java.net.ProtocolException: Incoming packet from device is null.
	at org.openhab.binding.broadlink.internal.BroadlinkProtocol.decodePacket(BroadlinkProtocol.java:191) ~[bundleFile:?]
	at org.openhab.binding.broadlink.handler.BroadlinkRemoteModel2Handler.getStatusFromDevice(BroadlinkRemoteModel2Handler.java:37) [bundleFile:?]
	at org.openhab.binding.broadlink.handler.BroadlinkBaseThingHandler.updateItemStatus(BroadlinkBaseThingHandler.java:202) [bundleFile:?]
	at org.openhab.binding.broadlink.handler.BroadlinkBaseThingHandler$1.run(BroadlinkBaseThingHandler.java:75) [bundleFile:?]
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [?:1.8.0_252]
	at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308) [?:1.8.0_252]
	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180) [?:1.8.0_252]
	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294) [?:1.8.0_252]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:1.8.0_252]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:1.8.0_252]
	at java.lang.Thread.run(Thread.java:748) [?:1.8.0_252]
2020-06-23 09:13:17.985 [ERROR] [handler.BroadlinkRemoteModel2Handler] - rm2:34-ea-34-43-35-97[^]: Problem getting status. Marking as offline ...
2020-06-23 09:13:17.986 [ERROR] [handler.BroadlinkRemoteModel2Handler] - rm2:34-ea-34-43-35-97[^]: updateItemStatus: Online -> Offline
2020-06-23 11:43:07.184 [WARN ] [trol.internal.handler.AccountHandler] - handling of websockets fails
org.openhab.binding.amazonechocontrol.internal.HttpException: GET url 'https://alexa.amazon.com/api/activities?startTime=1592930587026&size=10&offset=1' failed: Bad Request
	at org.openhab.binding.amazonechocontrol.internal.Connection.makeRequest(Connection.java:647) ~[bundleFile:?]
	at org.openhab.binding.amazonechocontrol.internal.Connection.makeRequestAndReturnString(Connection.java:503) ~[bundleFile:?]
	at org.openhab.binding.amazonechocontrol.internal.Connection.makeRequestAndReturnString(Connection.java:498) ~[bundleFile:?]
	at org.openhab.binding.amazonechocontrol.internal.Connection.getActivities(Connection.java:1010) ~[bundleFile:?]
	at org.openhab.binding.amazonechocontrol.internal.handler.AccountHandler.handlePushActivity(AccountHandler.java:834) ~[bundleFile:?]
	at org.openhab.binding.amazonechocontrol.internal.handler.AccountHandler.handleWebsocketCommand(AccountHandler.java:779) ~[bundleFile:?]
	at org.openhab.binding.amazonechocontrol.internal.handler.AccountHandler.webSocketCommandReceived(AccountHandler.java:767) [bundleFile:?]
	at org.openhab.binding.amazonechocontrol.internal.WebSocketConnection$AmazonEchoControlWebSocket.onWebSocketBinary(WebSocketConnection.java:417) [bundleFile:?]
	at sun.reflect.GeneratedMethodAccessor109.invoke(Unknown Source) ~[?:?]
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:1.8.0_252]
	at java.lang.reflect.Method.invoke(Method.java:498) ~[?:1.8.0_252]
	at org.eclipse.jetty.websocket.common.events.annotated.CallableMethod.call(CallableMethod.java:70) [bundleFile:9.4.20.v20190813]
	at org.eclipse.jetty.websocket.common.events.annotated.OptionalSessionCallableMethod.call(OptionalSessionCallableMethod.java:72) [bundleFile:9.4.20.v20190813]
	at org.eclipse.jetty.websocket.common.events.JettyAnnotatedEventDriver.onBinaryMessage(JettyAnnotatedEventDriver.java:133) [bundleFile:9.4.20.v20190813]
	at org.eclipse.jetty.websocket.common.message.SimpleBinaryMessage.messageComplete(SimpleBinaryMessage.java:68) [bundleFile:9.4.20.v20190813]
	at org.eclipse.jetty.websocket.common.events.AbstractEventDriver.appendMessage(AbstractEventDriver.java:65) [bundleFile:9.4.20.v20190813]
	at org.eclipse.jetty.websocket.common.events.JettyAnnotatedEventDriver.onBinaryFrame(JettyAnnotatedEventDriver.java:125) [bundleFile:9.4.20.v20190813]
	at org.eclipse.jetty.websocket.common.events.AbstractEventDriver.incomingFrame(AbstractEventDriver.java:145) [bundleFile:9.4.20.v20190813]
	at org.eclipse.jetty.websocket.common.WebSocketSession.incomingFrame(WebSocketSession.java:321) [bundleFile:9.4.20.v20190813]
	at org.eclipse.jetty.websocket.common.extensions.ExtensionStack.incomingFrame(ExtensionStack.java:202) [bundleFile:9.4.20.v20190813]
	at org.eclipse.jetty.websocket.common.Parser.notifyFrame(Parser.java:226) [bundleFile:9.4.20.v20190813]
	at org.eclipse.jetty.websocket.common.Parser.parseSingleFrame(Parser.java:262) [bundleFile:9.4.20.v20190813]
	at org.eclipse.jetty.websocket.common.io.AbstractWebSocketConnection.readParse(AbstractWebSocketConnection.java:582) [bundleFile:9.4.20.v20190813]
	at org.eclipse.jetty.websocket.common.io.AbstractWebSocketConnection.onFillable(AbstractWebSocketConnection.java:441) [bundleFile:9.4.20.v20190813]
	at org.eclipse.jetty.websocket.common.io.AbstractWebSocketConnection.onFillable(AbstractWebSocketConnection.java:428) [bundleFile:9.4.20.v20190813]
	at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:311) [bundleFile:9.4.20.v20190813]
	at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103) [bundleFile:9.4.20.v20190813]
	at org.eclipse.jetty.io.ssl.SslConnection$DecryptedEndPoint.onFillable(SslConnection.java:426) [bundleFile:9.4.20.v20190813]
	at org.eclipse.jetty.io.ssl.SslConnection.onFillable(SslConnection.java:320) [bundleFile:9.4.20.v20190813]
	at org.eclipse.jetty.io.ssl.SslConnection$2.succeeded(SslConnection.java:158) [bundleFile:9.4.20.v20190813]
	at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103) [bundleFile:9.4.20.v20190813]
	at org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:117) [bundleFile:9.4.20.v20190813]
	at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:336) [bundleFile:9.4.20.v20190813]
	at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:313) [bundleFile:9.4.20.v20190813]
	at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:171) [bundleFile:9.4.20.v20190813]
	at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:129) [bundleFile:9.4.20.v20190813]
	at org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:367) [bundleFile:9.4.20.v20190813]
	at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:782) [bundleFile:9.4.20.v20190813]
	at org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.run(QueuedThreadPool.java:918) [bundleFile:9.4.20.v20190813]
	at java.lang.Thread.run(Thread.java:748) [?:1.8.0_252]

Yes, but that cannot be fixed easily. Or at least it is a breaking change. @Trinitus01 has some insight on that and after these changes here are merged, we‘ll work on that.

2 Likes

I have prepared https://janessa.me/esh/org.openhab.binding.amazonechocontrol-2.5.6-f4.jar, IMO this has code issues fixed and is ready for review.

4 Likes

what is f4 addressing?

Several issues that could result in exceptions (probably not as catastrophic as the OOM we experienced earlier). In most cases These are related to wrong or corrupted responses from the server that could result in null-objects.

1 Like

@J-N-K YOU ARE AWESOME! Thank you very much!!

1 Like

f4 working fine for me!

1 Like

I’ve been using org.openhab.binding.amazonechocontrol-2.5.6-SNAPSHOT.jar with good success. But I can’t get amazonechocontrol-2.5.6-f4.jar to work.

Some info:
1.I’m running openHAB 2.4.0 (build #1412) on a RaspberryPi. It was using the amazonechocontrol_2.5.0.Beta_07_Preview_1, but recently updated to amazonechocontrol-2.5.6-SNAPSHOT.

  1. To install the F4 binding I used the instructions posted here to : Web Socket Error on AmazonEchoControl binding every 65 seconds

  2. The amazonechocontrol web page is not populated with devices.

  3. Although Gson 2.8.5 library is installed, the new binding seems to be complaining that he library is unresolved. Here is the log:
    2020-06-24 14:20:21.340 [WARN ] [org.apache.felix.fileinstall ] - Error while starting bundle: file:/usr/share/openhab2/addons/org.openhab.binding.amazonechocontrol.jar
    org.osgi.framework.BundleException: Could not resolve module: org.openhab.binding.amazonechocontrol [137]
    Unresolved requirement: Import-Package: com.google.gson; version="[2.8.0,3.0.0)"
    at org.eclipse.osgi.container.Module.start(Module.java:444) ~[?:?]
    at org.eclipse.osgi.internal.framework.EquinoxBundle.start(EquinoxBundle.java:383) ~[?:?]
    at org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundle(DirectoryWatcher.java:1260) [10:org.apache.felix.fileinstall:3.6.4]
    at org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundles(DirectoryWatcher.java:1233) [10:org.apache.felix.fileinstall:3.6.4]
    at org.apache.felix.fileinstall.internal.DirectoryWatcher.startAllBundles(DirectoryWatcher.java:1221) [10:org.apache.felix.fileinstall:3.6.4]
    at org.apache.felix.fileinstall.internal.DirectoryWatcher.doProcess(DirectoryWatcher.java:515) [10:org.apache.felix.fileinstall:3.6.4]
    at org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:365) [10:org.apache.felix.fileinstall:3.6.4]
    at org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:316) [10:org.apache.felix.fileinstall:3.6.4]

  4. Before the F4 installation I had checked the Gson (list | grep -i gson) and it reported this:
    21 x Active x 80 x 2.7.0.v20170129-0911 x Gson: Google Json Library for Java
    234 x Resolved x 80 x 2.8.5 x Gson

  5. Reverting back to amazonechocontrol-2.5.6-SNAPSHOT required a full system restore from an archive. That is to say, reinstalling the previous working jar did not go well (Openhab did not run and no log file was generated).

  • Thomas

Sorry, I can’t and will not provide support for OH 2.4. Please update to 2.5 and check if it works there. Mixing bundle versions often results in problems.

Understood. Updating to OH2.5 will have to wait until I have more time to deal with any issues that may arise.

  • Thomas
2 Likes

Im not sure how to proceed with this error now:
[ERROR] [rnal.common.AbstractInvocationHandler] - An error occurred while calling method ‘ThingHandler.handleCommand()’ on ‘org.openhab.binding.amazonechocontrol.internal.handler.EchoHandler@c2a038’: POST url ‘https://alexa.amazon.de/api/behaviors/preview’ failed: Too Many Requests

How can i fix this. There are not too many requests but it still triggers me. Will this log be fixed or how can i disable these messages. i coud not solve it with:
log:set OFF control.internal.handler.AccountHandler

Thanks in advance!

this is a know issue being worked on and I think otherwise harmless

1 Like

Hi @michi,

since a few days, the LastVoiceCommand-Channel is not triggered anymore when talking to the devices. Are there changes in the api from amazon or other changes?

Can you confirm this?

Thanks!
Ralph

I wouldn’t call it harmless because on my end it leads to commands fizzle and fail, e.g.:

EchoPlus_Routine.sendCommand("mach sauber") doesn’t trigger the appropriate routine, all i get is

2020-07-02 19:17:34.086 [ERROR] [nal.common.AbstractInvocationHandler] - An error occurred while calling method 'ThingHandler.handleCommand()' on 'org.openhab.binding.amazonechocontrol.internal.handler.EchoHandler@1884e3c': GET url 'https://alexa.amazon.de/api/behaviors/automations?limit=2000' failed: Too Many Requests

org.openhab.binding.amazonechocontrol.internal.HttpException: GET url 'https://alexa.amazon.de/api/behaviors/automations?limit=2000' failed: Too Many Requests

at org.openhab.binding.amazonechocontrol.internal.Connection.makeRequest([Connection.java:649](http://connection.java:649/)) ~[?:?]

at org.openhab.binding.amazonechocontrol.internal.Connection.makeRequestAndReturnString([Connection.java:505](http://connection.java:505/)) ~[?:?]

at org.openhab.binding.amazonechocontrol.internal.Connection.makeRequestAndReturnString([Connection.java:500](http://connection.java:500/)) ~[?:?]

at org.openhab.binding.amazonechocontrol.internal.Connection.getRoutines([Connection.java:1458](http://connection.java:1458/)) ~[?:?]

at org.openhab.binding.amazonechocontrol.internal.Connection.startRoutine([Connection.java:1387](http://connection.java:1387/)) ~[?:?]

at org.openhab.binding.amazonechocontrol.internal.handler.EchoHandler.handleCommand([EchoHandler.java:644](http://echohandler.java:644/)) ~[?:?]

at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:1.8.0_252]

at sun.reflect.NativeMethodAccessorImpl.invoke([NativeMethodAccessorImpl.java:62](http://nativemethodaccessorimpl.java:62/)) ~[?:1.8.0_252]

at sun.reflect.DelegatingMethodAccessorImpl.invoke([DelegatingMethodAccessorImpl.java:43](http://delegatingmethodaccessorimpl.java:43/)) ~[?:1.8.0_252]

at java.lang.reflect.Method.invoke([Method.java:498](http://method.java:498/)) ~[?:1.8.0_252]

at org.eclipse.smarthome.core.internal.common.AbstractInvocationHandler.invokeDirect([AbstractInvocationHandler.java:152](http://abstractinvocationhandler.java:152/)) [bundleFile:?]

at org.eclipse.smarthome.core.internal.common.InvocationHandlerSync.invoke([InvocationHandlerSync.java:59](http://invocationhandlersync.java:59/)) [bundleFile:?]

at com.sun.proxy.$Proxy417.handleCommand(Unknown Source) [?:?]

at org.eclipse.smarthome.core.thing.internal.profiles.ProfileCallbackImpl.handleCommand([ProfileCallbackImpl.java:74](http://profilecallbackimpl.java:74/)) [bundleFile:?]

at org.eclipse.smarthome.core.thing.internal.profiles.SystemDefaultProfile.onCommandFromItem([SystemDefaultProfile.java:48](http://systemdefaultprofile.java:48/)) [bundleFile:?]

at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:1.8.0_252]

at sun.reflect.NativeMethodAccessorImpl.invoke([NativeMethodAccessorImpl.java:62](http://nativemethodaccessorimpl.java:62/)) ~[?:1.8.0_252]

at sun.reflect.DelegatingMethodAccessorImpl.invoke([DelegatingMethodAccessorImpl.java:43](http://delegatingmethodaccessorimpl.java:43/)) ~[?:1.8.0_252]

at java.lang.reflect.Method.invoke([Method.java:498](http://method.java:498/)) ~[?:1.8.0_252]

at org.eclipse.smarthome.core.internal.common.AbstractInvocationHandler.invokeDirect([AbstractInvocationHandler.java:152](http://abstractinvocationhandler.java:152/)) [bundleFile:?]

at org.eclipse.smarthome.core.internal.common.Invocation.call([Invocation.java:52](http://invocation.java:52/)) [bundleFile:?]

at [java.util.concurrent.FutureTask.run](http://java.util.concurrent.futuretask.run/)([FutureTask.java:266](http://futuretask.java:266/)) [?:1.8.0_252]

at java.util.concurrent.ThreadPoolExecutor.runWorker([ThreadPoolExecutor.java:1149](http://threadpoolexecutor.java:1149/)) [?:1.8.0_252]

at java.util.concurrent.ThreadPoolExecutor$[Worker.run](http://worker.run/)([ThreadPoolExecutor.java:624](http://threadpoolexecutor.java:624/)) [?:1.8.0_252]

at [java.lang.Thread.run](http://java.lang.thread.run/)([Thread.java:748](http://thread.java:748/)) [?:1.8.0_252]

i used to be able to solve it on the RC version of the binding by using a timer since there’s a tts just before the command, but this workaround doesn’t cut it now for some reason.

great binding otherwise, finally getting the access to echo hub-connected devices

No, you are right, the command fails, and that is certainly not harmless. What I meant to say really is that it does not cause a system failure like the oom issue. As stated, the developers are aware of the issue and working on the best solution. I also tried a timer to delay the calls but as you say, it didn’t help

what i found out with my workaround of using three nested timers is that the first command almost always fails - the second and third almost always succeed.

i.e. previeously i had the timer set up for 10 seconds after the tts command, and it worked fine on the RC binding version. after moving to the beta, i saw the comand fail and increased the timer to 30s - which did not allevieate the issue
i then moved on to repeating the command three times with 10s intervalls each - and have a feeling the second and third always go through (i can hear the RVC beep a confirmation sound) and the first almost always fails

so it’s not just about command-to-command “cooldown” as i had first thought

1 Like

Please stay patient, a version to fix the too many requests issue is in testing state.

To explain the issue, not only a single command produces a request. After a command sends a request, the binding can receive a websocket call which again can produce a request. The binding also sends requests from time to time. So a timer between comands is only a “looks like a fix”. And for cammands to multible devices a timer would produce a echo by echo effect. Also there is an overlap for different commands to the same echo. Dont waste your time to try to fix it with workarounds in a rule.

Br

2 Likes

Finally all the changes (except those from @Trinitus01 for the „Too many requests“ issue) have been merged and will be available in openHAB‘s next snapshot and in 2.5.7 (after it has been released). Thanks too everyone who contributed (with code or testing, which is a valuable help).

I‘ll work together with @Trinitus01 to get his fixes incorporated as soon as possible. Stay tuned!

11 Likes