Schedule driven GPIO events

I want to use GPIO outputs to drive an IOT Power Strip.

My question is about triggering scheduled events.
For instance I want to issue a GPIO command to turn a pin on and off on a schedule.

So I could use cron but would like to avoid system utilities.
Looking around I found sysutils/fcron and sysutils/anacron. Both can run commands on a schedule.
anacron seems to use daily jobs. I need minute precision.

Another option I have considered is deskutils/calcurse.
I like the approach of scheduling by calendar. It can run commands too.

Can you recommend any programs I may have missed.

I need to schedule a command like gpioctl to run 4 times a day.
 
Even, if I don't exactly understand, what is wrong with a cronjob -- I got a lot of it in my crontabs --, the most effective solution would be, to write your own daemon (see here: https://forums.freebsd.org/threads/polling-a-sysctl-value.63501), wich you would modify to do a sleep(3) for the required amount of seconds (21600 s), and then calls the respective gpio(3) instruction.
 
Here is a sample task I need to do. I have a Siemans PLC at work that is old and getting flaky.
It keeps bad time and cannot handle DST time changes. I have to mess with it too much.

Surly I could find some timer circuit for less $ but I like to have an SSH window into the controller.
Plus I could feed cameras through it for auxiliary function.

This PLC controls a solenoid for Air Powered Horn that sounds at the beginning and end of the workday.
I would like to replace it with something else. Like a old Pi or anything with FreeBSD GPIO.

So I need to accurately trigger a solenoid 4 times a day.

I was looking at this program with interest. deskutils/remind/
This is overkill but I like the flexibility. Especially with complex scheduling.
 
the most effective solution would be, to write your own daemon
Thank You for mentioning that. In the end that is going to be the best solution.
But I think I want a daemon for each pin. A GPIO service for each pin. Totally independent.
Then I could make one GPIO pin service dependent on the state of another.

I really see the need the for an event driven GPIO program.
Cron is not preferable to me.

Anybody ever hear of Light-O-Rama?
They make Christmas Light Controllers. Mega tree. RS485 connects to the various junction boxes.
It is bad ass. Why is there no software for more 'General" I/O events?
 
I am looking at the deskutils/calcurse codebase.
If I changed 'Appointments' into 'Events' it might fit the bill.
Not Light-O-Rama but basic scheduled on off events.
Lots of un-needed features though..
 
But I think I want a daemon for each pin. A GPIO service for each pin. Totally independent.
Then I could make one GPIO pin service dependent on the state of another.
Take a look at the way moused and some other things work with hot pluggable devices.
You write a script once, then you have a symlink like moused.ums0 that the script looks at it's name to figure out what "port" (pin) it needs to work on.
 
With regards to calcurses, The notfcation system is not very robust. So that is a bust.
This guy reverted to cron.

So I started playing with dialog --calendar but I really don't have the skills to build my pipe dream.
Was thinking of hooking the fcron scheduler into a curses calendar interface. Similar to calcurses.
I was hoping to adopt some existing code but that is looking futile.
 
Well the best deals require patience.
I had patience as the seller took 10 days to ship my item.
He only shipped me one but I ordered 5.
It has been that kind of week.

Good news is I have the one IOT Relay working on my APU2.
Had to change type from Open Drain to Push Pull.
So finally I have outlet control.

Now its time to test out fcron. I will use a clock radio for testing.
 
If you can hook up your light controller to a FreeBSD machine and control that using command line first, there's theoretically no limit to how fancy you can get afterwards. But first things first, get the controller working under FreeBSD.
 
I don't have a Light-O-Rama controller. I just marvel at the off the shelf approach. Nothing new there.
RS485 daisychained controllers. Outlet boxes and some nice orchestration software.
Just application of newer electronics like the triacs for RGB LED's for spectacular effect.

I have been studying my needs and messing with cron/fcron.
It seems to me what we are missing in FreeBSD is a gpiod. On Linux this is what is used.
I looked at the Linux gpiod code and the differences are too great to port.
Scheduling is handled with the daemon as well as monitoring.
There is a OpenBSD GPIO daemon implementation that is closer to our GPIO subsystem.
 
fcron runs on seconds precision, and does cron and anacron.
So how are you doing this? f/a/cron all use the same time/date format?
Is it like this? Running a script?

I don't see second precision here:
Code:
root@APU2:~ # fcrondyn
fcrondyn> ls
ID   |USER     |SCHEDULE        |CMD
3    |root     |2021-06-27 12:11|/usr/sbin/gpioctl 0 1
2    |root     |2021-06-27 12:12|/usr/sbin/gpioctl 0 0
 
Sounds more like a Pi application - it may be better to have a dedicated device to run the light show for a few hours. FreeBSD or Rasbian, proper command line control, and then you can get as fancy as you want.
 
FreeBSD's crontab(5) does seem to support seconds in some capacity:
@every_second Run once a second.

fcron also has the ability to use seconds for repeats.

Neither of these seem to accommodate a start time/stop time in seconds like I want?
 
E.g, one line out of my fcrontab
Code:
@first(2000s)  1800s  /usr/home/x/Root/bin/snap_usr_home_increment  -u root
It runs first 2000s after starting and following regularly at 1800s time intervals.
Note, when you write 2000 instead of 2000s it will interprete it as 2000 minutes.
 
FreeBSD's crontab(5) does seem to support seconds in some capacity:
@every_second Run once a second.

fcron also has the ability to use seconds for repeats.

Neither of these seem to accommodate a start time/stop time in seconds like I want?
In which case, it might be easier to daisy-chain a couple scripts... write a script whose total run time is an hour, and has a PID file. Then your crontab has to check for completion of the script before starting it up all over again. It shouldn't take that many processor cycles to do the checking.
 
Back
Top