Bug 13781 - Alarm Clock needs backup alarm
: Alarm Clock needs backup alarm
Status: CLOSED FIXED
Product: SB Radio
Classification: Unclassified
Component: Menus
: Include FW version in comment
: PC Other
: P1 major (vote)
: 7.4.0
Assigned To: Richard Titmuss
: best_practices
Depends on: 12253 14217
Blocks:
  Show dependency treegraph
 
Reported: 2009-08-31 07:35 UTC by Blackketter Dean
Modified: 2010-05-27 14:46 UTC (History)
8 users (show)

See Also:
Category: ---


Attachments
patch to make sure self.player is set (1.05 KB, patch)
2009-09-22 21:54 UTC, Ben Klaas
Details | Diff
Path to suppress the splash sound on boot (975 bytes, patch)
2009-09-23 04:06 UTC, Richard Titmuss
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Blackketter Dean 2009-08-31 07:35:08 UTC
The alarm clock applet should be able to sound an alarm if there's no network or if it's powered off.  This should include powering up from battery if in off mode (using the built-in battery if available)  and then playing back a local sound effect if the alarm sound isn't available over the network.
Comment 1 Ben Klaas 2009-08-31 07:51:50 UTC
Questions to be answered:

1. Is Baby telling time correctly when not connected to the network?
2. What tone should be used for the fallback alarm and is it already in the baby firmware?
3. Corner case: if Baby is controlling another player should it be possible to a) set an alarm for that player and if so, b) what's the behavior of Baby if the network goes down?
Comment 2 Chris Owens 2009-08-31 09:20:24 UTC
We need to be sure that the RTC is actually being used by the OS.  Caleb, do you know if that's done?
Comment 3 Ben Klaas 2009-09-05 06:32:08 UTC
*** Bug 13765 has been marked as a duplicate of this bug. ***
Comment 4 SVN Bot 2009-09-10 14:06:35 UTC
 == Auto-comment from SVN commit #28490 to the slim repo by bklaas ==
 == https://svn.slimdevices.com/slim?view=revision&revision=28490 ==

Bug: 13781 +2
Description: SC-side support for sending secs to next alarm (as alarm_next) in playerstatus response to SP
Comment 5 SVN Bot 2009-09-11 20:46:31 UTC
 == Auto-comment from SVN commit #7536 to the jive repo by bklaas ==
 == https://svn.slimdevices.com/jive?view=revision&revision=7536 ==

Bug: 13781 +5
Description: First checkin for RTC backup alarm. Still undoubtedly buggy and needs testing, but this marks the first successful test of it
Comment 6 SVN Bot 2009-09-12 08:56:59 UTC
 == Auto-comment from SVN commit #7539 to the jive repo by bklaas ==
 == https://svn.slimdevices.com/jive?view=revision&revision=7539 ==

Bug: 13781
Description: poach demo mp3 for a fallback alarm tone. This is temporary until we decide what we want to use for the fallback alarm tone on baby
Comment 7 SVN Bot 2009-09-13 09:32:43 UTC
 == Auto-comment from SVN commit #7542 to the jive repo by bklaas ==
 == https://svn.slimdevices.com/jive?view=revision&revision=7542 ==

Bug: 13781
Description: store alarmNext as epoch secs so after reboot a sensible thing can be done for setting the fallback timer
Comment 8 SVN Bot 2009-09-13 14:07:15 UTC
 == Auto-comment from SVN commit #7545 to the jive repo by bklaas ==
 == https://svn.slimdevices.com/jive?view=revision&revision=7545 ==

Bug: 13781
Description: more supporting code for fallback alarm
Comment 9 SVN Bot 2009-09-14 10:55:48 UTC
 == Auto-comment from SVN commit #28512 to the slim repo by bklaas ==
 == https://svn.slimdevices.com/slim?view=revision&revision=28512 ==

