Apollon77 / alexa-remote

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Error after session active > 24 hours

sleuth255 opened this issue · comments

Hello, Alexa-remote won't correctly process speak functions after its been running for > 24 hours. Here are the relevant log entries:

Alexa-Remote: No authentication check needed (time elapsed 33888)
Alexa-Remote: Sending Request with {"host":"pitangui.amazon.com","path":"/api/behaviors/preview","method":"POST","timeout":10000,"headers":{}} and data={"behaviorId":"PREVIEW","sequenceJson":"{"@type":"com.amazon.alexa.behaviors.model.Sequence","startNode":{"@type":"com.amazon.alexa.behaviors.model.OpaquePayloadOperationNode","operationPayload":{"deviceType":"AKNO1N0KSFN8L","deviceSerialNumber":"G0B0H506617700D3","locale":"de-DE","customerId":"AWMF3SVYOF8RS","textToSpeak":"hello"},"type":"Alexa.Speak"}}","status":"ENABLED"}
Alexa-Remote: Response: No body
Error: no body
at IncomingMessage. (C:\alexa-speaks\public\alexa-remote.js:767:126)
at IncomingMessage.emit (events.js:215:7)
at endReadableNT (_stream_readable.js:1184:12)
at processTicksAndRejections (internal/process/task_queues.js:80:21)

Alexa-Remote always returns "Response: No body" and then Alexa speaks the text, but it appears that the status code is something other than 200 when the problem starts occurring. Here's how the logs look when the command is successful:
Alexa-Remote: No authentication check needed (time elapsed 24222)
Alexa-Remote: Sending Request with {"host":"pitangui.amazon.com","path":"/api/behaviors/preview","method":"POST","timeout":10000,"headers":{}} and data={"behaviorId":"PREVIEW","sequenceJson":"{"@type":"com.amazon.alexa.behaviors.model.Sequence","startNode":{"@type":"com.amazon.alexa.behaviors.model.OpaquePayloadOperationNode","operationPayload":{"deviceType":"AKNO1N0KSFN8L","deviceSerialNumber":"G0B0H506617700D3","locale":"de-DE","customerId":"AWMF3SVYOF8RS","textToSpeak":"hello"},"type":"Alexa.Speak"}}","status":"ENABLED"}
Alexa-Remote: Response: No body

As you can see, they appear to be identical except the successful attempt is receiving a status code that begins with "2".

you could add the respinse code to the Exception so that we could see what exactly the response is about. But if amazon is returning this ... could Isee your code somewhere? I personally do not experience such an effect

yes, I've done that and am waiting for it to fail again (should be in about 15 hours).

I'm actually using your alexa-remote.js code as-is as part of a node.js web wrapper that implements the speak function. It's targeted for use as an Alexa TTS API by home automation systems such as Home Control Assistant. https://github.com/sleuth255/alexa-speaks

Your code is in the public folder. Problem occurs whether useWsMqtt is true or false. Interestingly, when the problem is occurring, your getDevices function still works fine. It is only the speech function that is failing.

Why you do not use the lib as dependency but copy the code?!
Ok ... can it be that there is a time where too many requests are send too fast and amazon rate limiting kicks in?

I wouldn't think so. It fails even if I only send one command (see the logs above). I've had to work out how alexa-remote operates by looking at the code pretty much, so it was just easier to have it handy. Maybe I'm not setting everything up correctly? I'm directly using sendSequenceCommand with a "speak" function, init, and getDevices. from your code currently.

Hmmm... its still up. The only change I made was fix a problem with the refresh cookie interval. I now have the cookie being refreshed every 12 hours. Maybe the en-US locale/site requires a more frequent cookie refresh cycle than once every 7 days? Still, this doesn't explain why getDevices was still functional but the speak function was failing. I'll keep it running and if it lasts another day, I'll close the issue.

more on the bug which is that the default cookie timeout wasn't being set correctly on lines 95/96 of alexa-remote because the option name is being transposed to refreshCookieInterval.

Last bug I thought was fixed already ... maybe your code relies on an old version of Alexa cookie lib and remote lib because you hard Code all deps.

shouldn't those two lines of code say this:

    if (this._options.cookieRefreshInterval === 0) {
        this._options.cookieRefreshInterval = this._options.cookieRefreshInterval || 7*24*60*60*1000; // Auto Refresh after 7 days

??

No code is correct.

If you set the Intervall to 0 then no auto refresh is done. Else it will be used it set to 7days if it has a falsy value (false, null, undefined)

so

   if (this._options.cookieRefreshInterval !== 0) {
       this._options.cookieRefreshInterval = this._options.cookieRefreshInterval || 7*24*60*60*1000; // Auto Refresh after 7 days

is correct then. That's how I have it currently. changed from this:

    if (this._options.refreshCookieInterval !== 0) {
        this._options.refreshCookieInterval = this._options.refreshCookieInterval || 7*24*60*60*1000; // Auto Refresh after 7 days

I'll pull your library in as a dependency. It looks like my setting it to 12x60x60x1000 coupled with the above change has allowed the server to run for more 32+ hours and counting so far.

Hm ... it is very strange that it should need refreshs that often.