I have one TTS command which is triggered by a rule through two switches (if switch A and switch B are ON at the same time, let Alexa say something), this works immediately.
Then I have a second TTS command which is triggered by a rule through LastVoiceCommand (if the LastVoiceCommand-String contains “welche schicht” say something). This works, but it needs quite long until the LastVoiceCommand item is updated and even longer until Alexa answers.
They are included in that jar, the question is, if you use them.
@Trinitus01 and me don‘t see the delays but we both don‘t use the smarthome additions (available since 2.5.6 or in the previously shared „beta“ from this thread).
If you don‘t have things of type smartHomeDevice or smartHomeDeviceGroup, you don‘t use them. Of you have them, you use the smarthome additions.
Dear Colleagues, after upgrade to 2.5.7 I’m not able to send TTS command, but I can connect to device and change volumes and others. May you please help me on it?
Next problem…
I am using the binding to start routines. The log says they were started, but nothing happens. I am getting the following error.
(It worked once when I tested it yesterday)
2020-07-17 06:35:00.136 [ome.event.ItemCommandEvent] - Item 'Echo_Wohnzimmer_StartRoutine' received command Aufwachfernsehen
2020-07-17 06:35:00.139 [nt.ItemStatePredictedEvent] - Echo_Wohnzimmer_StartRoutine predicted to become Aufwachfernsehen
2020-07-17 06:35:00.163 [vent.ItemStateChangedEvent] - Echo_Wohnzimmer_StartRoutine changed from to Aufwachfernsehen
==> /var/log/openhab2/openhab.log <==
2020-07-17 06:35:05.829 [ERROR] [nal.common.AbstractInvocationHandler] - An error occurred while calling method 'ThingHandler.handleCommand()' on 'org.openhab.binding.amazonechocontrol.internal.handler.EchoHandler@2acf58': 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:675) ~[?:?]
at org.openhab.binding.amazonechocontrol.internal.Connection.makeRequestAndReturnString(Connection.java:531) ~[?:?]
at org.openhab.binding.amazonechocontrol.internal.Connection.makeRequestAndReturnString(Connection.java:526) ~[?:?]
at org.openhab.binding.amazonechocontrol.internal.Connection.getRoutines(Connection.java:1688) ~[?:?]
at org.openhab.binding.amazonechocontrol.internal.Connection.startRoutine(Connection.java:1622) ~[?:?]
at org.openhab.binding.amazonechocontrol.internal.handler.EchoHandler.handleCommand(EchoHandler.java:644) ~[?:?]
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.$Proxy470.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
Edit: Just changed the cron times and tried it again, now it worked…very strange.
the “limit” is an url-parameter. But too many requests doesn’t depend on this parameter or on any other user or the daytime. Amaz+n reject your request because of too many requests in a short period of time. (the amount of requests is not equal to the amount of sendCommand for example, there are much more hidden and parallel requests)
Edit: I think you can simply reproduce it by running sendCommand to a routine multiple times until the exception appears. (Routine is not protected agains the tmr-issue at the moment, only tts and act)
Many thanks for the explanation.
I am using the rules to start the routines since several months without problems, that’s why I was wondering what suddenly happened.
Could it be that this verison is not compatible with JAVA 11?
I’m using the following binding: org.openhab.binding.amazonechocontrol-2.5.7-SNAPSHOT.jar
When I switch to JAVA 11 (with openhabian-config), i’m getting the following errors:
2020-07-17 20:24:13.926 [WARN ] [mazonechocontrol.internal.Connection] - Request to url 'https://alexa.amazon.de/api/bootstrap' fails with unknown error
javax.net.ssl.SSLException: Unexpected error: java.security.InvalidAlgorithmParameterException: the trustAnchors parameter must be non-empty
at sun.security.ssl.Alert.createSSLException(Alert.java:133) ~[?:?]
at sun.security.ssl.TransportContext.fatal(TransportContext.java:326) ~[?:?]
at sun.security.ssl.TransportContext.fatal(TransportContext.java:269) ~[?:?]
at sun.security.ssl.TransportContext.fatal(TransportContext.java:264) ~[?:?]
at sun.security.ssl.SSLSocketImpl.handleException(SSLSocketImpl.java:1310) ~[?:?]
at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:403) ~[?:?]
at sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:567) ~[?:?]
at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:185) ~[?:?]
at sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1587) ~[?:?]
at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1515) ~[?:?]
at java.net.HttpURLConnection.getResponseCode(HttpURLConnection.java:527) ~[?:?]
at sun.net.www.protocol.https.HttpsURLConnectionImpl.getResponseCode(HttpsURLConnectionImpl.java:334) ~[?:?]
at org.openhab.binding.amazonechocontrol.internal.Connection.makeRequest(Connection.java:614) [bundleFile:?]
at org.openhab.binding.amazonechocontrol.internal.Connection.tryGetBootstrap(Connection.java:465) [bundleFile:?]
at org.openhab.binding.amazonechocontrol.internal.Connection.verifyLogin(Connection.java:882) [bundleFile:?]
at org.openhab.binding.amazonechocontrol.internal.Connection.tryRestoreLogin(Connection.java:357) [bundleFile:?]
at org.openhab.binding.amazonechocontrol.internal.handler.AccountHandler.checkLogin(AccountHandler.java:385) [bundleFile:?]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) [?:?]
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:1128) [?:?]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) [?:?]
at java.lang.Thread.run(Thread.java:834) [?:?]
Caused by: java.lang.RuntimeException: Unexpected error: java.security.InvalidAlgorithmParameterException: the trustAnchors parameter must be non-empty
at sun.security.validator.PKIXValidator.<init>(PKIXValidator.java:102) ~[?:?]
at sun.security.validator.Validator.getInstance(Validator.java:181) ~[?:?]
at sun.security.ssl.X509TrustManagerImpl.getValidator(X509TrustManagerImpl.java:300) ~[?:?]
at sun.security.ssl.X509TrustManagerImpl.checkTrustedInit(X509TrustManagerImpl.java:176) ~[?:?]
at sun.security.ssl.X509TrustManagerImpl.checkTrusted(X509TrustManagerImpl.java:189) ~[?:?]
at sun.security.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:129) ~[?:?]
at sun.security.ssl.CertificateMessage$T12CertificateConsumer.checkServerCerts(CertificateMessage.java:629) ~[?:?]
at sun.security.ssl.CertificateStatus$CertificateStatusConsumer.consume(CertificateStatus.java:295) ~[?:?]
at sun.security.ssl.SSLHandshake.consume(SSLHandshake.java:392) ~[?:?]
at sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:444) ~[?:?]
at sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:422) ~[?:?]
at sun.security.ssl.TransportContext.dispatch(TransportContext.java:183) ~[?:?]
at sun.security.ssl.SSLTransport.decode(SSLTransport.java:168) ~[?:?]
at sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1148) ~[?:?]
at sun.security.ssl.SSLSocketImpl.readHandshakeRecord(SSLSocketImpl.java:1057) ~[?:?]
at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:395) ~[?:?]
... 17 more
Caused by: java.security.InvalidAlgorithmParameterException: the trustAnchors parameter must be non-empty
at java.security.cert.PKIXParameters.setTrustAnchors(PKIXParameters.java:200) ~[?:?]
at java.security.cert.PKIXParameters.<init>(PKIXParameters.java:120) ~[?:?]
at java.security.cert.PKIXBuilderParameters.<init>(PKIXBuilderParameters.java:104) ~[?:?]
at sun.security.validator.PKIXValidator.<init>(PKIXValidator.java:99) ~[?:?]
at sun.security.validator.Validator.getInstance(Validator.java:181) ~[?:?]
at sun.security.ssl.X509TrustManagerImpl.getValidator(X509TrustManagerImpl.java:300) ~[?:?]
at sun.security.ssl.X509TrustManagerImpl.checkTrustedInit(X509TrustManagerImpl.java:176) ~[?:?]
at sun.security.ssl.X509TrustManagerImpl.checkTrusted(X509TrustManagerImpl.java:189) ~[?:?]
at sun.security.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:129) ~[?:?]
at sun.security.ssl.CertificateMessage$T12CertificateConsumer.checkServerCerts(CertificateMessage.java:629) ~[?:?]
at sun.security.ssl.CertificateStatus$CertificateStatusConsumer.consume(CertificateStatus.java:295) ~[?:?]
at sun.security.ssl.SSLHandshake.consume(SSLHandshake.java:392) ~[?:?]
at sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:444) ~[?:?]
at sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:422) ~[?:?]
at sun.security.ssl.TransportContext.dispatch(TransportContext.java:183) ~[?:?]
at sun.security.ssl.SSLTransport.decode(SSLTransport.java:168) ~[?:?]
at sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1148) ~[?:?]
at sun.security.ssl.SSLSocketImpl.readHandshakeRecord(SSLSocketImpl.java:1057) ~[?:?]
at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:395) ~[?:?]
... 17 more
When switching back to JAVA 8, the binding works without issues.
I don’t know if it is of any use for you.
I followed @richaardvark’s idea and changed the jar after login back to the latest 2.5.6- SNAPSHOT.
Today all my routines were running without the tmr error or any other errors or warnings and the LastVoiceCommand is working normal again, without any delays.
Does same tts outputs or act outputs in a short period of time work (example send tts with “blub” to device1, send tts with “blub” to device2 and send tts with “blub” to device 3)
Does different tts outputs or act outputs in a short period of time work (example send tts with “blub” and after it a tts with “blab” and a act with “blib”
Does ttsVolume work (example set ttsVolume one time to 50, set volume to 30, send tts, act, group tts or group act)
Hi. I tried that… and it worked the first couple of tests!
But while playing around, I had a significant delay like 30secs between saying something and the response of her saying something back using TTS. The log changed instantly, I was just “hearing” her response much later. It is replicable:
until 22:25:10 - nothing in the logs, but alexa starts with that chime and starts talking “ding dong”…
So I didn’t change the file… and asked her the same thing again, quick response. then I ask her again, quick response. Then I ask her again, 2min break before the response.
I know that behavior from the past, like a spam-blocker, because I ask her the same thing multiple times…Like there is a “only 5 TTS per minute or so”…
I have trace-logs enabled, no entry of “many”(requests).
Thank you very much to test the jar, it helps a lot to improve the binding.
I will take your rule and try to reproduce the “issue”. It will take some time for sure but i will report as soon as possible.
Edit: I fired 10 tts without any problem but not triggered via lastVoiceCommand. So it seems there is no limit per minute.
Edit: To reproduce it the best way i need to know if you set a ttsVolume or use the echo volume (never set the ttsVolume)?