Scheduled LED control not working

[jet45]

Hello,

I'm running Asuswrt-Merlin 3.0.0.4.260.21 on my Asus RT-N66U. I'm having trouble getting the Scheduled LED control to work. Per the Wiki I created three scripts "services-start", "ledsoff.sh","ledson.sh" and made them executable. Lastly I placed them in /jffs/scripts/ directory.

I then rebooted my router and executed this command "cru l" in putty once the router came back up to make sure the jobs are setup.

25 0 bin cifs1 cifs2 dev etc home jffs lib mmc mnt opt proc rom root sbin sys tmp usr var www bin cifs1 cifs2 dev etc home jffs lib mmc mnt opt proc rom root sbin sys tmp usr var www bin cifs1 cifs2 dev etc home jffs lib mmc mnt opt proc rom root sbin sys tmp usr var www /jffs/scripts/ledsoff.sh #lightsoff#
0 8 bin cifs1 cifs2 dev etc home jffs lib mmc mnt opt proc rom root sbin sys tmp usr var www bin cifs1 cifs2 dev etc home jffs lib mmc mnt opt proc rom root sbin sys tmp usr var www bin cifs1 cifs2 dev etc home jffs lib mmc mnt opt proc rom root sbin sys tmp usr var www /jffs/scripts/ledson.sh #lightson#

But unfortunately the leds do not shutoff at the time I set. I looked at my logs and I noticed this.

Dec 7 14:49:01 crond[505]: user admin: parse error at bin
Dec 7 14:49:01 crond[505]: user admin: parse error at cifs1
Dec 7 14:49:01 crond[505]: user admin: parse error at cifs2
Dec 7 14:49:01 crond[505]: user admin: parse error at bin
Dec 7 14:49:01 crond[505]: user admin: parse error at cifs1
Dec 7 14:49:01 crond[505]: user admin: parse error at cifs2

Not sure if that has anything to do with my jobs not running. Turning the leds off via gui works fine, I just can't get the schedule jobs to work.

 

[RMerlin]

Your cru commands are incorrectly processed. Try putting " " around the arguments to ensure the * doesn't get expanded by the shell.

 

[jet45]

This is what I have . Do you mean I need to put the " " around the time?

#!/bin/sh
cru a lightsoff 25 0 * * * "/jffs/scripts/ledsoff.sh"
cru a lightson 0 8 * * * "/jffs/scripts/ledson.sh"

 

[RMerlin]

This is what I have . Do you mean I need to put the " " around the time?

Like this:

#!/bin/sh
cru a lightsoff "25 0 * * * /jffs/scripts/ledsoff.sh"
cru a lightson "0 8 * * * /jffs/scripts/ledson.sh"

I'll update the Wiki.

 

[jet45]

Thanks Merlin, its working perfectly now...this is one of my favorite features from your firware, love it...thank you.. Now I could remove the limo tint from the router.

I have another question, if you dont mind, its unrelated to this. I have my traffic history saved every hour to my usb drive...how would I import my saved history back after a reboot?

 

[RMerlin]

Thanks Merlin, its working perfectly now...this is one of my favorite features from your firware, love it...thank you.. Now I could remove the limo tint from the router.

I have another question, if you dont mind, its unrelated to this. I have my traffic history saved every hour to my usb drive...how would I import my saved history back after a reboot?

You don't need to import it. It gets automatically loaded at boot time, provided you correctly configured the save path. Check syslog for any error message from rstats after reboot to confirm that your path is correct.

Note that the path must end with a "/" to ensure it gets treated as a directory.

 

[jet45]

This is what I have under save history location.

/tmp/mnt/sda1/traffic_history/

When I ssh to that location I do see a file named "tomato_rstats_50465d6d1238.gz". That means it is saving to that location but on boot its not importing it. I've searched my log for "rstats" errors but didnt see any.

Update: Ok, I messed around with it a little more and when I view the "Daily" view I do see past days history. The view I'm having issues (maybe its not an issue) with is the 24hrs view. When I reboot, the 24hrs graph does not display traffic history piror to the reboot.

 

[RMerlin]

It's possible that the 24-hours view might only rely on live data, not on historical data. I never looked at the details of how that one worked.

 

[jet45]

ok, cool. I just wanted to make sure I wasnt doing anything wrong.

 

[RMerlin]

Yeah, I haven't looked at the details on how the data gets stored, but I suspect that the database only contains the daily traffic, not the hourly traffic - otherwise it might make the database quite unmanageable after a few weeks of historical data.

 

[MarioCaires]

I have a small question regarding this note on Wiki:

"Note however that this will cause additional wear on your flash, and might slightly shorten its life, as the flash RAM has a limited possible amount of write cycles."

Is it just related to the "nvram commit", or to the entire script?