Minor issues: Chrome and max temp


 

Matt Fine

TVWBB Member
It looks like switching to a Pi Zero has successfully resolved my dropout issues, so now I have a couple small questions.

1) The link meter home page used to continuously update every second or two. It still does in Safari on an iPhone, but in edge (puke) it updates much slower and Chrome no longer updates. Is there a Chrome browser setting I need to adjust or did this get killed by a patch or update?

2) I used to be able to get the PID debug info by hitting P. It doesn't work in anymore in any browser I have tried. Is this an HM update, or a browser issue as well?

3) If my pit probe temp gets too hot at ~550-650 it will drop out and the HM LCD reports no pit probe. It comes right back after if cools down a bit. Is there limit with the HM thermocouple hardware or software, or is this something I should investigate further? I have ruled out the thermocouples I am using as I have the same issue with a half dozen of them, and they all work fine with two other devices up to 900 plus.
 
I can’t answer most of that. But, you can use tp=1 in the command box on the config page to get the PID debug info. I use it it a lot from my phone because I don’t know how to send the letter P from it.
 
I dont have an answer for item 1, I use Chrome and it updates fine

For #2, make sure you login with your password before you you hit P to open the PID screen

For #3, I have reported this issue, or similar issue a couple times, it is long standing. For me the TC doesnt really have a ceiling, I've gotten mine WAY up there and it reads fine. When I have a problem is when the temp rises rapidly, like after a lid open on a high heat cook. When I close the lid the temp darts up momentarily and then goes to "No Pit Probe". If I power cycle the HM it comes back immediately, or if I just wait a while it will eventually come back. It's not a problem with the TC handling the temp or the HM registering the temp (in my experience), it's a problem with the temp changing rapidly by a large amount. Bryan tried to reproduce it but said he couldn't, but I can reproduce it over and over with different HM units so I have no doubt there is some issue there.
 
Thanks guys. Being logged in does not help the P issue. Entering the command is a suitable alternative.

Ralph, you may be right about it being a rapid rise vs absolute temp. Whenever I use the Kamado at high temps, I am also opening and closing the lid frequently since things cook quickly. It happens on every high temp cook so it is easy for me to reproduce. I am surprised Brian can’t reproduce it. Hmmm.

Ralph, are you running an up to date and patched Chrome on up to date Windows 10? If so, it must be a setting I have, or maybe my antivirus or something else interfering.
 
1) Edge doesn't support the server-sent events standard so it polls rather than gets a data push like all other browsers (I think Microsoft closed this issue last year as a "won't support"). The update rate for other platforms is variable and depends on the data changing. If nothing changes the update rate is once every 5 seconds, if it is changing every second it will send the first two at 1s each then throttle down to once every 2s. This is done to reduce client side load of redrawing the graph every second which gets messy at larger scales and eats battery on mobile. If you're not seeing updates, be sure you're waiting long enough for an update to come (up to 10s) and it it looks like it is happening every 10s, then it is likely falling back to polled for some reason. I use Chrome exclusively and only do basic testing on the other browsers.

2) 'P' only works if you're logged in (the URI is /luci/admin/lm/home not /luci/lm) and the PID loop is actually running (it isn't OFF or No Pit Probe). The updates also only come 1-2 seconds after being turned on and only come via the server-sent events pipeline. If you're polling for some reason, no PID info.

3) I've still never seen this but I'll definitely look into this again. I can't imagine why some sort of slope would cause a no probe scenario. There are two limits though, one is the min/max temperature limit we accept as valid data: -20C to 500C. The other is the ADC dynamic ranging which is where thermocouples transition from one ADC reference to another. This happens around 200C ish but is variable depending on input voltages and bandgap tolerance. I could see that being an issue but I can't see in the code any case where the transition wouldn't happen properly. I wouldn't rule it out entirely though.
 
1) Edge doesn't support the server-sent events standard so it polls rather than gets a data push like all other browsers (I think Microsoft closed this issue last year as a "won't support"). The update rate for other platforms is variable and depends on the data changing. If nothing changes the update rate is once every 5 seconds, if it is changing every second it will send the first two at 1s each then throttle down to once every 2s. This is done to reduce client side load of redrawing the graph every second which gets messy at larger scales and eats battery on mobile. If you're not seeing updates, be sure you're waiting long enough for an update to come (up to 10s) and it it looks like it is happening every 10s, then it is likely falling back to polled for some reason. I use Chrome exclusively and only do basic testing on the other browsers.

I try to use chrome or my phone exclusively, just attempted Edge for kicks. I don't think there is an issue with the HM/LM as I can simultaneously watch the page update on my pnome, and not update for hours on Chrome. I will poke around and see if it is something I did with Chrome settings.



3) I've still never seen this but I'll definitely look into this again. I can't imagine why some sort of slope would cause a no probe scenario. There are two limits though, one is the min/max temperature limit we accept as valid data: -20C to 500C. The other is the ADC dynamic ranging which is where thermocouples transition from one ADC reference to another. This happens around 200C ish but is variable depending on input voltages and bandgap tolerance. I could see that being an issue but I can't see in the code any case where the transition wouldn't happen properly. I wouldn't rule it out entirely though.

