Appreciate pointing me to that section. Never poked around in the notifications area.
Hi,
I have these errors and warnings in my log and can't decipher them.
EchoApp (v4.2.2.0) | wakeupServerResp Exception: java.lang.Exception: No response data exists for async request
EchoApp (v4.2.2.0) | wakeupServerResp | Stack Trace: java.lang.Exception: No response data exists for async request
at hubitat.scheduling.AsyncResponse.getData(AsyncResponse.groovy:71)
at user_app_tonesto7_Echo_Speaks_167.wakeupServerResp(user_app_tonesto7_Echo_Speaks_167.groovy:2228)
EchoApp (v4.2.2.0) | wakeupServerResp Server may be down / unreachable
EchoApp (v4.2.2.0) | wakeupServerResp: 503
Can someone help me out?
I really appreciate any help you can provide.
If you are not sure Alexa heard you correctly, ask her "Alexa, what did you hear"? She will play back what she heard, which might be what you said, or not.
4 Likes
just deployed echo speaks server to docker on a synology, and after copying in the callbackURL, echo speaks on the hub is showing the internal docker bridged IP, and not the externally routable one. The echo speaks page shows the proper one.
Any way to fix this?
It SEEMS to be preventing it from working (which makes sense since the hub can't get to the .66 address, just .6 (which is the subnet the hub is on)
Check my write up, it shows you how to tell the server what IP to use.
1 Like
Thank you sir! That seems to have done it. just had to set "ipAddress" under advanced settings,
Thanks!
Not that it seems to affect anything, but my Echo Speaks server running in Docker on a Synology NAS stops unexpectedly every five days like clockwork. Thank goodness for auto restart! The app itself continues chugging along nicely. Love it.
Yeah I have the restart in my instructions as well. Someone in one of the threads found an exit statement somewhere in the code they think is probably killing the process under certain circumstances right after the cookie refresh. Sounds like that's what yours is doing.
2 Likes
Hi all,
Has anyone been getting errors in the last couple of days?? I have mine set on a synology nas and it’s been working flawlessly until a a couple of days ago when I started getting these errors in the logs:
getAvailableWakeWords Response Exception | Status: (500) | Msg: status code: 500, reason phrase: Internal Server Error
And I get notifications through the Hubitat app from echo speaks saying:
Echo speaks data refresh issue: the echo speaks app has NOT received any device data from Amazon in the last (14066) seconds. There may be an issue with network
I think these issues only started occurring since the cookie was last updated recently. I tried a manual cookie refresh which seemed to work but then I still got the same errors
1 Like
Nope, I haven’t seen these. Echo Speaks service is running locally on a Rasp Pi 4b, it just refreshes the cookie every 5 days like clockwork. Now, Comcast Xfinity Gbit has been going up/down for the past week as they make some changes, but I just switch over to our AT&T DSL that we have as a second feed for reliability
1 Like
I migrated from a C7 to a C8 on Friday (9 March). I just noticed today that my cookie refresh is failing with this error in the Hubitat logs: "EchoApp (v4.2.2.0) | Amazon Cookie Refresh FAILED 408". (I'm unsure if this started immediately after the migration since my logs don't go back that far.) Is there something I need to do because of the hub change? Or does this just look like a normal Amazon hiccup?
408 is a server timeout, should resolve itself.
Echo speaks was running on the hub I migrated. Everything appeared ok after the migration, but I never got a refresh of the cookie when it was due. I had to redeploy the server. I am running a local server on a RPi.
If the App Callback URL starts with "https://cloud.hubitat.com/api/..."
Then YES, you need to redo the authorization since this is an external webhook that uses the hub ID (that changed).
If the App Callback URL starts with a IPv4 address, then you need to ensure your new hub has the same IPv4 address as the old hub (or redo to ensure it has the correct IPv4).
3 Likes
@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.
1 Like
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.
1 Like
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)
1 Like
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".
