Utility to Schedule Group Enable/Disable - Block Groups at Specific Times

General Customizing Pi-hole
1

Utility to Schedule Group Enable/Disable - Block Groups at Specific Times

Pi-hole makes it easy to configure custom groups, but doesn’t allow users to schedule when those groups are active.

Pi-hole isn’t parental control application, but scheduling is useful for parents wishing to block social media, streaming, or gaming domains during homework hours or overnight.

Some may also find it useful to schedule different lists for on or off work hours, etc.

A Solution Path

Luckily, there’s a fairly simple solution if you’re willing to spend a few minutes with the command line interface.

Pi-hole stores data, including the “enable” or “disable” status of groups, in a database which currently can be edited with sqlite3.

The idea is:

  • You make a group in Pi-Hole web UI (e.g. "bedtime”)

  • Add Clients to that group in the web UI (e.g. kid’s laptop)

  • Add specific blocklists or domains in the web UI (e.g. add “^.\*$” as a regex filter in domains to block all traffic from resolving DNS)

  • Configure something on your machine to:

    • Automatically enable the group when you want (e.g. every day at 9 p.m.)

    • Automatically disable the group when you want (e.g. every day at 8 a.m.)

systemd-driven approach

Skwerl23 wrote a great tutorial for how to update the db with cron, which does the job, but has some limitations. Specifically, I was looking for an easier way to manage everything, without having to copy commands and write cron syntax every time.

I also wanted an easy way to see what timers are active and when they will trigger next.

Instead of cron, I approached the same db update with systemd service and timer template units.

The advantage of service and timers units:

  • Individual timers can be enabled/disabled and tested easily

  • Logs go to journalctl with per-unit log history (e.g. to see failed timers)

  • systemctl can show last run, next run, exit status easily

  • If the system is off during a schedule time, in can run immediately on the next boot (if Persistent=true)

Where to find it / how to use it

Here’s the project on GitHub with install instructions—you can install with one copy/paste into your command line listed in the ReadMe.

Once installed, users can use the configure command to launch their default editor and enter their groups and schedules into a single configuration file:

sudo pihole-toggle configure

After entering timers in the .conf file, running the sync command will automatically add and enable new timers and/or disable and remove timers that were deleted:

sudo pihole-toggle sync

The status command allows you to see all timers scheduled, the last time they ran, and the next time they will run.

pihole-toggle status

You can disable and remove all timers at any time by running the purge command.

pihole-toggle purge

I’m new to working with shell, so more experienced users, I’m happy to take your recommendations. My goals are learning and sharing in case this utility can help someone else.

1 Like
2

Note:

I didn't read all your code, but I noticed you are installing sqlite3 on the OS, as a dependency.
You don't need to install it because Pi-hole already has an embedded sqlite3.

Try replacing /usr/bin/sqlite3 in your commands with pihole-FTL sqlite3.

1 Like
3

Brilliant. Thank you for your time. I've removed the dependency from install, updated the scripts to use embedded sqlite3, and pushed the changes.

1 Like
4

This is a really clean and practical approach. Using systemd timers instead of cron makes a lot of sense, especially for something like scheduled group toggling where visibility and control matter. Being able to check status with systemctl, review logs in journalctl, and benefit from Persistent=true is a big usability win compared to raw cron entries.

I also like that you centralized everything into a single config file and wrapped it with simple commands like configure, sync, status, and purge. That lowers the barrier a lot for users who aren’t comfortable editing crontabs or writing SQL manually.

For someone new to shell scripting, this is solid work. One small suggestion might be adding input validation to the config parser to prevent malformed schedules from creating broken timers. Overall though, it’s a thoughtful and user-friendly solution that fills a real gap in Pi-hole.

5

Thanks so much for the time you spent reviewing the code, the kind words, and for the great idea for input validation. That will be next up!

Thanks especially for saying this lowers the barrier to entry. One of my goals of the project was to make this relatively easy to use for people who don't have a lot of time to learn SQL, cron syntax or shell scripting.

IMHO, the hardest part currently is the config input that requires strict formatting and specific calendar syntax. Validation there is an obvious improvement—I appreciate you pointing it out!

1 Like