Bug: 13781
Description: send epochsecs instead of remaining secs for alarmInNextday query
Comment 10 SVN Bot 2009-09-14 15:07:48 UTC
 == Auto-comment from SVN commit #7563 to the jive repo by bklaas ==
 == https://svn.slimdevices.com/jive?view=revision&revision=7563 ==

Bug: 13781
Description: use init method instead of __init method in Applets so self is really available
Comment 11 SVN Bot 2009-09-14 17:35:08 UTC
 == Auto-comment from SVN commit #7566 to the jive repo by bklaas ==
 == https://svn.slimdevices.com/jive?view=revision&revision=7566 ==

Bug: 13781
Description: RTC alarm fires 30 seconds after the minute that the SC alarm was set for
don't do decode:stop() unless RTC alarm is running
Comment 12 SVN Bot 2009-09-15 09:38:46 UTC
 == Auto-comment from SVN commit #28527 to the slim repo by bklaas ==
 == https://svn.slimdevices.com/slim?view=revision&revision=28527 ==

Bug: 13781
Description: don't push ip3k screensaver on clients with no display
Comment 13 SVN Bot 2009-09-15 13:15:11 UTC
 == Auto-comment from SVN commit #7583 to the jive repo by bklaas ==
 == https://svn.slimdevices.com/jive?view=revision&revision=7583 ==

Bug: 13781 +16
Description: working fallback timer
needs micro-controller support, but should be otherwise done
Comment 14 Ben Klaas 2009-09-15 13:20:25 UTC
Richard, everything should work except the microcontroller support-- as I recall that's to store the alarm time so a battery-powered baby will auto-wake before the alarm is due.

related: will the boot music sound when the baby powers up? If so, we'll want to suppress that.

Can you either add the necessary bits for the last part here or point me in the right direction so I can do it?
Comment 15 Caleb Crome 2009-09-15 22:17:45 UTC
The alarm support is already there.

Just:

echo <ephoch-seconds> > /sys/bus/i2c/devices/1-0010/alarm_time

to set the alarm

and 

cat /sys/bus/i2c/devices/1-0010/alarm_time

to check it.

Whenever the 'time' passes 'alarm_time', and the power is off, the baby should power up.
Comment 16 Richard Titmuss 2009-09-16 02:10:15 UTC
Ben, the file Caleb discusses works in seconds since unix epoch. That file should be written in SqueezeboxBabyApplet, you'll see examples in there on how to write to /sys from the lua. You'll need to add a service call for the alarm applet to access it.

If it's a clean shutdown the boot sound will work. I'll have to think about that. Actually the splash sound is now called from SqueezeboxBabyApplet, so that could check the alarm time and real time, and if they are within 2/3 minutes suppress the boot sound.
Comment 17 Ben Klaas 2009-09-16 13:48:35 UTC
There is a problem now in that the server-side epochsecs != squeezeplay-side epochsecs because squeezeplay is not doing TZ offset and mistakenly thinks it is UTC. This causes the microcontroller wakeup file to be incorrectly set and blocks this bug from closing.

Deferring to a fix for bug 12253
Comment 18 SVN Bot 2009-09-16 14:01:26 UTC
 == Auto-comment from SVN commit #7621 to the jive repo by bklaas ==
 == https://svn.slimdevices.com/jive?view=revision&revision=7621 ==

Bug: 13781
Description: set wakeup time to microcontroller. currently disabled pending fix for bug 12253
Comment 19 SVN Bot 2009-09-16 16:17:24 UTC
 == Auto-comment from SVN commit #7628 to the jive repo by bklaas ==
 == https://svn.slimdevices.com/jive?view=revision&revision=7628 ==

Bug: 13781
Description: pass in very large integer to unset microcontroller wakeup alarm
need to pass in as a string, presumably because Lua is 1-based
Comment 20 Ben Klaas 2009-09-22 09:05:18 UTC
Status: while 12253 blocks this from being closed, Brandon gave me a pointer on how I can set the timezone manually so I can test it. I'll be doing that today and if it all checks out this bug will just be waiting on the 12253 fix with nothing left to do code-wise.
Comment 21 Ben Klaas 2009-09-22 13:43:07 UTC
The alarm_time file when set is not powering up the Baby at the specified epochsecs.


