Release Candidate and Support: Amazon Echo Control Binding

kleiner-irrer · December 17, 2020, 7:09pm

can somebody tell me where I can find ShowIDsInGUI ??
Under Configuration / Bindings I can not configure it

From the binding manual:

        // These are only view of the possible options. Enable ShowIDsInGUI in the binding configuration and look in drop-down-box of this channel in the Paper UI Control section
        Selection item=Echo_Living_Room_PlayAlarmSound mappings=[ ''='None', 'ECHO:system_alerts_soothing_01'='Adrift', 'ECHO:system_alerts_atonal_02'='Clangy']

elarge · December 18, 2020, 9:07pm

Hi there, I still have issues discovering new devices. WIth your tip of uninstalling the echo binding something good happened. Although for me it only works the first time after reinstalling the echo binding and restarting openhab. The second time I press discover in the alexa app i notice the following errors in the log. Any ideas what is wrong?
Second weird thing: Alexa finds a lot of hue devices with sometimes wrong names. This is funny because those devices have no alexa tags set.
I am a bit confused. At least I have some more devices now connected with alexa.

22:01:57.435 [ERROR] [jersey.server.ServerRuntime$Responder] - An I/O error has occurred while writing a response message entity to the container output stream.
org.glassfish.jersey.server.internal.process.MappableException: org.eclipse.jetty.io.EofException
at org.glassfish.jersey.server.internal.MappableExceptionWrapperInterceptor.aroundWriteTo(MappableExceptionWrapperInterceptor.java:92) ~[?:?]
at org.glassfish.jersey.message.internal.WriterInterceptorExecutor.proceed(WriterInterceptorExecutor.java:162) ~[bundleFile:?]
at org.glassfish.jersey.message.internal.MessageBodyFactory.writeTo(MessageBodyFactory.java:1130) ~[bundleFile:?]
at org.glassfish.jersey.server.ServerRuntime$Responder.writeResponse(ServerRuntime.java:711) [bundleFile:?]
at org.glassfish.jersey.server.ServerRuntime$Responder.processResponse(ServerRuntime.java:444) [bundleFile:?]
at org.glassfish.jersey.server.ServerRuntime$Responder.process(ServerRuntime.java:434) [bundleFile:?]
at org.glassfish.jersey.server.ServerRuntime$2.run(ServerRuntime.java:329) [bundleFile:?]
at org.glassfish.jersey.internal.Errors$1.call(Errors.java:271) [bundleFile:?]
at org.glassfish.jersey.internal.Errors$1.call(Errors.java:267) [bundleFile:?]
at org.glassfish.jersey.internal.Errors.process(Errors.java:315) [bundleFile:?]
at org.glassfish.jersey.internal.Errors.process(Errors.java:297) [bundleFile:?]
at org.glassfish.jersey.internal.Errors.process(Errors.java:267) [bundleFile:?]
at org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:317) [bundleFile:?]
at org.glassfish.jersey.server.ServerRuntime.process(ServerRuntime.java:305) [bundleFile:?]
at org.glassfish.jersey.server.ApplicationHandler.handle(ApplicationHandler.java:1154) [bundleFile:?]
at org.glassfish.jersey.servlet.WebComponent.serviceImpl(WebComponent.java:473) [bundleFile:?]
at org.glassfish.jersey.servlet.WebComponent.service(WebComponent.java:427) [bundleFile:?]
at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:388) [bundleFile:?]
at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:341) [bundleFile:?]
at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:228) [bundleFile:?]
at com.eclipsesource.jaxrs.publisher.internal.ServletContainerBridge.service(ServletContainerBridge.java:76) [bundleFile:?]
at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:852) [bundleFile:9.4.20.v20190813]
at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:544) [bundleFile:9.4.20.v20190813]
at org.ops4j.pax.web.service.jetty.internal.HttpServiceServletHandler.doHandle(HttpServiceServletHandler.java:71) [bundleFile:?]
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143) [bundleFile:9.4.20.v20190813]
at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:536) [bundleFile:9.4.20.v20190813]
at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127) [bundleFile:9.4.20.v20190813]
at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:235) [bundleFile:9.4.20.v20190813]
at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1581) [bundleFile:9.4.20.v20190813]
at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:233) [bundleFile:9.4.20.v20190813]
at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1307) [bundleFile:9.4.20.v20190813]
at org.ops4j.pax.web.service.jetty.internal.HttpServiceContext.doHandle(HttpServiceContext.java:293) [bundleFile:?]
at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:188) [bundleFile:9.4.20.v20190813]
at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:482) [bundleFile:9.4.20.v20190813]
at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1549) [bundleFile:9.4.20.v20190813]
at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:186) [bundleFile:9.4.20.v20190813]
at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1204) [bundleFile:9.4.20.v20190813]
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141) [bundleFile:9.4.20.v20190813]
at org.ops4j.pax.web.service.jetty.internal.JettyServerHandlerCollection.handle(JettyServerHandlerCollection.java:80) [bundleFile:?]
at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127) [bundleFile:9.4.20.v20190813]
at org.eclipse.jetty.server.Server.handle(Server.java:494) [bundleFile:9.4.20.v20190813]
at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:374) [bundleFile:9.4.20.v20190813]
at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:268) [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.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_181]
Caused by: org.eclipse.jetty.io.EofException
at org.eclipse.jetty.io.ChannelEndPoint.flush(ChannelEndPoint.java:283) ~[bundleFile:9.4.20.v20190813]
at org.eclipse.jetty.io.WriteFlusher.flush(WriteFlusher.java:422) ~[bundleFile:9.4.20.v20190813]
at org.eclipse.jetty.io.WriteFlusher.write(WriteFlusher.java:277) ~[bundleFile:9.4.20.v20190813]
at org.eclipse.jetty.io.AbstractEndPoint.write(AbstractEndPoint.java:381) ~[bundleFile:9.4.20.v20190813]
at org.eclipse.jetty.server.HttpConnection$SendCallback.process(HttpConnection.java:818) ~[bundleFile:9.4.20.v20190813]
at org.eclipse.jetty.util.IteratingCallback.processing(IteratingCallback.java:241) ~[bundleFile:9.4.20.v20190813]
at org.eclipse.jetty.util.IteratingCallback.iterate(IteratingCallback.java:223) ~[bundleFile:9.4.20.v20190813]
at org.eclipse.jetty.server.HttpConnection.send(HttpConnection.java:549) ~[bundleFile:9.4.20.v20190813]
at org.eclipse.jetty.server.HttpChannel.sendResponse(HttpChannel.java:857) ~[bundleFile:9.4.20.v20190813]
at org.eclipse.jetty.server.HttpChannel.write(HttpChannel.java:929) ~[bundleFile:9.4.20.v20190813]
at org.eclipse.jetty.server.HttpOutput.write(HttpOutput.java:250) ~[bundleFile:9.4.20.v20190813]
at org.eclipse.jetty.server.HttpOutput.write(HttpOutput.java:226) ~[bundleFile:9.4.20.v20190813]
at org.eclipse.jetty.server.HttpOutput.write(HttpOutput.java:525) ~[bundleFile:9.4.20.v20190813]
at org.glassfish.jersey.servlet.internal.ResponseWriter$NonCloseableOutputStreamWrapper.write(ResponseWriter.java:325) ~[?:?]
at org.glassfish.jersey.message.internal.CommittingOutputStream.write(CommittingOutputStream.java:229) ~[bundleFile:?]
at org.glassfish.jersey.message.internal.WriterInterceptorExecutor$UnCloseableOutputStream.write(WriterInterceptorExecutor.java:299) ~[bundleFile:?]
at org.glassfish.jersey.message.internal.ReaderWriter.writeTo(ReaderWriter.java:116) ~[bundleFile:?]
at org.glassfish.jersey.message.internal.AbstractMessageReaderWriterProvider.writeTo(AbstractMessageReaderWriterProvider.java:79) ~[bundleFile:?]
at org.glassfish.jersey.message.internal.InputStreamProvider.writeTo(InputStreamProvider.java:105) ~[bundleFile:?]
at org.glassfish.jersey.message.internal.InputStreamProvider.writeTo(InputStreamProvider.java:60) ~[bundleFile:?]
at org.glassfish.jersey.message.internal.WriterInterceptorExecutor$TerminalWriterInterceptor.invokeWriteTo(WriterInterceptorExecutor.java:265) ~[bundleFile:?]
at org.glassfish.jersey.message.internal.WriterInterceptorExecutor$TerminalWriterInterceptor.aroundWriteTo(WriterInterceptorExecutor.java:250) ~[bundleFile:?]
at org.glassfish.jersey.message.internal.WriterInterceptorExecutor.proceed(WriterInterceptorExecutor.java:162) ~[bundleFile:?]
at org.glassfish.jersey.server.internal.JsonWithPaddingInterceptor.aroundWriteTo(JsonWithPaddingInterceptor.java:106) ~[?:?]
at org.glassfish.jersey.message.internal.WriterInterceptorExecutor.proceed(WriterInterceptorExecutor.java:162) ~[bundleFile:?]
at org.glassfish.jersey.server.internal.MappableExceptionWrapperInterceptor.aroundWriteTo(MappableExceptionWrapperInterceptor.java:86) ~[?:?]
… 53 more
Caused by: java.io.IOException: Eine bestehende Verbindung wurde softwaregesteuert
durch den Hostcomputer abgebrochen
at sun.nio.ch.SocketDispatcher.writev0(Native Method) ~[?:1.8.0_181]
at sun.nio.ch.SocketDispatcher.writev(SocketDispatcher.java:55) ~[?:1.8.0_181]
at sun.nio.ch.IOUtil.write(IOUtil.java:148) ~[?:1.8.0_181]
at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:504) ~[?:1.8.0_181]
at org.eclipse.jetty.io.ChannelEndPoint.flush(ChannelEndPoint.java:263) ~[bundleFile:9.4.20.v20190813]
at org.eclipse.jetty.io.WriteFlusher.flush(WriteFlusher.java:422) ~[bundleFile:9.4.20.v20190813]
at org.eclipse.jetty.io.WriteFlusher.write(WriteFlusher.java:277) ~[bundleFile:9.4.20.v20190813]
at org.eclipse.jetty.io.AbstractEndPoint.write(AbstractEndPoint.java:381) ~[bundleFile:9.4.20.v20190813]
at org.eclipse.jetty.server.HttpConnection$SendCallback.process(HttpConnection.java:818) ~[bundleFile:9.4.20.v20190813]
at org.eclipse.jetty.util.IteratingCallback.processing(IteratingCallback.java:241) ~[bundleFile:9.4.20.v20190813]
at org.eclipse.jetty.util.IteratingCallback.iterate(IteratingCallback.java:223) ~[bundleFile:9.4.20.v20190813]
at org.eclipse.jetty.server.HttpConnection.send(HttpConnection.java:549) ~[bundleFile:9.4.20.v20190813]
at org.eclipse.jetty.server.HttpChannel.sendResponse(HttpChannel.java:857) ~[bundleFile:9.4.20.v20190813]
at org.eclipse.jetty.server.HttpChannel.write(HttpChannel.java:929) ~[bundleFile:9.4.20.v20190813]
at org.eclipse.jetty.server.HttpOutput.write(HttpOutput.java:250) ~[bundleFile:9.4.20.v20190813]
at org.eclipse.jetty.server.HttpOutput.write(HttpOutput.java:226) ~[bundleFile:9.4.20.v20190813]
at org.eclipse.jetty.server.HttpOutput.write(HttpOutput.java:525) ~[bundleFile:9.4.20.v20190813]
at org.glassfish.jersey.servlet.internal.ResponseWriter$NonCloseableOutputStreamWrapper.write(ResponseWriter.java:325) ~[?:?]
at org.glassfish.jersey.message.internal.CommittingOutputStream.write(CommittingOutputStream.java:229) ~[bundleFile:?]
at org.glassfish.jersey.message.internal.WriterInterceptorExecutor$UnCloseableOutputStream.write(WriterInterceptorExecutor.java:299) ~[bundleFile:?]
at org.glassfish.jersey.message.internal.ReaderWriter.writeTo(ReaderWriter.java:116) ~[bundleFile:?]
at org.glassfish.jersey.message.internal.AbstractMessageReaderWriterProvider.writeTo(AbstractMessageReaderWriterProvider.java:79) ~[bundleFile:?]
at org.glassfish.jersey.message.internal.InputStreamProvider.writeTo(InputStreamProvider.java:105) ~[bundleFile:?]
at org.glassfish.jersey.message.internal.InputStreamProvider.writeTo(InputStreamProvider.java:60) ~[bundleFile:?]
at org.glassfish.jersey.message.internal.WriterInterceptorExecutor$TerminalWriterInterceptor.invokeWriteTo(WriterInterceptorExecutor.java:265) ~[bundleFile:?]
at org.glassfish.jersey.message.internal.WriterInterceptorExecutor$TerminalWriterInterceptor.aroundWriteTo(WriterInterceptorExecutor.java:250) ~[bundleFile:?]
at org.glassfish.jersey.message.internal.WriterInterceptorExecutor.proceed(WriterInterceptorExecutor.java:162) ~[bundleFile:?]
at org.glassfish.jersey.server.internal.JsonWithPaddingInterceptor.aroundWriteTo(JsonWithPaddingInterceptor.java:106) ~[?:?]
at org.glassfish.jersey.message.internal.WriterInterceptorExecutor.proceed(WriterInterceptorExecutor.java:162) ~[bundleFile:?]
at org.glassfish.jersey.server.internal.MappableExceptionWrapperInterceptor.aroundWriteTo(MappableExceptionWrapperInterceptor.java:86) ~[?:?]
… 53 more