As you pointed out in the other thread, the thin wire thermocouples I use are very fast reacting. I wonder if that is why you are not seeing it and Ralph and I are. I am almost always cooking below 500C, but when the lid is open on a raging kamado fire, I believe the temp reading will drop below 200c/400f. Upon closing the lid it is going to rapidly cross back over that threshold up to 600+F (pizza and calzone) and I guess it is possible that the extra air hitting the coals may mean a brief heat spike to 900+f/500c. I have measured temps at my searing grate (1/2" off the fire) of over 1100f using the same probes and a different device, so I know the probes read over 500C and the charcoal fire is capable of producing those temps.

BTW, is ther a way to adjust the max temp up a bit to 550 or 600C? 500C is not completely unreasonable if you are trying to replicate a tandoor. Only mostly unreasonable. :D
 
I use a very thin needle thermocouple as a pit probe and it does react very fast, so when I open the lid on a high heat it goes from ambient up to 500-600F very rapidly, that is when I get the "No Pit Probe" issue. I dont think it is due to exceeding the max temp, as I know I have had my pit hotter and the HM registered it fine, I think it has something to do with the rapid rate of change on the pit probe.
 
Ralph, I think you and I must be too quick for Bryan to keep up. :D Seriously, it does sound like it is related to a rapid rate of change. If it wasn't snowing and blowing like mad out, I might have done some testing tonight.

I figured out my issue with "Chrome" not updating. It turns out the craptastic Sophos virus suite my employer is currently requiring does not play nice with server-sent events. It treats it as a downlod and buffers it to scan, and small updates will take forever to fill the buffer so they simply dont get through. Grrrrrr.
 
Final followup on problems 1) and 2)...

Uninstal Sophos and the webpage updates properly and the P works again. :D

So, my only remaining issue is the elusive high temp or high rate of temp change bug. Since I am not the only one with the issue and it really is minor, I can live with that for now. I will try to remember to do some testing to see what it takes to reliable recreate, but not until the snow melts.
 
I know I did some testing trying to nail down the issue when I first experienced it, as I recall the pit probe never dropped off when the pit would rise up slowly even if the top end temp was very high, but would reliably drop off if the rate of rise was very rapid. Like you said, not a major issue, I just make sure to check the HM after I close the lid on high heat cooks and power cycle the HM if it drops off. It will eventually come back on its own, but for pizza I want the pit temp to rebound really quickly so I keep the fan pumping even while the lid is open and want to to continue when I close the lid.... because the whole cook takes less than 10 minutes, and I want to hit at least 550F in the first minute or so...
 
I tested this like 20 times with a bare thermocouple and a blowtorch going from room temperature up as high as 800F+ and back down over and over and it worked fine. I also put the thermocouple over the stove gas burner and turned it on and off over and over and it worked fine as well. Then I tried putting an upside down pot over the thermocouple and turning the stove on and off and tahdahhhh! No Pit Probe.

It appears to be just as I expected, some weirdness in the way the code handles switching over from high resolution (<~450F) to high temperature. It could get wedged up at the highest possible high res temperature and be unable to flip over. If there was one reading in the transition zone, somewhere between 400F and 450F, it worked fine but if it somehow was able to skip that range entirely, it would stay stuck until the temp dropped again. I've posted some test AVR Firmware -> Online Repository -> heatermeter.hex which I think I've worked around this. Slap that on your HeaterMeters and let me know if that resolves the issue and doesn't appear to break anything else.
 
Reading partway through about the blowtorch and open flame I was starting to worry you'd never reproduce it, glad you finally were able to witness this behavior yourself. I did a steak last night and had this happen twice, once at each lid opening... would drive me bonkers if you couldn't reproduce it!
I just threw the update on my machine, will try to do some high heat cooks in the next couple days to see if this is fixed.
Thanks for investigating Bryan!
 
Woohoo! Glad to see such quick progress on this bug, and super glad you were able to reproduce it.

I can’t test this week (out of town) but I will try to plan a high heat cook next weekend.
 
FYI, I did a steak cook last night and the pit probe did not drop off at all. This isn't a definitive answer that this issue is fixed, but a couple days ago I did a cook in the same exact manner and the pit probe dropped off twice during that cook... so I'm thinkin' this issue may be fixed!
 
I've done another steak searing cook and two pizza cooks and had no pit probe dropouts, I think this issue is history! Thanks for making that change Bryan, even though I had just accepted that I had to power cycle the HM to bring the pit probe back to life on high heat cooks that little humbug did bother me quite often, glad to be rid of it....
 
If the snow ever stops, I will try to test on Saturday. If I use the snapshot tool Friday evening will it be in there, or should I grab the hex file?
 
IDK when Bryan is going to get this rolled into the regular snapshot download or release version, but right now if you go to you HM Config/AVR Firmware tab and click "Online Repository" you should see a Heatermeter.hex dated April 9th. Load that up and it should have this fix.
 
Just uploaded the new combined snapshots so everything is in sync now, using the latest firmware image includes the latest AVR image. The faster way to do it is to just do the AVR snapshot only as Ralph explained though, since that takes 2 seconds compared to a couple minutes for a full image (and that's the only thing that's changed).
 
OK, done. I haven’t followed close enough to know if there have been any other changes for the snapshot.

Thanks.
 

 

Back
Top