ADS1115 Temp Readings

[weberbox]

So on a couple of cooks I have had an issue with the probe temps freezing. It only seems to affect the food probes and has never affected the grill probe. I think it happens when there is big and fast change in the probe readings. For example today the probes were at around 65f and when I probed the meat which was 35f they stuck at 65f. Unplugging them and plugging them back in seems to resolve the issue.

Wanted to see if this has ever happened to anyone before I start debugging what might be causing it.

[nebhead]

Yep, I know what's happening. I have some protections in the code, to prevent the food probe temperatures from erroneous readings. I was having some issues with some particularly finicky probes that would jump around wildly with their readings, especially at lower temperatures (such as around 35F). So I put some logic into the code in the control script to prevent the food probes from reporting the temperature swings of 20% difference from the last reading. So it makes sense that it would suppress these readings if the probe was reading 65F ambient and you probed something that was 35F. There might be a smarter way to handle this. :) I ended up throwing out my knock-off Maverick probes and only use the ThermoWorks probes now which makes a huge difference in the reliability of the output.

Here's the code in control.py:

# Get temperatures from all probes
		adc_data = {}
		adc_data = adc_device.ReadAllPorts()

		# Test temperature data returned for errors (+/- 20% Temp Variance), and average the data since last reading
		if((adc_data['GrillTemp'] != 0) and (adc_data['GrillTemp'] >= AvgGT * 0.8) and (adc_data['GrillTemp'] <= AvgGT * 1.2)):
			AvgGT = (adc_data['GrillTemp'] + AvgGT) / 2

		if((adc_data['Probe1Temp'] != 0) and (adc_data['Probe1Temp'] >= AvgP1 * 0.8) and (adc_data['Probe1Temp'] <= AvgP1 * 1.2)):
			AvgP1 = (adc_data['Probe1Temp'] + AvgP1) / 2
		elif(AvgP1 == 0):
			AvgP1 = adc_data['Probe1Temp']
		elif(adc_data['Probe1Temp'] == 0):
			AvgP1 = 0

		if((adc_data['Probe2Temp'] != 0) and (adc_data['Probe2Temp'] >= AvgP2 * 0.8) and (adc_data['Probe2Temp'] <= AvgP2 * 1.2)):
			AvgP2 = (adc_data['Probe2Temp'] + AvgP2) / 2
		elif(AvgP2 == 0):
			AvgP2 = adc_data['Probe2Temp']
		elif(adc_data['Probe2Temp'] == 0):
			AvgP2 = 0

You can try to remove this logic and see what happens for you. Or if you have some other thoughts on how we can avoid erroneous inputs, let me know.

[weberbox]

Ok I slightly remembered this section of code and it was my first thought on where to start looking so I am relived that it is not a hardware issue. I also have Thermoworks probes so I doubt it is needed in my case. Removing it would obviously be the easiest but it would be nice to have some protection from bad readings especially for anyone that might have lower quality probes.

I think the issue now is there is no recovery if the temp is outside the 20% variance, The if statement would just be passed over and AvgP(x) would not be updated again until it came back into the 20% variance threshold of the last reporting. Maybe adding an elif with a short time period to drop erroneous readings and require multiple readings (not sure how many would be needed) within the new reported range to consider it normal and update AvgP(x) with the new reported temp then the first statement would resume function again.

I think that way if the probe read something way out of line a couple times it would be ignored but if the new temp is real the elif would reset AvgP(x). So I guess need to figure out how many new reporting's do we need before it is considered normal. I guess you could require it be be within a time frame as well but that might just be overkill.

[weberbox]

Ok so here is something I thought up. It could probably be better but might inspire other ideas

# Test temperature data returned for errors (+/- 20% Temp Variance), and average the data since last reading
if((adc_data['GrillTemp'] != 0) and (adc_data['GrillTemp'] >= AvgGT * 0.8) and (adc_data['GrillTemp'] <= AvgGT * 1.2)):
    AvgGT = (adc_data['GrillTemp'] + AvgGT) / 2
    probe_data_list.clear() ## Clear the list if we return here of if we never made it to 20 probe readings before the probe corrected itself
elif(adc_data['GrillTemp'] != 0):
    if(len(probe_data_list) < 20):  ## Collect 20 probe readings
        probe_data_list.append(adc_data['GrillTemp'])
    else: ## Once we have 20 readings which will be about 1 second
        avg = round(sum(probe_data_list)/len(probe_data_list)) ## average all 20 entries in the list
	new_list = []
	for item in range(len(probe_data_list)):
		if((probe_data_list[item] >= avg * 0.8) and (probe_data_list[item] <= avg * 1.2)): ## Strip out any reading that are outside the 20% variance of new readings 
			new_list.append(probe_data_list[item])

        AvgGT = round(sum(new_list)/len(new_list)) ## Average the new list with the 20% variance items removed
        new_list.clear()

else:
      readings are 0

This should work if the readings are not all crazy but only a few are out of spec.
When your other probes gave some crazy readings do you think it was more than 5-10 readings?

[nebhead]

I really like your idea of using a list to store temperature entries. It got me thinking that it might be a nice idea to create our own queue class that just keeps a running list of the last 10 readings or so. The class could do the averaging, throwing out the readings that are greater than +/- 20% off. We could use objects of this class this instead of the AvgXX variables above. Would probably give us a better overall average values and might be a little cleaner to look at. :) I'll try to whip something up when I have time tomorrow.