NCO · December 28, 2020, 5:32pm

I just started to migrate to OH3 and found out, that I am not able to register the new amazonechocontrol thing.

The problem is, that when I go to the url to register:
http://homer:8080/amazonechocontrol/
The site opens fine and I can select the new thing.
Next is, that I need to login.
Secondly I need to login again (with Captcha) and a notification for approval will be sent to my cell phone.
After I approved, nothing changes and the website above always jumps back to the first login screen.
Does anyone have the same issue?
With 2.5-12 it was working without a hassle.
Thanks in advance.

EDIT:
I got it - don’t know how or why…
I tried it with 4 different browsers: Safari, Firefox, IE, Chrome.
It just was successful with IE.
Apparrently it’s a timing issue.
Whenever I get an approval link sent to my phone I really need to hurry up before the login screen refreshes (jumps back to login).

J-N-K · December 28, 2020, 6:12pm

Did you enable 2FA?

NCO · December 28, 2020, 6:56pm

I don’t think so and I know, that there are issues coming with it.
Furthermore it was working well on 2.5-12.
And according to my amazon account I need to enable it if I would like to use 2FA.
But you are right - it seems to be activated.

bf8392 · January 13, 2021, 6:40pm

Maybe this is the same? TTS on OH3 in Rules and Main-Ui

