Hi Clarkson,
Thanks for letting me know about your use of the script! After I dropped it into the forum, there was nary a ripple of response, so I thought nobody was using it. My EX has been running well and one time the script ran for > 90 days without a glitch until I needed to reboot the controlling iMac. Fan speed index never exceeded 3.
I tried redirecting stdio/err back when I first wrote it, but failed; it’s been a long time since I did much serious shell-scripting or I’d probably have remembered the need to flush. Thanks for the sys.stdout.flush() hint! I’ll add it to my version. I also like the nohup, may keep the script running when the controlling pty goes away (i.e. when my iMac crashes, or I quit the Terminal app or close its window).
At short intervals, yes, I agree hysteresis is a good idea. That’s why furnace and air conditioner systems typically use ±1deg, IIUC. But at the 600-sec intervals we’re using I find that for my needs it’s fine without. The speed change seems to require little CPU or other resource, so aside from a bit of background noise-level change, a simple, symmetric, non-hysteresis ramp is adequate for my use. Of course, it’s Python, so you can change it for your own use case, which is the beauty of Python over compiled languages like C or C++.
Note - I’ve been considering dropping down to 300 sec or even less. So far, 600 sec seems just fine–max 1-2 deg excursions observed in that interval–but if something goes wrong in the h/w (e.g. a book falls on it and partly blocks the top vent), and it starts heating quickly, a shorter interval may catch the heat-up sooner and protect the equipment/data from consequential damage. There’s no safety net.
As for cron, there are probably a number of folks who’d like that flexibility, especially if it auto-restarts after a reboot of the EX. Maybe a crontab that checks whether the looping implementation is currently running and kicks it off if not would also be a good thing for a lot of users; I don’t think there’s much to gain in resource use with cron, as time.sleep() seems to be implemented very cheaply, with CPU usage being minuscule, and the fan I/O operations don’t seem to put much of a load on the cpu, and should not interfere with disk or LAN i/o. I haven’t really tested those assumptions though, just done some casual observations.
Please post your changed version in case anyone else wants to use it. If you do a single-stepping cron version, please give the new version a new name.
Many thanks