{I still have not studied mango's plug-in infrastructure, so I my terminology may be sub-optimal.}

OK, so pasting from above, let's get some data....

23.0 °C Dec 03 23:06
23.0 °C Dec 03 23:05
23.0 °C Dec 03 23:04
23.0 °C Dec 03 23:03
85.0 °C Dec 03 23:02
23.0 °C Dec 03 23:01
...

Let's first assume that at 23:02 there was a real temperature excursion to 100 Deg C, which was limited to 85 internally in the sensor, and reported as 85, the device's maximum value.

Assume that the mango source also had its maximum value limited to 85.

The data in the db would reflect 85 for 23:02, and this information would be correct, within the limits of the system.

In the context we could say that the temperature at that time was 85 degrees or above. Real and useful information.

Now let's assume instead that there was an error in the device or the driver at 23:02. This may have occurred due to low voltage on the line, or a bug, whatever, but we know that these 85 degree values are highly suspect.

In this case, putting the value 85 in the database would be misleading. We actually have no idea what the temperature was. If we were able, we should say so, by storing what I called an 'out-of-band' point. This could be a datapoint with a flag attached saying that an error occurred. Then this point would not be used for display, or for controlling air-con equipment. Or we simply ignore the point. That is better than taking action on data that we suspect is nonsense.

A practical approach in this case might be to configure the upper limit to 84 degrees, and configure/code the driver to ignore/or raise exceptions on sensor values of 85 degrees.

Finally, a comment on smoothing temperature values, or limiting the rate of change. My thought is that in this case this would make matters worse. First of all it's hard to know the excursion rates that are normal, and to express those values in a general way. It's hard to process the data, and we need to query the last n values each time a new value comes in. IMHO, for this sensor, with its specific behavior of sending 85 out-of-the-blue, one should simply treat it as a device that reads to 84.xx degrees, and treat 85 degrees as bad data.

Yes, it's an ugly situation.

limiting misses the point, really.

In the examples higher up the thread, the 85 value should not really be limited to some value, and presented as if a real value, but treated as 'point could not be read' and discarded, or shown out-of-band of the normal temp curve.

I was doing some work implementing a 1-wire driver on an XMOS device recently, and saw 85degC value occasionally. This was due to a value read inside the driver being out of range and being limited to 85.

I forget the details, but I thought at the time that an exception should have been raised and the whole packet discarded.

Probably the best approach is to detect 85 and flag it as an error for a re-read, but I don't know your plug-in architecture yet, to be more concrete.