Re the previous answer: the DS18B20 is a digital sensor - it takes the reading locally, stores it locally and though a separate read process digitally transmits the result (usually 12bit resolution) on the OneWire bus to which it is attached. The transmission of the reading to the host is not voltage sensitive (in that a different voltage will represent a different temperature value). However, voltage problems can corrupt the signal.
The -127C reading is actually a return from the OneWire bus code of 0xFF (ie 1111 1111) which is an error from the bus that it failed to receive a reading from the DS18B20. As a decimal signed integer that is -127.
Re anomalous readings (that appear digitally valid), I don't have an exact root cause answer but have experienced and solved similar.
In my case a particular sensor on a longish cable run (approx 20m) both when sharing a bus with others and on its own occasionally returns 80c (whereas the usual range is 15-25 for water temperature in a header tank).
I at first though it a digital corruption via mismatched signal reflections especially when mixed with shorter runs, however this should have been detected in the CRC and on isolation to a single bus the problem continued anyway.
Interestingly I have narrowed the problem to rapid thermal changes in the wire temperature (dropping from 20C to 10C over an hour or so), even while the DS remained very stable, immersed in 20K litres of water. I put this down to a slight change in conductivity on the voltage supply wire. (If it where signal wire related then again the CRC should catch it). This could well be a similar situation with your fan activation.
I have solved it in two ways electrically (though neither are 100% reliable) and one way in software.
Electrically, locating the pull up resistor close to the sensor (rather than at the bus termination) gives far more stable results generally in terms of bus errors (avoiding the -127s). The other electrical solution was to increase the supply voltage to compensate for the longish run to 5.2v and also drop the bus end resistor down to 2.2K. This pretty much got rid of the odd 80C reading, but not entirely.
In software, I accepted that unreliability was to be dealt with and implemented some sanity checking whereby if a result came in that was clearly wrong, then my system (polling every 2 minutes), simply repeated the previous valid result along with a warning.
My software sanity checks include: basic range checking of possible valid values (> -5 < 70) which applies to all my sensors; and a check for out-of-bounds delta change since the last valid result using a tunable time window (in case a series of invalid results continue past the window - in which case I accept the next valid range value as really valid). This may or may not be appropriate given the rapid changes your wind machine could trigger.
Another possibly not to dismiss is that perhaps you just have a single dodgy sensor.
.
