timedclient-qt5 usage - need some help with repeat option.

asked 2016-10-23 17:12:17 +0200

Schturman gravatar image

Hi to all.
I think about switch from using systemd.timer to timedclient-qt5 because of deep sleep mode when timer stop to work. I use this command as example for testing (from this post):

timedclient-qt5 -a'whenDue;runCommand=/home/nemo/.scripts/rsync.sh@nemo' -r'hour=13;minute=30;everyDayOfWeek;everyDayOfMonth;everyMonth' -e'APPLICATION=Android_Backup;TITLE=Android_Backup'

And it work very good for my needs in SPECIFIC time. But in some app I don't need to use specific time like in this example, I need repeat option like can be used in timer. For example to start my script every 3 minutes or every 6 hours. Here I'm stuck...
The timedclient-qt5 --help not explain this or at least I don't understand it from --help.
If it possible at all, can someone explain me how to change this command to start my script for ex. to run it every 6 hours or minutes ?
I know that I can change "hour=13;" to all hours to run it every hour, like this:

hour=0;hour=1;hour=2;hour=3;hour=4;hour=5;hour=6;hour=7;

etc... until 23, all is good here, but if I want to run my script every 10 hours ? I can change it like

hour=0;hour=10;hour=20;

But between 20:00 and 00:00 (next day) it less than 10 hours, that mean it incorrect...
Again if someone know and if it possible to use repeat option in timedclient-qt5, please explain it here.
Thanks.

edit retag flag offensive close delete

Comments

what if your script schedules/submits the next job/task?

A.Maretzek ( 2016-10-24 01:13:20 +0200 )edit

Yes it possible... I already tested it by using "ticker" option like in this example:

timedclient-qt5 -a'whenDue;runCommand=/usr/share/openrepos-autoambience2/test.sh@nemo' -e'APPLICATION=Autoambience2;TITLE=Autoambience2_test;ticker=120'

Like you can see it not use hour, minute, date etc, it just use 120 seconds. It start my script after 2 min and this task automatically deleted from timedclient-qt5. But If I will add the same command also inside my script as a last command, it will create something like a loop, every time with new task.
I don't know if this right/correct way to do this... Also one strange thing that I noticed, when task deleted automatically or I delete it manually, the same cookie number not used anymore. Every time when I create new task after one deleted, I always get new cookie number... I don't understand if it still collected somewhere and in some point it can cause some problem or it normal behavior...
This is a reason that I don't really like this way for "repeat" option...

Schturman ( 2016-10-24 01:41:52 +0200 )edit

@schturman: I still recall relatively well how maemo alarmd worked. Assuming timed works "similarly enough" in this context ...

That is basically how n900 calendar alarms worked. The calendar app maintained a separate database of alarms and used alarmd just for scheduling the next one in the line. When that alarm got deleted (handled separately from triggering/showing alarm dialog), a "program the next alarm" helper binary was executed to schedule the next wakeup. Passing the cookie to the helper and/or querying with suitable attributes can and needs be used to make sure no excess alarms are left in the queue. [And in case of calendar alarms where time of day matters, also tz changes needed to be taken care of since this type of triggering does not make it possible for alarmd to handle it].

About the cookies: After alarms are queued, they are semi-immutable i.e. the alarm daemon can modify the alarm state etc, but changing alarm properties via dbus is handled as a "delete old + create new" type of transaction. This implicitly makes sure that things like editing an alarm that is already triggered and shown by the system ui are handled correctly (the alarm dialog gets removed etc).

spiiroin ( 2016-10-24 10:59:33 +0200 )edit