@Bloodtick_Jones
Thanks for the info. I went through the authorization 2x and it comes back to this screen for Amazon logon.
Which, of course, is a bad server address, which results in this:
So it appears I've done something wrong - or something else is. I'll try again in a bit.
I am running on a pi3 and it took a couple of attempts to clear the old data/webhook. Not sure what the secret combination was - but eventually it updated and was healthy. Watch the Echo Speaks logs, they helped me with delays. Good luck.
The 0.0.0.0 ip usually means you need to set the ipAddress variable on the server instance.
Check this guide I made: [GUIDE] Echo Speaks Server on Docker (and alternates)
OK, after multiple retries, I finally noticed that the required entry field for using the Heroku server said 'null'. This probably caused the odd server address. I retried a couple of times and it finally didn't say 'null' so I proceeded. I got through the process until it was time to log on to Amazon. I now get through the email/password authorization OK but after multiple iterations of entering the 6-digit 2FA authorization code, Amazon returns this: "Cannot POST /ap/cvf/approval/verifyOtp".
I'm sure my logon is OK and now I think it's just an Amazon issue. I think I'll try again much later. Thanks for listening.
Update: I now tried an additional time by using my phone and I received the same response.
Yeah, that server IP address was obviously wrong and the 'null' entry that produced it was maybe inserted when I was working on the entries of the Heroku page as I ran through the reauthorization steps. Maybe I fat-fingered it somehow - although I didn't actually enter anything anywhere near that field. Who knows, I guess? I did finally notice that the 'null' was there. I then just reran the process steps again and the 'null' was no longer there. Now, I just need to get past the issue occurring when entering the 6-digit 2FA authorization code and Amazon returns this: "Cannot POST /ap/cvf/approval/verifyOtp".
This person was having the same issue today and switched to using an authenticator app for the OTP code and that seems to have worked: [GUIDE] Synology docker for echo-speaks-server ( echo-speaks) - #15 by jtp10181
@jtp10181 and @Bloodtick_Jones
I was finally able to complete the Amazon login process. It appears (to me at least) that Amazon was having an issue that finally cleared. However, in the meantime, I had gotten a security warning on my Amazon page about someone attempting to log in from Virginia. I'm in western NY so it must have been taken from a server I was going through. Anyway, I went to Amazon, cleared the security warning and my Amazon login attempt went right through.
My Echo Speaks cookie has been reconnected and properly refreshed, so I'm good!
Thanks for all the help and information.
Just wanted to jump in and say that it's been smooth sailing here since January 21st after following @jtp10181 's instructions.
I love having this running local.
Thank you!!
Since migrating to C8 I've soft reset my C7, reset Zigbee, and changed the channel. I've noticed the following in the logs, even though Echo Speaks isn't installed (app 27 is Echo Speaks on the C8):
sys:12023-03-18 11:49:56.202 PMwarnReceived cloud request for App 27 that does not exist, path: /receiveData from 3.248.185.168
sys:12023-03-18 11:49:55.789 PMwarnReceived cloud request for App 27 that does not exist, path: /cookie from 3.248.185.168
sys:12023-03-18 11:49:27.596 PMwarnReceived cloud request for App 27 that does not exist, path: /cookie from 3.253.6.194
sys:12023-03-18 11:34:56.114 PMwarnReceived cloud request for App 27 that does not exist, path: /receiveData from 3.253.6.194
Will these go away on their own, or is there something I need to do to stop Amazon pinging the C7?
Take a look at your cookie server ad see if it is still looking at the C7.
@jtp10181 Hey, I followed your guide because my original setup with container on windows wasn't refreshing and server kept stopping. While using your guide was easy, I was having tremendous trouble getting the login to stick. I ended up trying a multitude of things (not sure what made it stick after dozens of reinstalls and starting from scratch on the container side). I ended up using the cloud url for the call back. However, my server missed the refresh and I am not sure why it did. Is it supposed to refresh the cookie after 5 days or was that a Heroku thing? I mean, I get it, if it's not broken then leave it alone. Is it because I used cloud url instead of the local one?
I should still refresh every 5 days, should work fine the way you have it setup. You can go into the echo speaks app on Hubitat and there is a toggle to trigger a manual refresh. You can try that and see if it refreshes. If not, then something is wrong.
Just tried the manual refresh. Didn't work. Didn't even trigger/populate anything in the server's logs. Should i attempt a whole new install of server and relogin using local url? Or update call-back to local?
EDIT: Modifying the call-back to local server url did the trick. I then went to do the manual refresh switch and started seeing the container populate logs on the request trigger. Thank you for the tip on the manual refresh.
2023-03-22 13:37:37 3-22-2023 - 5:37:37pm debug: /config page requested
2023-03-22 13:37:37 3-22-2023 - 5:37:37pm info: Checking for Server Version Updates...
2023-03-22 13:37:38 3-22-2023 - 5:37:38pm info: Server Version is Up-to-Date.
2023-03-22 13:37:41 hubPlatform: Hubitat
2023-03-22 13:37:41 3-22-2023 - 5:37:41pm debug: ** Settings File Updated via Web Config **
2023-03-22 13:37:41 getRemoteCookie...
2023-03-22 13:37:56 3-22-2023 - 5:37:56pm info: Server Wakeup Received | Reason: (runCookieRefresh)
2023-03-22 13:37:58 3-22-2023 - 5:37:58pm verbose: refreshCookie request received
2023-03-22 13:37:58 3-22-2023 - 5:37:58pm debug: cookieData: [object Object]
2023-03-22 13:38:00 3-22-2023 - 5:38:00pm info: Successfully Refreshed Alexa Cookie...
2023-03-22 13:38:25 3-22-2023 - 5:38:25pm warn: Restarting after cookie refresh attempt
2023-03-22 13:38:25 clean
2023-03-22 13:38:25 1
2023-03-22 13:38:25 graceful setting timeout for PID: 1
Thank you - only just spotted this message.
I'm still using Heroku, so logged in and checked the Config Vars, adding the C8 hub ID into appCallbackUrl and smartThingsUrl (just in case). Bounced the instance, and bingo - cookie refreshed after 11 days!
I left the access_token as it was - seems to have worked.
I cannot seem to keep it stable using the Cookie server locally. I'm still using Heroku as it gets updated automatically and has been stable too.
I just cannot get the setting to stick.
Just wanted to say i set this up on a lenovo tiny, using proxmox and it works very solid. I have it speak things for my door locks and sensors, and now with notifications from ecobee suite manager.
I would like to change the voice on it, to one of the other options that hubitat provides but everytime i try and test that, the voice doesn't change. Any ideas?
I’m noticing the following in my logs - any ideas what might cause it and if there’s anything I can do to avoid it?
Voice notifications are working with no issues.
It is an api change by Amazon, @tonesto7 has not had time to find a workaround.
it is harmless otherwise.
Since the text-to-speech output is to an Amazon Alexa enabled device, you’d have to change the voice in the Alexa app.
Hubitat’s built-in TTS feature uses Amazon’s Polly service to speak on other types of connected speakers that don’t have a voice assistant built in.
Thanks! I’ll probably see if I can find the line in the code that generates it in the interim… it’s filling-up my logs! 
Download the Hubitat app
