Release Candidate and Support: Amazon Echo Control Binding

J-N-K · December 5, 2020, 5:39pm

value: PowerController.powerState
config:
  category: LIGHT

That’s what I configure as alexa-metadata on OH3 and that works. I have no idea how to do that in OH2.

miazza · December 5, 2020, 5:44pm

Im running OH 2.5.10 with latest snapshot of your Binding (this fixed the refresh status of the switches).
Is there any reason why the expire binding is not working anymore for timers longer than 1 or 2 minutes ?
I mean, can this expiring issue be raleted to the way Echo Control Bindings refresh items ?

In the event-log I cannot see anything strange.

elarge · December 5, 2020, 9:17pm

The problem seems to be that Amazon cannot read my new exported variables at all. At the moment I presse the search button in the App I get a lot of errormessages in the log.

JamesB · December 9, 2020, 2:27pm

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?

goldie · December 9, 2020, 5:58pm

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?

Wolfgang_S · December 9, 2020, 8:19pm

did you enable 2FA / two step verification as explained here: https://www.amazon.com/gp/help/customer/display.html?nodeId=202073820 ?

goldie · December 10, 2020, 8:55am

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

sticki · December 10, 2020, 8:11pm

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

sticki · December 10, 2020, 8:34pm

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

delid4ve · December 17, 2020, 6:29pm

Any chance the echo auto can be added with location services? (Not sure if possible)

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