Can we resurrect MAX31865 fault tolerance PR #4164?

The above PR has been stale for about a year due to what I understand is Xorlev’s life commitments (real priorities). It seems to me that a large number of users (pretty much everyone using MAX31865) can benefit from this feature.

Would anyone be interested in resurrecting this PR so that it can be merged? I think the outstanding “cleanup” is rather minor in nature. I would make an attempt at it myself, but I can pretty much guarantee that I would turn it into dog’s breakfast. I know virtually nothing about Python, even though I understand what the proposed changes are doing at a high level.

Well, there does not seem to be much excitement about this, so here is my attempt at turning this into dog’s breakfast:

I think I addressed all points that Kevin and Xorlev discussed, but once again - I know nothing about Python. Is anyone interested and able to conduct a sanity check & review? The modified code appears to work fine in my test setup.

As a separate note, I tested the above code by momentarily shorting the RTD input to induce faults. While doing this, I noticed a rather unexpected behaviour - at times Klipper would briefly register seemingly valid spikes in temperature. I therefore added experimental feature to handle excessive rate of change of temperature received from MAX31865. This should be capable of handling certain intermittent and/or in-range failures that the MAX31865 internal diagnostics may not catch, such as those associated with wiring issues or electromagnetic interference. The primary goal here is to prevent these from being fed into the PID cntroller. I have not pushed these changes into my repository yet, but would be happy to do so if there is interest…

If anyone is interested in reviewing and/or testing the excessive rate of change handling branch, it is located here:

Note that it includes all of the other changes to Xorlev’s branch that I referenced before.

For the sake of completeness and traceability, I now created a PR: