Are these direct readings from the sensor or are you using filtering?
The sensor will reset to 88C (ca. 190F) on power up, and this can happen when doing a long conversion and you lose power. The sensor appears on the bus, since it’s able to use parasitic power, but as soon as you try to read a temperature it will fall off the bus.
Since the onewire protocol includes crc checks, a high reading seems unlikely from a firmware problem. (I don’t know the dallas library - so not 100% sure it has crc checks implemented.)
Hi @mdma (Do you prefer Matt or Matthew?)
I rolled back to 0.4.4 and doing some testing now.
Another footnote- I’m not sure if I may have been originally running v0.4.4-rc.2-photon.bin
Would the Web IDE bump it up to v0.4.4-photon if I had 0.4.4 selected in the build dropdown a few weeks ago?
Filtering? Not sure what you mean, but these issues just started this past week. Over the past few months I would occasionally get a false high-temp (maybe once in 2 weeks), whereas now I’m getting them randomly every 5 minutes to 3 hours.
*should this conversation be moved to a different heading?
Hi again, I’m happy with mdma, Mat (one t) or Matthew, thanks for asking.
For filtering, I wonder if you filter the temperature values through a low-pass filter - it can smooth out unepxected jump. You may not need it in your application - I used it at brewpi.com to help smooth over spikes and other anomalies.
Yes, let’s move this conversation to another thread since it’s no longer about downgrading!
(This should have appeared at the top of the thread! mea cupla --mdma)
Thanks @mdma! I didn’t know rollback wasn’t working. I didn’t think it was the cause, but as a troubleshooter, I was looking to reverse all changes back to a time when it was stable. Is it at all possible that it relates to float conversion since it seemed fine using int16_t and no decimal point for Temperature when I modified it as a temporary fix last month.
Oddly - my Core with the same set-up and firmware using sprintf ("%2.1f") does not exhibit the temperature jump. Every now and again it may miss a read and then the value is a min or max value, but this is always around 138F with the at-rest temperature around 80F
None of the STRING variables should have an “&” in front of them (all of the INT variables need it). So multiSwitch and multiVal are correct but cTemp and highTempVal and overTempVal are not.
Thanks @bko
I fixed that. Shouldn’t that have caused a compile error?
Could that have caused the issues? So far, even without that fix, it has not generated a random higher-temp reading since loading 0.4.4
I’ll check it with the OneWire lib next.
No, it is difficult to make a compile-time error for that case and it is a very common fault. And yes, it could easily explain the symptoms you were seeing since the Spark (Particle) variable was reading from a location in memory that was not correct.
The issue of using & with strings comes up very often. I wonder if some C++ template magic can help check this at compile time. Currently the variable is of type void* which gives us no checks…leave it with me and I’ll try to make this better.
I’ve been experiencing this same issue with my DS18B20 on 0.4.5 using https://github.com/Hotaman/OneWireSpark. Pretty much took my routines straight from his examples.
Temperature reads 76 most of the time, I was getting the occasional 131, and have been seeing 31 recently. I had chalked it up to a weak connection on my breadboard
Update - After letting it run on 0.4.4 and only getting a few high jumps in a weeks time, I just updated to 0.4.6 and already gotten 2 jumps at 134F in the last 2 hours with room temp @80F. not even using floats