…

On Mon, Oct 25, 2021 at 7:03 PM James Weber ***@***.***> wrote: Ok so here is something I thought up. It could probably be better but might inspire other ideas # Test temperature data returned for errors (+/- 20% Temp Variance), and average the data since last reading if((adc_data['GrillTemp'] != 0) and (adc_data['GrillTemp'] >= AvgGT * 0.8) and (adc_data['GrillTemp'] <= AvgGT * 1.2)): AvgGT = (adc_data['GrillTemp'] + AvgGT) / 2 elif(adc_data['GrillTemp'] != 0): if(len(probe_data_list) < 20): ## Collect 20 probe readings probe_data_list.append(adc_data['GrillTemp']) else: ## Once we have 20 readings which will be about 1 second avg = round(sum(probe_data_list)/len(probe_data_list)) ## average all 20 entries in the list new_list = [] for item in range(len(probe_data_list)): if((probe_data_list[item] >= avg * 0.8) and (probe_data_list[item] <= avg * 1.2)): ## Strip out any reading that are outside the 20% variance of new readings new_list.append(probe_data_list[item]) AvgGT = round(sum(new_list)/len(new_list)) ## Average the new list with the 20% variance items removed probe_data_list.clear() ## Clear the list. Now the first if statement should take over since we updated AvgGT to the new reading. new_list.clear() else: readings are 0 This should work if the readings are not all crazy but only a few are out of spec — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#48 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AEXUYFQCI7DHDFXLTSZOALLUIYD6VANCNFSM5GUKZX7A> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[nebhead]

OK, I have a solution that I'll push up shortly that utilizes a class for the average temperatures. I'm embarrassed to admit I might have stolen some time away from work to do this today. It basically creates a small queue with the last 10 samples. It does a standard deviation calculation on the data, and if it doesn't exceed a certain threshold, it will do the average on the data. But if it fails, it will use the last known good average. So for large temperature swings, it should pause only momentarily as the queue gets flushed with new data, and won't get stuck. For erroneous values, it should hide the minor swings (i.e. one or two values getting completely borked). However if it is really bad, it might stall the temperature readings. In that case, it might be a good thing. Toss that probe in the trash. :)

Anyway, there might be a better way to handle this, so please feel free to let me know if you see any room for improvement. I haven't tried this on real hardware yet, but I will give it shot the next time I use the grill.

Also fixed a couple bugs that I discovered along the way. Bonus! :)

[weberbox]

Cant wait to take a look! And if your embarrassed by stealing some work time I should be outright ashamed of myself lol. I have stolen a considerable amount but I am salaried so it gets made up in some way or another over time at least.

[nebhead]

And if your embarrassed by stealing some work time I should be outright ashamed of myself lol. I have stolen a considerable amount but I am salaried so it gets made up in some way or another over time at least.

Ha! Oh yes, they will definitely get that extra time out of me eventually. Sigh.

[weberbox]

OK, I have a solution that I'll push up shortly that utilizes a class for the average temperatures. I'm embarrassed to admit I might have stolen some time away from work to do this today. It basically creates a small queue with the last 10 samples. It does a standard deviation calculation on the data, and if it doesn't exceed a certain threshold, it will do the average on the data. But if it fails, it will use the last known good average. So for large temperature swings, it should pause only momentarily as the queue gets flushed with new data, and won't get stuck. For erroneous values, it should hide the minor swings (i.e. one or two values getting completely borked). However if it is really bad, it might stall the temperature readings. In that case, it might be a good thing. Toss that probe in the trash. :)

Anyway, there might be a better way to handle this, so please feel free to let me know if you see any room for improvement. I haven't tried this on real hardware yet, but I will give it shot the next time I use the grill.

Also fixed a couple bugs that I discovered along the way. Bonus! :)

Did a few cooks this weekend with the new temp queue and it worked great. I didn't see the probes lock up and it seemed to report the temps back just fine.

There is something that came up that I had never thought of before though. Power loss recovery. We were out camping in our trailer this weekend and I brought the smoker. Had a couple power fluctuations and the grill shut off due to power loss.

I started some work on power loss recovery. Hopefully I can get it working well enough. Would be awful if it was a 10+ hour cook that stopped in the middle due to a power loss and you were sleeping etc.

[nebhead]

Did a few cooks this weekend with the new temp queue and it worked great. I didn't see the probes lock up and it seemed to report the temps back just fine.

Woohoo! That's great! I also did a cook over the weekend and was pleased at how it worked as well. No lock-ups and even when probing a partially frozen Tri-Tip, it worked great.

There is something that came up that I had never thought of before though. Power loss recovery. We were out camping in our trailer this weekend and I brought the smoker. Had a couple power fluctuations and the grill shut off due to power loss.

Oh man, I wish I could cart my grill with me on trailer trips. Unfortunately, our trailer is a little on the small side (Jayco Pop-Up) and there is no way I'm going to fit a grill into either the car or the trailer. Maybe I'll need to look at one of those portable pellet grills some day.

I started some work on power loss recovery. Hopefully I can get it working well enough. Would be awful if it was a 10+ hour cook that stopped in the middle due to a power loss and you were sleeping etc.

Excellent, looking forward to this!