Topic: Is there a pre_alarm_action ?

I have been trying to get my Chumby One to turn it's speaker on when the alarm is triggered. Usual thing of me listening to audio on a headphone but want others to hear the alarm. The backup alarm is great, but I'd rather it didn't get that far.

Now I've found the command to turn the speaker on :

regutil -w HW_AUDIOOUT_SPEAKERCTRL_CLR=0x01000000

But the only scriptable actions I can find is  /mnt/usb/post_alarm_action, and I've verified that only runs when the alarm is stopped, no use for this application.

Is there a script that gets called when the alarm is starting ? i.e a pre_alarm_action

Thanks

Re: Is there a pre_alarm_action ?

To answer my own question. I decided as there maybe is no immediate solution, I took a sledgehammer to this walnut. I'm posting here in case it's of any use to anyone else. Isn't Chumby great that you can get right in there and change things you don't quite like.

I basically have three files "speakeroncron", "speakeronalm" and "alarmparse" in /psp. "alarmparse" uses the /psp/alarms file that stores alarm times and converts these to cron entries. I have wrapped this is an shell script "speakeroncron" , this checks if the alarms file is newer than the crontab file. If so, it reparses the alarms file and generates new cron entries.

First is speakeroncron

#!/bin/sh

if [ "/psp/alarms" -nt "/psp/crontabs/root" ] ; then
    grep -v '/psp/speakeronalm' /psp/crontabs/root >/psp/cleanrootcrontab
    cat /psp/cleanrootcrontab | /psp/alarmparse | crontab -
fi

Then the perl I use to parse "alarmparse":

#!/usr/bin/perl

# Script to parse alarms file and create appropriate cron entries

while (<>) { print $_;};

open ($fh,"/psp/alarms") or die "Failed to open alarms file";
read ($fh, $alarms, 20480);
close ($fh);

%daysofw = ("monday",1,"tuesday",2,"wednesday",3,"thursday",4,"friday",5,"saturday",6,"sunday",7);

@alarmlines=split("<alarm name=",$alarms);
foreach (@alarmlines){
    /enabled=\"(\d+)" time=\"(\d+)\" when=\"(.+)\"/;
    $enabled=$1;
    $altime=$2;
    $when=$3;
    next if (!$enabled);
    if ($when eq "once") {
        ($sec,$min,$hour,$mday,$mon,$year,$wday,$yday,$isdst) =
                                                localtime($altime*60);
        print "$min $hour $mday ",$mon+1," * /psp/speakeronalm\n";
    }
    else {
        $wdays="";
        $wdays="1-5" if ($when eq "weekday");
        $wdays="6,0" if ($when eq "weekend");
        $wdays="\*" if ($when eq "daily");
        $wdays=$daysofw{$when} if ($wdays eq "");
        next if ($wdays eq "");
        
        $min=$altime%60;
        $hour=int($altime/60);
        print "$min $hour * * $wdays /psp/speakeronalm\n";
    }
        
}

And finally the job cron runs, "speakeronalm", I put in a 3s delay just to let things settle before turning the speaker on (didn't know if the alarm program is fiddling with stuff so didn't want to tread on it's toes). And didn't want the possibility that the speaker playing earlier than the alarm:

#!/bin/sh

sleep 3
regutil -w HW_AUDIOOUT_SPEAKERCTRL_CLR=0x01000000 >/dev/null 2>/dev/null

Then just cron /psp/speakeroncron this as often as you think necessary, hourly was enough for me ( I don't change alarm times often):

4 * * * * /psp/speakeroncron

When the cron runs it will populate roots cron with /psp/speakeronalm jobs for the times you set your alarms for.

The limitations are a few. One, if you change alarm times to go off sooner than the cron runs, the speaker won't go on. Also after the alarm goes off you need to remember the speaker is now enabled so if you go back to audio say (or have it set to auto go back to audio) then this will also go through the speaker still.  I personally want to leave the speaker enabled, as if I hit snooze ,I want that next alarm to come through the speaker too. If not using snooze, I guess you could save the speaker state in the cron script and return it to the correct state using post_alarm_action (not sure how you'd handle the snoozed alarm though).

Re: Is there a pre_alarm_action ?

Just for the public record I've modified my "speakeronalm" script to poll every 5 seconds looking for something playing the alarm sounds mp3's. If so turn the speaker on. The alarm seems to turn it off on next sounding (on next snooze cycle). Do this for half an hour to cope with the any snoozed alarms.

#!/bin/sh

sleep 3
regutil -w HW_AUDIOOUT_SPEAKERCTRL_CLR=0x01000000 >/dev/null 2>/dev/null

for a in `seq 1 360`;  do
    sleep 5
    fuser /usr/chumby/alarmtones/* >/dev/null 2>/dev/null
    if [ $? -eq 0 ]; then
        regutil -w HW_AUDIOOUT_SPEAKERCTRL_CLR=0x01000000 >/dev/null 2>/dev/null
    fi
done

Re: Is there a pre_alarm_action ?

Hello!

I don't need to turn on the speakers on alarm, but I really love the way you connect the alarm system to cron. I have done a slightly modified version of your scripts, basically I did:

*) put the scripts in the directory "/psp/alarm2cron" and renamed the scripts to more general names.
*) pass the alarm name and index to the executing script, so you can react on the name and do differnt things with several alarms.

Now I can use the alarm system to schedule all kind of things. If you are interested, you can take a look in "my" scripts:
http://web.student.tuwien.ac.at/~e98254 … m2cron.tar

Thanks for this nice and helpful hack!
Christian

Re: Is there a pre_alarm_action ?

Sorry to revive an old topic but this is exactly what I was looking for.
I spent the last month wondering why my alarm was not sounding forgetting I had recently starting the headphone jack.
I think turning the Chumby speaker on with the alarm should be a built in feature rather than a work around like your solution.
But great job will have to try it out!

Re: Is there a pre_alarm_action ?

Glad it's of use. But given the bugs that have recently been introduced into cron by the latest firmware I had to modify one script slightly to workaround.

I changed speakeroncron to :

#!/bin/sh

if [ "/psp/alarms" -nt "/psp/crontabs/root" ] ; then
    grep -v '/psp/speakeronalm' /psp/crontabs/root >/psp/cleanrootcrontab
    cat /psp/cleanrootcrontab | /psp/alarmparse >/psp/crontabs/root
    touch /psp/crontabs/cron.update
fi

You will also probably have to

chown root:root /psp/crontabs/root

as the new update has installed the incorrect permissions for this file.

Here is the discussion of the cron bugs introduced in the latest update.

http://forum.chumby.com/viewtopic.php?id=5673

From the discussion on this thread I could, I think, have made a simpler alteration,
cat /psp/cleanrootcrontab | /psp/alarmparse | crontab -c /psp/crontabs -
, but I've not tried this myself in the application. I'm hoping Chumby will fix cron. I know the above speakoncron works as is.

BTW this is for Chumby One, you will need to alter slightly for Chumby Classic.

Re: Is there a pre_alarm_action ?

nice. Thanks much. I added one line to skip alarms that are silent.
foreach (@alarmlines){
+    if($_ =~ /type=\"none\"/) { next; }