Step 1. per instructions from Brandon, link /etc/localtime to the correct timezone. For me that's US/Central

# ls -al /etc/localtime      
lrwxrwxrwx    1 root     root           32 Sep 22 09:53 /etc/localtime -> ../usr/share/zoneinfo/US/Central
# 


Step 2. Unset SC alarm via Baby UI to verify that alarm_time file is an unsigned -1

# cat /sys/bus/i2c/devices/1-0010/alarm_time 
4294967295

Step 3. Set alarm to ~10 minutes in the future (alarm is now set for 3:49 p.m.)
observe that alarm_time file is set for ~8 minutes past the return value for `date +%s`.
# date
Tue Sep 22 15:37:51 CDT 2009
# date +%s
1253651885
# cat /sys/bus/i2c/devices/1-0010/alarm_time 
1253652360

Step 4. Wait > 8 minutes. I observe that the Baby does not power itself back on.


I'm using r7707 with a slight modification of SqueezeboxBabyApplet writes to the alarm_time file (currently commented out in the checked in code), which works properly. It's the auto power up that's not working...

Anyone have any thoughts? Caleb, pushing this your way first...
Comment 22 Caleb Crome 2009-09-22 13:53:55 UTC
It looks like you're setting alarm_time realative to system time.

However, are you sure that system time is the same as MSP time?  

Try this pseudo code:
  alarm_offset = alarm_time - now
  msp_time = `cat /sys/bus/i2c/devices/1-0010/time`
  msp_alarm_time = msp_time + alarm_offset
  echo msp_alarm_time > /sys/bus/i2c/devices/1-0010/alarm_time.

Check your system time vs. msp time.  If they are not the same, you'll have problems with the method you're using -- they run on different clocks.