Tobi77 · January 16, 2021, 10:42am

May I just ask a maybe dumb question? I am a bit sceptic putting my credentials to “some site” (here, http://openhab:8080/amazonechocontrol/). From e.g. myOpenHAB or other services, I am used to be redirected to the “original” provider page such as Amazon, innogy or whatever to put in my credentials which probably leads to some internal key exchange.

Here, I put in my credentials into some local website that looks like the official Alexa page, but it is obviously not.

Don’t get me wrong, I am not notoriously sceptical. But Amazon account data is probably amongst the most critical and sensitive credentials a consumer can have these days… How can I be sure that this data is not sent to a bad person?

Thanks for clarifying my request.

J-N-K · January 16, 2021, 11:07am

Look in the code. It‘s open-source.

Tobi77 · January 16, 2021, 11:18am

Yeah, sure. But then I would need to be sure to understand all underlying mechanisms. I am no programmer, so a comment on the concept would definitely help me.

Something between “Look in the code!” and “Believe me, this is trustworthy!” would be greatly appreciated.

Wolfgang_S · January 16, 2021, 4:26pm

you had a smile behind your question - ok - so one may not have to take it literal.
Doing that J-N-K’s answer is the correct one.
And even that could not be enough: the delivered jar files could be based on other code.
That would mean the only thing you could do is to check the network traffic.
And at that time it already could be too late as the password is sent once you logged the traffic.

So it’s a mater of trust, isn’t it ?

EDIT:
the related code seems to be in openhab-addons/bundles/org.openhab.binding.amazonechocontrol/src/main/java/org/openhab/binding/amazonechocontrol/internal/AccountServlet.java at main · openhab/openhab-addons · GitHub

J-N-K · January 16, 2021, 4:40pm

@Wolfgang_S pointed to the correct location. What you see is Amazon‘s Login Form. It‘s just proxied, so we can get the cookies necessary to emulate the Alexa App.

Tobi77 · January 16, 2021, 5:36pm

Indeed, and it is not meant personally at all. I mean, it’s like giving the PIN of your credit card to someone: It never feels really good.

@J-N-K , please apologise in case this felt like a personal offend…

jlekhter · January 22, 2021, 8:48pm

Sorry if this has been answered, but I’m still getting DateTimeParse errors in the log for the amazon echo control binding. Looking through the thread it seems like it was brought up in the past, but I couldnt find a definitive solution for it. I’m still on openhab 2.5.3 but using the 2.5.11 version of the binding. Here is the log excerpt:

==> /var/log/openhab2/openhab.log <==

2021-01-19 21:28:59.030 [ERROR] [trol.internal.handler.AccountHandler] - refresh data fails with unexpected error

java.time.format.DateTimeParseException: Text '2021-01-20Tnull-08:00' could not be parsed at index 11

at java.time.format.DateTimeFormatter.parseResolved0(DateTimeFormatter.java:1949) ~[?:1.8.0_222]

at java.time.format.DateTimeFormatter.parse(DateTimeFormatter.java:1851) ~[?:1.8.0_222]

at java.time.ZonedDateTime.parse(ZonedDateTime.java:597) ~[?:1.8.0_222]

at java.time.ZonedDateTime.parse(ZonedDateTime.java:582) ~[?:1.8.0_222]

at org.openhab.binding.amazonechocontrol.internal.handler.EchoHandler.updateNotifications(EchoHandler.java:1283) ~[?:?]

at org.openhab.binding.amazonechocontrol.internal.handler.AccountHandler.lambda$4(AccountHandler.java:489) ~[?:?]

at java.util.concurrent.CopyOnWriteArrayList.forEach(CopyOnWriteArrayList.java:891) ~[?:1.8.0_222]

at java.util.concurrent.CopyOnWriteArraySet.forEach(CopyOnWriteArraySet.java:404) ~[?:1.8.0_222]

at org.openhab.binding.amazonechocontrol.internal.handler.AccountHandler.refreshNotifications(AccountHandler.java:488) ~[?:?]

at org.openhab.binding.amazonechocontrol.internal.handler.AccountHandler.refreshData(AccountHandler.java:585) ~[?:?]

at org.openhab.binding.amazonechocontrol.internal.handler.AccountHandler.refreshAfterCommand(AccountHandler.java:830) ~[?:?]

at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [?:1.8.0_222]

at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:1.8.0_222]

