If you're going to use a controller of some sort then some kind of timer in the programming might be useful to help determine needs. I'd think you'd have to calibrate based on temp rise time and perhaps factor ambient temp. As in, pipes in the summer/winter might have different rise/fall times, perhaps also by time of day.
Whatever you do make SURE the method you use to control power to the fan has an override at the switch. You do not want to set up some embedded gizmo that applies power directly to a device without having a manually operable interrupt in a place where it would be OBVIOUS to anyone that might be servicing it. You don't want someone coming along later thinking just turning off the wall switch would be enough...
Likewise, be sure to factor power loss/interruptions. Resetting clocks on a bunch of stuff can be tedious if/when power to them cycle off/on. Having just had to deal with that for the steam shower, the floor heat, the towel warmer, the microwave, coffee maker and a handful of clocks...
This is where the 'internet of things' that gets bandied about stands to get annoying tedious... Don't get me wrong, I do like the idea of monitoring/controlling devices, especially if/when standards (which won't be) are developed.
The same thing could be said for the temperature detection logic. Presumably you'd have a baseline temp and a rise time. If your device came on and the temp was suddenly above the baseline, what should it do? There your logic would need to know the max temp and factor the fall time. Those would be values that'd have to be kept in some sort of non-volatile storage. They could be part of the programming code but I'd think it would be more effective to have them adjustable values. For a PC-like environment with an easy programming interface (aka, network connected) that'd be relatively easy. But for something that had to be 'manually' loaded via a programming cable, not so much...
I'm reminded of the 'boiled frog' tale. Though while untrue, this is one of those areas where programming can fail to achieve desired results when ineffective logic is applied. It's all about parameters and their times. How cold was it, for how long, how quickly did it heat up, how long did it stay that way, how quickly did it cool, etc. So it's not just about 'is the pipe warm or not'...