-Caleb
Comment 23 Ben Klaas 2009-09-22 13:57:01 UTC
yes, they are not the same :(

So you're recommendation would be to code an offset on the Lua side to account for this? MSP Time != System time is working as designed?

# cat /sys/bus/i2c/devices/1-0010/time
1253634951
# date +%s
1253652953
#
Comment 24 Ben Klaas 2009-09-22 21:54:28 UTC
Created attachment 5895 [details]
patch to make sure self.player is set

This patch gets most of the way there, but with two critical remaining issues:

1. Alarm sound, whether the client-side fallback or server-side, sometimes will make no noise whatsoever until the volume knob is moved just one detent either way.

2. when Baby awakes via RTC auto-wake, the splash sound is audible on boot.
Comment 25 Ben Klaas 2009-09-22 21:55:29 UTC
Richard, I'm assigning over to you and would like to discuss this tomorrow. See my last comments for details.
Comment 26 Ben Klaas 2009-09-22 22:00:34 UTC
I should also note all of my tests were done working around bug 12253 by doing the following on each boot

power up and connect by ethernet to an up-to-date SC
ssh to baby
# hwclock -w -u
from baby UI, set an alarm for > 3 mins in the future
power down baby
pull the ethernet cable
wait for baby to power itself up
wait until alarm is scheduled to go off
observe behavior

also note: the file write in SqueezeboxBabyApplet.lua is currently commented out because this feature is broken, so that needs uncommenting for any of these tests to work.
Comment 27 Richard Titmuss 2009-09-23 03:56:18 UTC
A good unit test for the mcu wakeup from the command line after four minutes:

  NOW=`date +%s`; NEXT=`echo $NOW | awk  '{ print $1 + 320 }' `; echo $NEXT > /sys/devices/platform/i2c-adapter\:i2c-1/1-0010/alarm_time ;
Comment 28 Richard Titmuss 2009-09-23 04:06:52 UTC
Created attachment 5898 [details]
Path to suppress the splash sound on boot

This patch also clears the alarm_time on boot if the alarm is set in the past. Without this then it's not possible to turn the system off, as the MCU keeps awaking up. This is not a complete fix, if the system is powered up at alarm_time then the mcu alarm_time won't be cleared.

My proposal to Caleb is for the mcu to clear the alarm_time, so it acts as a one shot timer.
Comment 29 Ben Klaas 2009-09-23 07:26:25 UTC
note: the unit test in comment#27 also needs a `hwclock -w -u` at the start currently, as the file in /sys/bus/i2c/devices/1-0010/time is what the wakeup uses and until 12253 is fixed is off for any other timezone but GMT.
Comment 30 Ben Klaas 2009-09-23 09:56:41 UTC
Richard asked me to test using the back button instead of the volume knob in situations where no volume is heard when the alarm starts. 

I tried this and confirmed that the alarm audio starts when the back button is hit, so this appears to be an issue with the Baby being in power save mode.
Comment 31 Richard Titmuss 2009-09-23 12:55:27 UTC
Case 1 from comment 24 fixed in bug 14217.
Comment 32 SVN Bot 2009-09-23 13:07:06 UTC
 == Auto-comment from SVN commit #7722 to the jive repo by bklaas ==
 == https://svn.slimdevices.com/jive?view=revision&revision=7722 ==

Bug: 13781
Description:
get the local player as self.player in init
if self.player isn't available in openAlarmWindow, get it again
unset microcontroller alarm_time file when alarm time is hit
suppress splash sound on wakeup
Comment 33 Ben Klaas 2009-09-23 15:17:16 UTC
The fixes to the blockers on this makes this fixed too. All necessary code is now checked in for this bug.

As was stated in 12253, needs extensive testing.

QA: some thoughts on that...

Confirm that an alarm set via SC correctly goes off and presents a popup window (snooze/cancel)
Confirm that an alarm set via SN correctly goes off and presents a popup window (snooze/cancel)
Confirm that a set alarm still works if network connectivity is down at time of alarm
Confirm that a Baby Boom will wake itself up, without the startup sound, 3 minutes before an alarm is set to go off, then properly go off at the alarm time.

I will try to test this as much as I can, but the weight of testing is really falling to QA for this now. Alarm clock is a really big deal to get right...
Comment 34 Dan Evans 2009-09-23 16:04:31 UTC
Which canned audio sound did you decide to use as the backup alarm?  I know there was a couple to choose from.
Comment 35 Ben Klaas 2009-09-23 16:05:46 UTC
Same as store demo applet-- a 12 second instrumental loop of Datarock's Fa Fa Fa

Steven's got a copy if you want to hear it.
Comment 36 Julius Dauz 2009-09-25 16:18:48 UTC
I'm seeing this currently with r7745. The alarm activates, but no audio.

I did this test with a live network connection, but the internet connection was severed. The SB Radio was conencted to MySB.Com as its music source.
Comment 37 Julius Dauz 2009-09-25 16:46:23 UTC
Retested with r7757 and SB Server r28637 build and verified the issue has been fixed.
Comment 38 James Richardson 2009-10-05 14:27:33 UTC
This bug has been marked as fixed in the 7.4.0 release version of SqueezeBox Server!
    * SqueezeCenter: 28672
    * Squeezebox 2 and 3: 130
    * Transporter: 80
    * Receiver: 65
    * Boom: 50
    * Controller: 7790
    * Radio: 7790  

Please see the Release Notes for all the details: http://wiki.slimdevices.com/index.php/Release_Notes

If you haven't already, please download and install the new version from http://www.logitechsqueezebox.com/support/download-squeezebox-server.html

If you are still experiencing this problem, feel free to reopen the bug with your new comments and we'll have another look.
Comment 39 Chris Owens 2010-05-27 14:46:18 UTC
These bugs have all been marked resolved and belong to a component which is being removed.  Therefore they have been moved to the most applicable of the new components.