Fallback Alarm Issue

[elziko]

I have a single alarm defined to wake me up every weekday (i.e. Mon-Fri) at 07:20 - this generally works fine. On Saturday night I deliberately switched off the machine running SqueezeCenter (a guest was staying in that room).

The problem is that on Sunday morning the fallback tone alarm went off at 07:20, as if it knew that it had an alarm to cover at 07:20 but it did not know that this alarm was not defined for Saturdays and Sundays. Waking up at that time on a Sunday cannot be good for you.

Is this normal/expected behavior?

[peterw]

Consider filing a bug report at bugs.slimdevices.com. IIUC, the Boom essentially has a simple 24-hour internal clock representation. Whenever an alarm is scheduled/edited/deleted/added, SC (or SN) tells the boom the next time that an alarm is due. To prevent your scenario from happening, SC/SN should tell the Boom that there are *no* upcoming alarms if there are none for the next 24 hours. This means you'd oversleep on Monday if your server shut down before 7:20 am on Sunday.

There's no way, without firmware enhancements, that SC/SN could tell the Boom that the next alarm fires at 7:20 am "day after tomorrow". Such intelligence might be simple to add with a one-byte day counter. Even so, you'd still need to get SC up & running by 7:20 am Tuesday in order for that alarm to fire since Boom only knows about the very next alarm...

...unless the firmware were further enhanced to be able to remember a "stack" of upcoming alarms. You might as well ask for what you want in the bug you open. Personally I think it should be pretty easy for Boom firmware to allocate as little as 21 bytes so that it could track 10 upcoming alarms (1 byte for the current day value; 10 sets of 11 bits for HH:MM time, the remaining 5 allowing for day counters up to 2 months in the future); naturally there'd also need to be an enhanced client protocol command for setting the Boom (day counter + time) clock, and managing the Boom's internal alarm queue, and more intelligence on the Boom for dealing with the full queue. This could let typical users get through a full week of SC/SN outage without oversleeping.

Max, Felix, whaddya think?

[verypsb]

Had the same problem this saturday...

[Howard Passman]

Had the same problem this saturday...

....that some of these issues are caused by alarms set in SqueezeNetwork and forgotten? Seems like a funny place to be able to set one, but it's there.

If I go look at my SB3 in SN it shows alarms set for no time of day on every day of the week with the alarm button on. If I try to turn it off, it comes right back on. I would assume if I left my SB3 connected to SN, it might trigger unwanted alarms.

Howard

[elziko]

I finally (!) got round to submitting a bug report for this:

http://bugs.slimdevices.com/show_bug.cgi?id=9833

[androidtopp]

To prevent your scenario from happening, SC/SN should tell the Boom that there are *no* upcoming alarms if there are none for the next 24 hours. This means you'd oversleep on Monday if your server shut down before 7:20 am on Sunday.

There's no way, without firmware enhancements, that SC/SN could tell the Boom that the next alarm fires at 7:20 am "day after tomorrow". Such intelligence might be simple to add with a one-byte day counter. Even so, you'd still need to get SC up & running by 7:20 am Tuesday in order for that alarm to fire since Boom only knows about the very next alarm...

I guess I thought this was already implemented - the Boom fires the next alarm (whenever it may be) and that's it. Figuring out when the next alarm is and firing it whenever that time (but not date) rolls around isn't what I had expected. Granted, I expected that without intervention that I wouldn't get an alarm on Tuesday. I'm a dork, and this box is also my mail server, so when it goes down, I notice pretty quick.

Cross linking to my own issue: http://forums.slimdevices.com/showthread.php?t=54301