Preview and Beta: Amazon Echo Control

Sorry, bad description…

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.

Do you use the latest smarthome additions?

I only downloaded the latest jar from here.

Where do I find those additions please?

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?

Ah, thanks, I see.

No, then I don’t use them. Is it for Amazon SmartHome devices?

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.

i had the same issue. After i remove the Amazon Account Thing and made a new one i am able to login again.

2 Likes

Hi,

thank you for the log information.
Routines are not protected against “too many requests”.
We will take a look into.

br

1 Like

Does this “limit=2000” mean that there are too many users starting routines at the same time?

I noticed that it seems to work when I change my cron times to more “unusual” times (06:09:30 a.m. instead of 06:10:00 a.m. for example).

No,

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)

1 Like

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.

That worked for me. Thanks

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.

1 Like

No, I’m using Java 11 (Zulu).

1 Like

Hi,

could you please test the following jar.

Link removed.

Test cases are:

  • Is there still a delay on lastVoiceCommand
  • Is there still a delay on tts or act
  • Is there any too many request error in log
  • Does group tts or group act work
  • 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)

Big thanks for testing!

br

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:

I edit rule-file.


Then I say something:

than no response…

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)?

Br

As I wrote I installed the 2.5.6 SNAPSHOT again after logging in with 2.5.7 and everything is working fine.

So I am wondering if all the changes are really necessary.
Wouldn’t it be enough to change the login process only?