at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180) [?:1.8.0_222]

at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) [?:1.8.0_222]

at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:1.8.0_222]

at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:1.8.0_222]

at java.lang.Thread.run(Thread.java:748) [?:1.8.0_222]

Any help is appreciated.

Thanks,

Jerry

miazza · January 24, 2021, 2:42pm

hello , since few days all Things have changed their ID and things a very frequently going offline.
Am I alone in this ?
The issue is the same treated in this discussion:
https://community.openhab.org/t/amazon-amazonechocontrol-smarthomedevice-things-in-unknown-state/110156/8

platyase · January 30, 2021, 9:39pm

I seem to be having a similar error too, on OpenHab 2.5.12 and that version of the Amazon Echo Control Binding. Have you figured out a solution to the issue? It seemed to have started maybe two weeks ago, but I haven’t made any recent changes to my OpenHab configuration. Actually, I was on 2.5.9 for a while, then upgraded to 2.5.12 today to see if it would fix the issue, but no luck.

13:20:57.929 [ERROR] [rnal.common.AbstractInvocationHandler] - An error occurred while calling method ‘ThingHandler.handleCommand()’ on ‘org.openhab.binding.amazonechocontrol.internal.handler.EchoHandler@2c6275’: GET url ‘https://alexa.amazon.com/api/behaviors/automations?limit=2000’ failed: Not Found
org.openhab.binding.amazonechocontrol.internal.HttpException: GET url ‘https://alexa.amazon.com/api/behaviors/automations?limit=2000’ failed: Not Found
at org.openhab.binding.amazonechocontrol.internal.Connection.makeRequest(Connection.java:691) ~[?:?]
at org.openhab.binding.amazonechocontrol.internal.Connection.makeRequestAndReturnString(Connection.java:555) ~[?:?]
at org.openhab.binding.amazonechocontrol.internal.Connection.makeRequestAndReturnString(Connection.java:550) ~[?:?]
at org.openhab.binding.amazonechocontrol.internal.Connection.getRoutines(Connection.java:1840) ~[?:?]
at org.openhab.binding.amazonechocontrol.internal.Connection.startRoutine(Connection.java:1770) ~[?:?]
at org.openhab.binding.amazonechocontrol.internal.handler.EchoHandler.handleCommand(EchoHandler.java:640) ~[?:?]
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:1.8.0_251]
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[?:1.8.0_251]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:1.8.0_251]
at java.lang.reflect.Method.invoke(Method.java:498) ~[?:1.8.0_251]
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.$Proxy164.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_251]
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[?:1.8.0_251]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:1.8.0_251]
at java.lang.reflect.Method.invoke(Method.java:498) ~[?:1.8.0_251]
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_251]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:1.8.0_251]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:1.8.0_251]
at java.lang.Thread.run(Thread.java:748) [?:1.8.0_251]

J-N-K · January 30, 2021, 9:45pm

You have a different issue that is already fixed.

platyase · January 30, 2021, 9:58pm

Yes, I think it’s a different issue. I manually updated to the 2.5.13 echo control and it seems to be working now.

Confused · January 31, 2021, 12:58pm

I’m getting the same error as @jlekhter with the DateTimeParseException

I’m using openHAB 2.5.7, and this continues with the 2.5.13 Binding that I’ve just updated to (which seems to have fixed the routines issue! )

But I must say a huge thank you for writing this Binding, it’s become a core part of my home automation!

J-N-K · January 31, 2021, 1:18pm

I‘ll check the other error.

J-N-K · January 31, 2021, 2:32pm

Can you please tell me from what version that stacktrace is? Otherwise it‘s a bit difficult to find it.