HTTP request has 20 second wake up

#1

1) Give a description of the problem
Trying to use Sonos as an alarm, but the Piston is creating a 20 second delay after the 18 second mp3 is played. So, the 18 second mp3 will play, followed by 20 seconds of silence (or resumed whatever was playing) then loop and play again.

Using **[node-sonos-http-api] because the Sonos api is now broke. Tried playing a longer file so I don’t have to loop, but then if I stop the loop (disable the alarm) the file will resume playing and I’m unable to remove it.

2) What is the expected behaviour?
HTTP request should be sent with no delay (no wake in 20 seconds)

3) What is happening/not happening?
20 s delay before the loop will send additional http requests

**4) Post a Green Snapshot of the piston![image|45x37]

image
image.png1178×639 34.3 KB

5) Attach logs after turning logging level to Full
10/18/2019, 2:59:50 PM +171ms
+0ms ╔Received event [Home].time = 1571435991262 with a delay of -1092ms
+223ms ║RunTime Analysis CS > 70ms > PS > 135ms > PE > 19ms > CE
+226ms ║Runtime (39901 bytes) successfully initialized in 135ms (v0.3.110.20191009) (225ms)
+227ms ║╔Execution stage started
+242ms ║║Comparison (boolean) true is (boolean) true = true (1ms)
+244ms ║║Condition #6 evaluated true (5ms)
+245ms ║║Condition group #5 evaluated true (state did not change) (6ms)
+247ms ║║Cancelling statement #7’s schedules…
+253ms ║║Calculating (string) http://192.168.1.2:5005 + (string) /clippreset/home_alarm/prometheus_siren_18s.mp3 >> (string) http://192.168.1.2:5005/clippreset/home_alarm/prometheus_siren_18s.mp3
+260ms ║║Sending internal web request to: 192.168.1.2:5005/clippreset/home_alarm/prometheus_siren_18s.mp3
+265ms ║║Executed virtual command httpRequest (6ms)
+267ms ║║Requesting a wake up for Fri, Oct 18 2019 @ 3:00:10 PM PDT (in 20.0s)
+273ms ║╚Execution stage complete. (45ms)
+274ms ║Setting up scheduled job for Fri, Oct 18 2019 @ 3:00:10 PM PDT (in 19.994s)
+285ms ╚Event processed successfully (286ms)

#2

http requests are expected to return a response in 20 seconds. The timeout you see is the ‘timeout wakeup’.

If the http request ‘works properly’, it should respond with a response much quicker, and the timeout would be cancelled when handling the response.

#3

The server replies in about 1 second and starts to play the file. If the file is longer than 16 seconds, then the loop continues and somehow the remaining time on the mp3 is saved to play again when the current iteration is done. I can’t seem to interrupt it or stop it from playing other than to pause Sonos, but the mp3’s will stick in the speaker (not in the queue or playlist). Then, if something happens to resume the audio, like a TTS saying the front door is open, the siren mp3 file will continue to play until they’ve all played to their duration. I know this is weird.

Pseudocode:
loop while alarm_is_tripped
http get /clippreset/home_alarm/30sec.mp3 <-- plays the mp3 file

Plays 16 seconds or so of the file, stops as it goes through another loop then plays the second 30sec.mp3 leaving the first mp3 with 14 seconds remaining.

Disarm the alarm at 15 seconds played of file 2 (15 sec remaining, paused)

Front door opens -> “front door is open” TTS plays, then resumes 15 seconds of file 2 followed by 14 seconds of file 1.

I need to either be able to clear the speakers of any mp3 (Sonos is of no help here as it’s not a playlist or a queue, it’s just a streamed music file) or set it to a 1 second empty mp3 to remove the 30sec.mp3 (this doesn’t work as the 1sec.mp3 plays, then the 30sec.mp3 goes right back).

I’m open to other ideas on how to solve this issue to use the Sonos speakers for my doorbell and home alarm.

#4

