in reply to Continuous or timed?

it depends on how complex you want to end up.

regarding (1) you can restart a failed script by placing it in an infinite loop within a parent shell script if you are sure you debugged it enough so not to end up with an infinite pile of core-dumps. You can also have cron checking on it and respawn it if it disappears from the process list. You can also have cron sending it periodically a signal to dump diagnostics. In any event "perpetual" script or cron, it will have to sleep for a while in a loop. (1) makes it easier to change that sleep interval and also importantly, you can wake it up with a signal in order to respond to emergencies. So "continuously running" has a lot of merrits too. And it can too reschedule its wake up time with a Perl alarm (need example code?).

nit-picking: (3) is best with at.

With (1) you can expand your system to scan a queue of future actions from a database: open curtains at 8, close curtains at 5, water plants, etc. And execute if it's time. Each action is consumed unless it is a recurrent type of action (like the curtains). You can have many types of actions and your script would know how to handle each. The database/queue-of-actions can be updated independently and perhaps remotely or by voice. Also a speech synthesizer can read out the entries to the database of actions-to-do when instructed.

With (1) I would use a cron job to only make sure that the script is alive, or to periodically send it a signal to dump some diagnostics to email them to you. To have the script running even after a reboot, turn it into a service with systemctl - that buys you a free respawning within reason.

For your current spec I would go with (2): script is executed every 5 mins, if sunrise it opens, if sunset (calculate it) it closes. And it short-circuits if time of day is not interesting e.g. midnight. That's 12*24 times a day. Nothing really.

edit: basically you end up with a home-cron hehe

Replies are listed 'Best First'.
Re^2: Continuous or timed?
by Bod (Parson) on Dec 11, 2020 at 21:43 UTC

    and perhaps remotely or by voice

    As it happens...I've already received a feature request to have it connected to Alexa!

    if sunset (calculate it) it closes

    I'm pulling sunset from an API and an offset from the control file. Until it is actually in use I won't know if the curtains need to close at sunset or a little while before or after.

    For your current spec I would go with (2)

    That seems to be the consensus here and was my gut feeling. So 2 it shall be. I will be writing an updater to pull down a new script version from the server and SSH is enabled so I will be able to update the code remotely (not sure yet how to access the remote unit but that can be sorted).

[reply]

      FYI Linux, I hear (no experience), has support for blind users, e.g. connecting a braille display and its voice recognition (I also guess) must be adequate too. Making a voice interface to your project must be feasible.

      Options (1), (2) (I have no experience with microcontrollers) are valid depending on where you want to end up, i.e. how far to expand it. This can easily turn into a useful product with lots of capabilities unless re-inventing the wheel.

      SSH, i.e .accessing the remote unit (uncle's) from your home (re:not sure yet how to access the remote unit): hmm you need to sort out uncle's IP somehow as ISPs tend to arbitrarily change it for home users. The problem is solved if the unit (uncle) accesses your servers (the website you have) to download script+data updates once a day - i think this is what you are suggesting. But then you must make sure that this works perfectly as you will be away. You can always install a back-door, it seems now-a-days it's a requirement in order to be MI5-certified :) There are various techniques to enable incoming SSH with minimal risk. But the risk is there none-the-less.

[reply]
[d/l]

      The RPi has lots of memory. You could preload a year's(or 10 years) worth of sunrise sundown times and reduce the need for as many updates.

      James

      There's never enough time to do it right, but always enough time to do it over...

[reply]
        ... year's(or 10 years) worth of sunrise sundown times ...

        The Earth's rotation is slowly slowing and days are getting longer, but the year-to-year change over ten or twenty years is small. If one were only concerned with 1-2 minute resolution, one could store, say, 62 or 183 sunup/sundown pairs (the day-to-day variation is also small). Since sunup and sundown only happen during certain periods of the day, these times might be stored as one byte each. This is a very small table.

        Be that as it may, I'm not convinced one should be concerned with time as much as with light. What does it matter if, in midwinter, the curtains open at "sunup" when the sky is so overcast that it's like the middle of the night? A photocell/light level interface seems more important.

        I agree with stevieb: These considerations and others suggest a microcontroller solution. A system running Linux seems like overkill indeed.

        Give a man a fish:  <%-{-{-{-<

[reply]
[d/l]

        You could preload a year's(or 10 years) worth of sunrise sundown times and reduce the need for as many updates

        Yes indeed that could be done. It is not especially difficult to calculate them either.

        A side benefit of having the RPi call in is that the last state it put the curtains into can be seen on the web interface. Some family members are rather concerned that these curtains will never work correctly because of the poor experience we have had with the timer that is controlling them presently. Being able to see the time they last closed or opened might relieve some worry.

        There is also the issue of opening at 8:30am and not at sunrise. My blind uncle's guide dog enjoys barking loudly at the children going to the school opposite...by 8:30am most of the children are safely installed. It is quite possible that the curtains might be required to open earlier during school holidays so keeping it flexible seems sensible.

[reply]

In Section Seekers of Perl Wisdom