Iām having trouble logging into the /amazonechocontrol/Amazon page. The site tries to authenticate through a text but locks me back out when I approve. Has anyone else experienced this?
Hi, I am getting these errors:
2020-12-09 18:53:40.160 [INFO ] [control.internal.handler.EchoHandler] - getPlayer fails
org.openhab.binding.amazonechocontrol.internal.HttpException: GET url āhttps://alexa.amazon.de/api/np/player?deviceSerialNumber=xxxxxxxxx&deviceType=A1RABVCI4QCIKC&screenWidth=1440ā failed: Internal Server Error
at org.openhab.binding.amazonechocontrol.internal.Connection.makeRequest(Connection.java:695) ~[bundleFile:?]
at org.openhab.binding.amazonechocontrol.internal.Connection.makeRequestAndReturnString(Connection.java:558) ~[bundleFile:?]
at org.openhab.binding.amazonechocontrol.internal.Connection.makeRequestAndReturnString(Connection.java:553) ~[bundleFile:?]
at org.openhab.binding.amazonechocontrol.internal.Connection.getPlayer(Connection.java:1095) ~[bundleFile:?]
at org.openhab.binding.amazonechocontrol.internal.handler.EchoHandler.updateState(EchoHandler.java:842) [bundleFile:?]
at org.openhab.binding.amazonechocontrol.internal.handler.AccountHandler.refreshData(AccountHandler.java:580) [bundleFile:?]
at org.openhab.binding.amazonechocontrol.internal.handler.AccountHandler.refreshAfterCommand(AccountHandler.java:831) [bundleFile:?]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) [?:?]
at java.util.concurrent.FutureTask.run(FutureTask.java:264) [?:?]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304) [?:?]
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) [?:?]
It is only coming if the ECHO DOT type is A1RABVCI4QCIKC.
If I try another ECHO DOT, which has the type: A32DOYMUN6DTXA, there is no problem accessing that API.
Any idea how to debug/fix?
did you enable 2FA / two step verification as explained here: https://www.amazon.com/gp/help/customer/display.html?nodeId=202073820 ?
Yes, I did.
I have 3 A1RABVCI4QCIKC and 4 A32DOYMUN6DTXA, and it was 100% fully reproducible with all the A1RABVCI4QCIKC (getting internal server error http500) and was just working fine with all the A32DOYMUN6DTXA echo dots.
Later I realized that problem was present in https://alexa.amazon.de Now Platying menu, but even in the Android App as well (it could not get the status of player of those echo dots)
So this problem is nothing to do with the openhab binding.
I sent a feedback to amazon yesterday evening about this.
Today it is working just fine with every echo dots. I am not sure it is because of the feedbackā¦ but anyhow, it is Okay now.
regards
Hello,
so far I understood that you just have to mark an Item with ie. [āLightingā] ā¦ if the org.openhab.openhabcloud binding is active you donāt have to expose the item to the cloud and the Alexa App will find your new item to be ready for voice control.
This is how it works for me in the past ā¦
But not anymore 
I canāt say when it worked lately because I didnāt add any items to Alexa for a long time, but now it doesnāt work anymore.
Does any one know why
Cheers
Hi again 
found a workaround :
The amazonechocontrol-binding is hindering Alexa to find new Items.
You have to remove amazonechocontrol from addons.cfg ā¦ wait until its done
Start searching for new Items in your Alexa App
well done - all items found
afterwards add amazonechocontrol again to addons.cfg
Thats it !
So, the problem is definitely the amazonechocontrol binding here
Regards
Any chance the echo auto can be added with location services? (Not sure if possible)
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']
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
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).
Did you enable 2FA?
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.
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.
Look in the code. Itās open-source.
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.
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
@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.
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ā¦
1 Like
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