NAS326 - Set wakealarm at shutdown fails - on reboot fine

Fusel
Fusel Posts: 6  Freshman Member
edited March 2019 in Personal Cloud Storage
I want to start my NAS every day at 08:00.
When i set the wakealarm for rtc on reboot it works fine.
I use the script below to set wakealarm
START_TIME="08:00"
START_TIME=$(date -d "$(date "+%Y-%m-%d") $START_TIME:00" "+%s")

sh -c "echo 0 > /sys/class/rtc/rtc0/wakealarm"
sh -c "echo $START_TIME > /sys/class/rtc/rtc0/wakealarm"
On shutdown i check some parameters and sometimes i want to wakeup the NAS before 08:00.
When i use the script above to wakeup e.g. at 03:00, i set START_TIME to "03:00" and run it the same way like on reboot. But this doesn't work.
(I also prefer to set the next default start time at shutdown instead of reboot, but even this fails.)

On shutdown i tried to save the wakealarm file and it contains the right wakeup timestamp. But the NAS doesn't start.

Short: On reboot works, on shutdown doesn't.

Why?

#NAS_Mar_2019

All Replies

  • Mijzelf
    Mijzelf Posts: 2,600  Guru Member
    First Anniversary 10 Comments Friend Collector First Answer
    I think your script interferes with the firmware timed wakeup implementation. At reboot it's not necessary to set the rtc, so in that case your script has 'the last word', but at shutdown the firmware sneaks in and overwrites your action.

    Having said that, I have no idea how the firmware sneaks in. /etc/init.d/rc.shutdown doesn't seem to do anything significant in this respect, and AFAIK 'poweroff' and 'reboot' don't call any firmware scripts, just cause init to shutdown/reboot.

    Maybe you can disable the possibility of the firmware to access the rtc. Try to delete /sbin/i2cset. (Don't worry, it's in the initramfs, and will be back on reboot). A possible problem here is that /etc/init.d/rc.shutdown also calls i2cset. I 'think' to tell the MCU what to do on power loss.

    If that doesn't help, you can remove the rtc from the /sys/class/ tree. On my 520 that is done with
    <div>echo c2k-rtc >/sys/bus/platform/drivers/c2k-rtc/unbind</div><div></div>

    BTW, how do you know your scripts works at reboot? Just pull the plug?


  • Fusel
    Fusel Posts: 6  Freshman Member
    Thanks a lot for your answer!

    I forgot some details...
    I wanted to install Tvheadend, so i installed ffp using your package.
    On ffp you can use the /ffp/start/ directory to call scripts after start ffp - my autorun on reboot ;)
    In this script i set the wakeup (i rather prefer on shutdown instead) and add a script-call to /etc/init.d/rc.shutdown on first position.
    This script is running on shutdown/reboot (checking by buzzerc -t 2).

    Wakeup at defined time works well but setting different wakeup by using shutdown-call fails.
    Copy wakealarm to hdd using my shutdown-script shows the right time, but wake on initial wakeup and not on the wakeup defined in my shutdown-script.

    Setting wakeup at shutdown instead of reboot also fails.
    So i think you are right, "default" firmware overrides my changes with my previous setting.
    But only at shutdown/reboot.

    When i delete i2cset, wakealarm still runing?
    When i unbind rtc, wakealarm still possible?
  • Mijzelf
    Mijzelf Posts: 2,600  Guru Member
    First Anniversary 10 Comments Friend Collector First Answer
    When i delete i2cset, wakealarm still runing?
    When i unbind rtc, wakealarm still possible?
    The RTC is an independent chip which is connected to the SoC by the I2C bus. And it has a copper line to some logic which is able to powerup the bus. By progamming a wakeup time you actually tell the clock to pulse that copper line at a certain time.
    Deleting i2cset or unbinding the rtc has the same purpose, virtually cutting the i2c wire. If you do that after programming the chip, it should prevent the firmware (and you) from accessing the chip, but the chip itself is autonomous, and doesn't care.
    So yes, wakealarm should still occur.
    But if the firmware programs the rtc using another way (a direct link to libi2c) it doesn't help.

  • Fusel
    Fusel Posts: 6  Freshman Member
    I think it's an other problem.
    When i use
    ST=1553675595 // (e.g.)
    echo 0 > /sys/class/rtc/rtc0/wakealarm
    echo $ST > /sys/class/rtc/rtc0/wakealarm
    it work.

    When using
    ST=$(date -d '+ 2 minutes' +%s)
    echo 0 > /sys/class/rtc/rtc0/wakealarm
    echo $ST > /sys/class/rtc/rtc0/wakealarm
    
    it fails.

    Maybe an problem with the date-function and/or the result of it and not with the rtc himself
  • Mijzelf
    Mijzelf Posts: 2,600  Guru Member
    First Anniversary 10 Comments Friend Collector First Answer
    I suppose you have looked at the output of
    date -d '+ 2 minutes' +%s
    But did you also look at
    /bin/date -d '+ 2 minutes' +%s
    When using FFP, by default /ffp/bin/date is used, which is much more powerful than the firmware busybox applet.
    /etc/init.d/rc-shutdown runs in a different environment, and so it will default to /bin/date. I don't think you can use /ffp/bin/date here, as FFP is already cleaned up.

  • Fusel
    Fusel Posts: 6  Freshman Member
    edited March 2019
    </code>/bin/date -d '+ 2 minutes' +%s</pre>Fails - invalid date '+ 2 minutes'<br><br><pre class="CodeBlock"><code>ST=$(/bin/date +%s)
    
    ST=$(($ST + 180))
    works

Consumer Product Help Center