Glad to hear we’re back to just the one issue of the automatic update routine. Hopefully someone will figure out what’s going on with that. Seems to work for some, it not for others.
1 Like
FWIW, it is apparent that there are several fields missing in the cookie retrieved by AlexaCookieJs.
Here are the fields in the cookie that I retrieve manually using Safari (or Chrome):
session-id=
session-id-time=
session-token=
ubid-main=
skin=
i18n-prefs=
at-main=
sess-at-main=
sst-main=
x-main=
x-wl-uid=
lc-main=
sid=
Here are the field in the cookie that is retrieved successfully using AlexaCookieJs:
session-id=
session-id-time=
ubid-main=
at-main=
sess-at-main=
I'm assuming one or more of the missing fields makes a difference. Hoping @gabriele can solve this .... 
1 Like
I don't think missing fields are the problem, because as told by @ogiewon if you try to refresh it immediately, it works, so at least basically it's working.
Mine for example was working since 1 month, then yesterday stopped..
Do somone know if the other integration (EchoSpeakers) it's still working or it's having issues? Library for cookie update should be the same, by Apollon77
Echo Speaks is working without issue (at least for me).
Interestingly, not for me. If I refresh immediately, it stops working within 5 minutes. Basically, as soon as a new cookie is retrieved and replaces the cookie that I manually pasted. Puzzling.
Just to make sure we're clear on the steps I have used to get the Automatic Cookie Refresh to work after it stops behaving...
- I VNC into my Raspberry Pi
- I stop and restart Alexa-Cookie for good measure
- I then open Chromium and connect to the Alexa-Cookie NodeJS server per @gabriele's Readme.
- After getting logged into alexa.amazon.Com successfully within the Alexa-Cookie NodeJS App, I copy the presented "Options" data into my clipboard.
- I go back over to my Hubitat web browser session, where I paste into the Alexa TTS Manager app the "Options" from the NodeJS session.
- I then turn on the Refresh Switch (which turns itself back off) and click Next, Done.
- I wait the five minutes and then go back into Alexa TTS Manager and step through the screens, making sure I can select my Echo devices, and then click Done.
- I go into Devices, find an Echo, and then issue a test Speak command.
At this point, everything works.
6-7 days later, during the normally scheduled Alexa-Cookie refresh time, the cookie returned causes my system to stop working as expected.
I just realized that I may have left one detail out of the equation that may help to explain things... I have two Hubitat hubs that I run in production. Both of these have Alexa TTS running on them, and I have had them both pointing to the same Alexa-Cookie NodeJS server for many months without any issues. After following the steps above, I simply start at step #5 above, and update the second hub. It works after 5 minutes as well. Both hubs start failing at the same time, 6-7 days later. Maybe the issue is they both try to have the Alexa-Cookie NodeJS server refresh the cookie at the same time? I'll need to try just having one Hubitat hub connected to the Alexa-Cookie NodeJS server to see if that makes any difference...
Im seeing similar issues as the above... (I follow the process above pretty closely, I dont have a pi, I have an ubuntu VM running to do the NodeJS functions) I can get it to work for a few minutes or a couple days, but then it starts failing with errors like:
[app:546](http://192.168.50.16/logs/past#app546)2019-07-31 09:18:05.137 am [error](http://192.168.50.16/installedapp/configure/546)'speakMessage()': error = java.lang.IndexOutOfBoundsException: index is out of range 0..-1 (index = 0)
[app:546](http://192.168.50.16/logs/past#app546)2019-07-31 09:18:05.118 am [debug](http://192.168.50.16/installedapp/configure/546)Sending 'test' to 'Joseph's Echo Dot Living room'
[dev:481](http://192.168.50.16/logs/past#dev481)2019-07-31 09:18:05.054 am [debug](http://192.168.50.16/device/edit/481)Speaking message = 'test'
when trying to do a test. I have the current NodeJS setup working and verified it is handing the cookie to the hub, but something seems to be off. Best case it will work for a couple days then die (the hub side of things, the NodeJS side seems to work fine).
Hope this starts working again / or more consistently. It was a nice feature I was going to lean on heavy but at this point it just throws cookie error notifications any time it tried to do a speech message.
What does the cookie generated by AlexaCookieJs look like compared with the cookie that you manually copy?
My observation is that Alexa TTS works flawlessly until a new cookie is retrieved by AlexaCookieJs. There may be something weird about my Alexa login/password (I use 2FA), so I wonder if you could post the fields in your manually copied cookie vs the one from AlexaCookieJs. I've compared the fields I get here.
Thanks!
I had Alexa TTS setup and working for several months. It worked perfectly with my Raspi retrieving a new cookie and providing the new cookie to my Hubitat hub. The automatic retrieval of the cookie seems to be broken now. I uninstalled and then reinstalled NodeJS on my Raspi. Now when I go through the NodeJS setup I dont seem to be able to get node NodeJS to retrieve the cookie. The first login screen doesnt work, I get prompted for the second login. On the second login screen it says success. I close the second screen and look back to the first tab and it seems to just get stuck on please wait.
Just give it time, it will ultimately show the login option and refresh URL. My problem was that although the FIRST cookie that is retrieved works fine, every subsequent cookie would not.
Finally, I decided that retrieving a cookie manually every two weeks using Safari and pasting it into the Alexa TTS setup page takes me less than a minute, which is an inconsequential amount of time. So I stopped using AlexaCookieJs, and simply refresh the cookie manually.
3 Likes
Just giving it time doesn't work.
@ogiewon Ok I'm getting weird shit here.
I can go to the device and manually make it speak but if the device is used in Bigtalker or HSM I get a error saying the cookie isnt good.
What gives Dan ?
I had to delete the devices and start over again to fix this isuue... annoying
If Amazon believes you're exceeding their rate limit, then you'll get the "Check your cookie" notification. Basically, that is the error it spits out for everything, as that is usually the problem. Check the Live/Past Logs and you may see a more detailed error message.
I have never had to delete the child devices and start over. That is a new one for me.
I only use 1 echo device now since I use the Join app on my other tablets now so it can't be rate limited.
Like I said it was weird....
If you try to send too many TTS messages to one Echo, you can still hit the rate limit. I have seen it happening more recently than ever before. Perhaps Amazon made a backend change? Check your logs.
Dear Ogiewon,
What a nuisance that Amazon hasn't implemented (or, perhaps, just hasn't documented) an Oauth flow for programmatically getting an access token for the Alexa API that your text-to-speech app uses! Two ideas occurred to me about how to improve the cookie retrieval/maintenance process. Let me throw these ideas out there on the off-chance that you haven't already considered them:
- Perhaps it would be possible to perform the function of gabriele-v's AlexaCookieNodeJs script entirely within the Groovy code running on the Hubitat.
- The built-in Hubitat app named "Amazon Echo Skill" retrieves and periodically refreshes an access token, presumably for one of Amazon's Alexa-related API's (or so I expect, because I see, in the app's 'state' data, properties named "access_token", "bearerToken", "refreshToken", and "tokenExpires"). Perhaps the token fetched by the "Amazon Echo Skill" app would serve as an alternative to the cookie. If so, even though there might not be a straightforward way for your Hubitat app to programmatically read the state data of the "Amazon Echo Skill" Hubitat app, the user could, at least, manually copy and paste the access token from the "Amazon Echo Skill" app's "installedapp/status" page into a text field in the preferences page of your app, as an alternative to the (presumably more difficult) process of copying and pasting the cookie from his browser's database. Better yet, if it turns out that the token fetched by the "Amazon Echo Skill" app does work for the Amazon API that your app uses, then maybe Hubitat could be persuaded to divulge the relevant parts of the code of the "Amazon Echo Skill" app so that you could incorporate the same technique into your Hubitat app.
Thanks for the great work that you have done on this project.
Sincerely,
Neil Jackson
1 Like
I do not believe this is possible. The author of Echo Speaks also requires a man-in-the-middle server to retrieve the cookie for that integration.
Interesting...however, I have to believe that if it was possible to use the Alexa Skill API to perform Text To Speech, even in this unorthodox manner, the numerous developers who have made custom Alexa Skills would have figured this out already. It is definitely beyond my skill level. Maybe it is possible?
As always, I am happy to accept pull requests. If you’re a programmer and can figure out how to improve this app, I am happy to have the assistance. You definitely have some good ideas! 
good points.
