in reply to Re: Continuous or timed?
in thread Continuous or timed?

For #3, I wouldn't fool with Chron - just calculate number of seconds until next run and sleep() that long. That way if the system restarts, your process runs immediately and calculates the time until the next run time. That way there is no Chron file involved.

You are reinventing the wheel here. cron does exactly that. Calculate the sleep time until the next job needs to run, and sleep. If it wakes up early, that almost certainly has happened because someone submitted changes to the job list (i.e. running crontab).

Oh, and by the way, don't blindly run after sleep returns. sleep may be interrupted, so your process may have slept for a much shorter time than expected.

There might be some startup race conditions after a power failure. I'm not sure about the Pi config options are when the Pi cannot get current date/time from the internet? Maybe Pi is "ready" before the router to the internet?

That could be detected in startup scripts. Linux starts at unix time 0, i.e. 1970-01-01 00:00:00 UTC. So if the application detects a system time years before it was written (if (year < 2020) would be sane), it should assume a fresh boot and just wait for ntpd to do its job. Also, there are RTC chips for the Raspi, so that it adjusts the system clock very early in the boot process, before cron and other services run.

Think about a status LED - perhaps blinking means good - stuck on(or off) means bad.

Good idea, easy to implement. Add a cheap red LED (based on GaAs, voltage drop about 1.6 V) and a resistor to a GPIO pin. GPIO voltage level is about 3.3 V, LED current should be around 5 mA, so the resistor value is R = U / I = (3.3 V - 1.6 V) / 5 mA = 340 Ohm. Close standard values are 330 Ohm and 390 Ohm. Heat dissapation is P = U * I = 1.7 V * 5 mA = 8.5 mW for 5 mA. Any cheap resistor can easily heat away at least 125 mW. LED should be connected between GPIO pin and GND, with the resistor in series wih the LED. If the LED is too bright, decrease the current by increasing the resistor value. To get 1 mA, you need 1.7 kOhm, close standard value is 1.8 kOhm. Only very few LEDs are visible at less than 1 mA, so that's about the upper limit for the resistor. The Raspi can't sink or source significantly more than 15 mA, and has an additional limit of about 50 mA for the sum of all GPIO pins, so you don't want more that 5 to 10 mA for the LED, so the resistor should not be less than 170 Ohm.

Alexander

--
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)

Replies are listed 'Best First'.
Re^3: Continuous or timed?
by Marshall (Canon) on Dec 15, 2020 at 20:27 UTC
    Oh, and by the way, don't blindly run after sleep returns. sleep may be interrupted, so your process may have slept for a much shorter time than expected.

    Yes, indeed! I had forgotten about that. Sleep() returns the value of unslept seconds. So if its not zero, just sleep again for that return value. Sleep is often implemented with SIGALRM so that's another potential issue.

    Good description of power/brightness for LED's. As another comment, you can get what are called "resistor LED's". In that case, the resistor is built into the LED. Probably the most common value will be 1K Ohms which is a good choice for 5V. For 3.3V perhaps, 470 or 560 Ohms would be fine. The brightness can also be adjusted by pulsing the LED. I forget exact waveforms that I've used in the past for "ON", but as a starting point, probably a square wave with 20-30ms/on-off is about as bright as 100%. Play with different duty cycles for "on" and see what happens... Current and duty cycle of that current vs perceived brightness is a non-linear function.

    BTW, I like blinking as the "good state" -> that means that the processor is running and is able to turn the LED on/off. Also, different cadences of the LED can be used to indicate error conditions. Human brains are excellent at pattern recognition. My router has a particular flashing light sequence that I recognize as "normal" without really thinking about what each individual light means. If the LED is stuck either at ON or OFF, I would surmise that the processor is "dead". If you just have a single LED, perhaps Long blip, followed by short blip means Internet connection bad, etc.

[reply]
Re^3: Continuous or timed?
by stevieb (Canon) on Dec 13, 2020 at 16:25 UTC
    "Good idea, easy to implement. Add a cheap red LED (based on GaAs, voltage drop about 1.6 V) and a resistor to a GPIO pin."

    No need even for that on a Pi. In my RPi::WiringPi, I use a couple of command line commands to manipulate the power and disk I/O LEDs so that a user can identify by eye which Pi is the one currently being worked on (this was a user request I implemented). Since this is a Perl forum, I've left the CLI commands within the actual code itself. Essentially, the identify routine turns the power LED off completely, and turns the disk IO LED on solid. Using these LEDs to set them to non-standard configuration could easily indicate a problem with custom software.

    sub io_led {
    my ($self, $tweak) = @_;
 
    if ($tweak){
        # stop disk activity from operating the green LED
        `echo none | sudo tee /sys/class/leds/led0/trigger`;
        # turn on the green LED full-time
        `echo 1 | sudo tee /sys/class/leds/led0/brightness`;
    }
    else {
        # turn off the green LED from being on full-time
        `echo 0 | sudo tee /sys/class/leds/led0/brightness`;
        # start disk activity operating the green LED
        `echo mmc0 | sudo tee /sys/class/leds/led0/trigger`;
    }
}
sub pwr_led {
    my ($self, $tweak) = @_;
 
    if ($tweak){
        # turn off the red power LED
        `echo 0 | sudo tee /sys/class/leds/led1/brightness`;
    }
    else {
        # restore default power LED operation
        `echo input | sudo tee /sys/class/leds/led1/trigger`;
    }
}

    [download]
[reply]
[d/l]

In Section Seekers of Perl Wisdom