Wildcards for time scheduler

[jshuggins]

Right now I have the following scheduler set for some YouLoop antenna testing...

    "scheduler": {
        "type": "static",
        "schedule": {
            "1800-1810": "160m",
            "1810-1820": "80m",
            "1820-1830": "40m",
            "1830-1840": "30m",
            "1840-1850": "20m",
            "1850-1900": "17m",
            "1900-1910": "160m",
            "1910-1920": "80m",
            "1920-1930": "40m",
            "1930-1940": "30m",
            "1940-1950": "20m",
            "1950-2000": "17m",
        },
    },

For a given test session, this seems to work very well, pskreporter properly reveals spots showing up in the correct band vs. time.

Is there a possibility of using some sort of wild card that allows for this...

    "scheduler": {
        "type": "static",
        "schedule": {
            "**00-**09": "160m",
            "**10-**19": "80m",
            "**20-**29": "40m",
            "**30-**39": "30m",
            "**40-**49": "20m",
            "**50-**59": "17m",
        },
    },

...so I don't have to define the entire 24 hour block if I want this hourly band-pattern to run 24/7?

Consider this merely a feature request.

Thanks.

[jketterl]

I'm kind of torn about this. I don't like the idea of wildcards, the logic behind may very well become pretty ugly.

When this idea first came up I was thinking more something like this:

"scheduler":{
    "type":"tbd",
    "schedule": {
        "0000-0000": {
            "bands": ["160m", "80m", "40m", "30m", "20m", "17m"],
            "interval": 600
        }
    }
}

(600 would be 10 minutes, should match your example)

[D0han]

Hm.. What about using crontab-style schedule?
Quick search gives some links to ready to use code like https://github.com/josiahcarlson/parse-crontab

[jketterl]

i"m not a big fan of cron, nor it's syntax. i'm not a big fan of external dependencies, either.

you need to think ahead: how would you implement a frontend for this?

[jshuggins]

I'm kind of torn about this. I don't like the idea of wildcards, the logic behind may very well become pretty ugly.

When this idea first came up I was thinking more something like this:

"scheduler":{
    "type":"tbd",
    "schedule": {
        "0000-0000": {
            "bands": ["160m", "80m", "40m", "30m", "20m", "17m"],
            "interval": 600
        }
    }
}

(600 would be 10 minutes, should match your example)

This would accomplish my task perfectly. I like it.

[D0han]

i"m not a big fan of cron, nor it's syntax.

While i agree its not the prettiest, it is flexible, widely used and known.

i'm not a big fan of external dependencies, either.

Me neither, but we cannot build every wheel from scratch. We already need quite a few different projects for reasonable feature set, and this one is python only - no compiling needed.

you need to think ahead: how would you implement a frontend for this?

So far what i saw was just text area with validation. Yes, its crude. But why not put 2 ways to configure it in GUI? Basic with some dropdowns/whatever and advanced with text field giving full flexibility.

[jketterl]

i"m not a big fan of cron, nor it's syntax.

While i agree its not the prettiest, it is flexible, widely used and known.

It is common knowledge across unix sysadmin folks. While I would appreciate it if there was more of those around, they are still a minority, and certainly not everyone using OpenWebRX would know it.

i'm not a big fan of external dependencies, either.

Me neither, but we cannot build every wheel from scratch. We already need quite a few different projects for reasonable feature set, and this one is python only - no compiling needed.

No, but every external dependency needs to be taken care of in the form of packages, installations routines and stuff. Hence I'd rather avoid them.

you need to think ahead: how would you implement a frontend for this?

So far what i saw was just text area with validation. Yes, its crude. But why not put 2 ways to configure it in GUI? Basic with some dropdowns/whatever and advanced with text field giving full flexibility.

So far, nothing has been implemented, but I'd prefer a frontend that doesn't have an "advanced" mode, especially if it requires a special skillset.

One more thing: cron scheduler is instantaneous in execution, i.e. it fires a command at given times. The selection of bands at hand here is rather a range of time, that's also why the original scheduler has the "xxxx-yyyy" syntax. I'm not saying it's impossible to switch, but the difference in approach certainly opens up its own set of edge cases.

[D0han]

No, but every external dependency needs to be taken care of in the form of packages, installations routines and stuff. Hence I'd rather avoid them.

As this is published python package, there is no need for any routines and stuff. It will be handled by pythons packet manager when installing openwebrx package.

One more thing: cron scheduler is instantaneous in execution, i.e. it fires a command at given times. The selection of bands at hand here is rather a range of time, that's also why the original scheduler has the "xxxx-yyyy" syntax. I'm not saying it's impossible to switch, but the difference in approach certainly opens up its own set of edge cases.

IMO current approach with ranges introduces unnecessary verbosity and places for mistakes.

[jketterl]

As this is published python package, there is no need for any routines and stuff. It will be handled by pythons packet manager when installing openwebrx package.

There's a total of four installations methods, none of them are based on the python package manager (neither pip nor easy_install).

IMO current approach with ranges introduces unnecessary verbosity and places for mistakes.

That's just one way to see it. It certainly makes it easier to pick the scheduling back up once the user has disconnected.

[cjritola]

@jketterl 's idea looks best to me: As much as I like CRON approach, it introduces the possibility to create overlapping scheduling conflicts from within the same profile. Same applies to wildcards. The cyclical scheduling type keeps errors from slipping in.