There are several things going on here. First and foremost, jishi’s clip’ command is a 'play and resume" command. The code (a) allots time for the mp3 to play based the file length, (b) starts the mp3, and (3) at the end of the allotted time tries to restore the speakers to their prior status. Whether playback is interrupted with a second instance of the first mp3 or the 1-second blank mp3, when the second file is done playing, the code attempts to resume playing what was playing immediately before that, which means your original mp3. So, technically, it isn’t that the mp3 is “stuck in the speaker,” but in the resume memory of jishi’s node-sonos.

All this is further complicated by the fact that SmartThings will wait 20 seconds for a server response before reporting a timeout (408) error. Execution will resume when the server responds, or when the 20-second period expires. Note that this timeout is set by SmartThings, not webCoRE, and unfortunately cannot be changed by you programmatically or webCoRE.

Since your mp3 length, the server response time, and SmartThings’ timeout are never going to match, the While Loop is almost always going to work against you, not for you. So I would start by eliminating the Loop entirely and just using an IF/THEN

IF switch changes to ON
THEN
Make GET request (Play clip)
ELSE
Here, you can try, either individually or in combination …
pause, stop, mute, clearqueue
ENDIF

I use my Sonos for alarms, and use the mute command. I check the speaker volume before, play the mp3, mute on OFF, wait X seconds, then restore the original volume and state (for any music I might have already been playing).

One other aside, just as a reference for your future efforts. The actual response time from the node can vary greatly depending on the number of devices are involved and how many changes to speaker configuration have to be made to enable the preset you’ve requested. With my configuration (I have a dozen or so Sonos speakers) and varied presets, 20 seconds is often not enough. For this reason my pistons ignore 408 errors, but do act on 500 errors.

#5

Wow, great level of detail bthrock, thank you! I was thinking there must be something in the API code that was making it do the resume, but was leery of trying to change his code to stop doing the resume, as sometimes that’s the desired behavior.

So, for your alarm, you simply have a very long MP3 and then mute the speakers when you disarm? I can do that, but I believe the long playing MP3 will still be in the speaker until I replace it with another item. I was wondering if I could make a favorite (or queue) and set that with the API to be a silent.mp3, simply to replace the long playing one.

#6

It’s been awhile, so I’d have to look at my pistons again, but I know I either mute or pause upon disarm. It’s the easiest solution for me, as I’m rarely concerned with resuming what was playing previously—although I worked on that, too.

You can, of course, create your own playlists and set them as favorites (in the new API, Sonos has chosen to refer to them as Presets, just to add to the confusion!). I suppose a silent.mp3 could be stored in your music library, added to a playlist, then called with a GET request. Your music library couldn’t be stored on a PC that sleeps if you did that. But how all that would work with what you’re trying to accomplish would take more thought and perhaps some experimentation.

FWIW, I’ve considered posting a request on GitHub for jishi to add the option to clear the prior clip if a second clip is requested, just as he does (or so I remember) with TTS requests. I’ve just never done it.

#7

Yes, having an option to not resume would be great, as would having an option to clear whatever is in the speaker (room). It’s impossible to talk to Sonos support about this, as they simply claim that clear queue will work, but it doesn’t.

Thank you for all your help good sir!

#8

jishi’s clearqueue command works for me.

#9

I honestly don’t know why /clearqueue won’t work for my streamed (/clippreset/) mp3’s, but it does nada. I did find a work around, thanks to you. I configured a NAS to store music with no password (easier than on my NodeJS server). Then I created a playlist with the silent.mp3 on it.

Now the flow is:

  1. Arm Alarm
  2. Open physical door, alarm is tripped
  3. Siren plays long_loud.mp3
  4. Disarm alarm, which does below
  • /pauseall <-- Could mute here, but might as well pause
  • /kitchen/playlist/silent <-- This gets something in the queue that I can remove to empty the speakers
  • /kitchen/clearqueue <-- removes the silent.mp3
  • /kitchen/leave <- Leave’s the home_alarm preset, just to keep things clean.

This seems to work very well. Much better than my impossible loops! In my testing, after a few minutes, sometimes, the siren.mp3 fires again, but I can’t be sure it’s not me refreshing the browser (testing api calls in chrome before I code WebCoRE.

Anyway, this was so much harder than it needed to be! Thank you for all your help.