StokerLog Version 5 Preview


 
In the app I wrote, "timers", this feature is selected in a menu. I first select a probe to test for a temp, then select either rising or falling, which probe to change, and finally the new target temperature. I make no assumptions as to which probe is to be tested or which probe is to be changed. I only need to know if you are looking for a temperature rising or a temperature falling. This is for ease of logic (>= or <=). There might be no reason to reset the target temp of a pork butt, but my app doesn't care about that type of logic. Mine also works the ramps in the order they were created, so you can have 5 changes, but it is only looking at the top of the heap, when that is completed, it throws that off and starts looking at the next one until they are all gone. This wouldn't work for multiple pits.

I wouldn't do this just for me, I have a way of doing it in the app I wrote. Maybe you should find out if any one has has any interest in such a feature. One of the reasons I thought it might be a good idea was breaking that stubborn temp shelf in low and slow pork butts. You know that point when your butts reach 150 and then seems to hang there for a couple of hours before starting to rise again. With this feature, you can tell the stoker to kick the fire up from 225 to 250 when the butt reaches 150 and then when it reaches 160, kick the fire back down to 225 to finish it. This reduces cooking time with no bad effects.
 
I am not sure I would use this "auto shift" feature in order to break a plateau (possibly) but I would certainly be interested in it for the Turkey example as well as the reverse if I am doing prime rib. When doing prime rib, I like to start off hot for the first few degrees to help form a good crust and then drop to low and slow to allow for an even cook.
 
Quick question and thought on the predict when done feature.

First, does it use the excel forecast function for the entire log of that probe?

The reason I ask is that I notice mine are seldom anywhere near the target and it keeps updating until the point where I pass the prediction and sometimes I still have 2-3 hours or more.

I was wondering if it does read the entire log, if it would be more appropriate to have it only look at the last portion of the log for that probe in the prediction calculation. This may help account for the early jump when you put something on, and then then the plateau as well. Perhaps just looking at the last 25% of the values in the calculation, or maybe even a max of the trailing 30min to an hour?
 
Well, yes and no
icon_smile.gif
. It does use a polynomial regression function which Excel also has. Alas, when I used it in practice, it just didn't work right. So I played with it for a while to make it better to no avail. For example, I do ignore the first X number of samples.

I have seen it work well for grilling where there is good progression of temps. For low and slow, it doesn't work. I tried higher order polynomials and that didn't work any better either so I put it back to linear I think for the latest version.

I plan to one day ask the user what is being cooked, and then have the program have knowledge of the knee and other things that would describe the cook. In case of pulled pork for example, I think one really needs to ignore all data until you get out of the long period in the middle when nothing happens. A curve fit is just not going to generate useful info.

I am open to suggestions/ideas on how to make this better
icon_smile.gif
.
 
Well your ideas surpass mine at this point. I was just looking at something basic like looking at the last 10-15-20-25-30-etc. minutes to use as the prediction sample.

I was just baffled that the timer would continue to increase to the point that it finally went away and then still had a few hours to cook.

I may play around with a couple of my recent logs and see if there is a window that appears to work based on the data recorded in the logs that then tracks close to the finish time.

Let you know what I turn up.
 
Thanks. BTW, I blank the field when it gives me times in the past or a way into the future (like months from now)! The formula does crazy things in providing the coefficients.
 
OK. I uploaded my last few cooks into excel and then used various samples sizes 5 minutes, 10 minutes, 20 minutes, 30 minutes and 40 minutes. For each, I used only 1 sample per minute (the logs seem to only record one sample a minute to this worked well).

As a measure of accuracy I used a +/- 10 min from the actual target time that I did reach my target temp as the method of checking each update to see how accurate each prediction was.

In my test cases, the last 5 minutes was the worst. It spent the least time through out the cook within my set margin of error and it spent the most time during the plateau predicting a completion time in the past (i.e. the flat and sometime dropping temp in the plateau reeks havoc on the excel forecast function as it starts to predict a time in the past).

All the other sample sizes did a reasonable job in the latter stages of the cook but all of them had some time in the plateau that predicted the target would have been reached in the past. That said, all the larger sample sizes up to the 40 min mark started to get more accurate as it approached the target temp.

The 40 min sample size never predicted a time in the past. That said, it did not get within my margin of error until the last 30 minutes of the cook.

The 10 min sample size spent 19 minutes in the plateau predicting a time in the past. But it entered the margin of error about 55 minutes out.

The 20 min sample spent 14 minutes predicting a time in the past during the plateau and entered the margin of error 38 minutes out.

The 30 min sample spent 9 minutes predicting a time in the past during the plateau and entered the margin of error 33 minutes out.



Also, all samples (except for the min sample size which was observed to have a wide range of swings) showed a ramp up a good 2.5 hours past the actual target time before the plateau. Then a gradual ramp down until it hit the target temp. For the 10-30 min samples there was a dip during the plateau and then a spike once again to about 2 hours past the target before it starts to zero in again.

Based on this, I would say that the 10 min or 40 min sample sizes are the best predictors if you can only look at one temp entry every min. I think the fact that it starts to zero in 1 hour out is very helpful on the 10 min side and that it never appears to predict a time in the past is attractive for the 40 min sample size.

Perhaps a graph of the rolling prediction will show this trending will give a good example of what is going on and especially the converging lines of the prediction and the probe temps would let you know where you are in the cycle and how accurate the prediction may be.

I do think that the actual samples need to be limited to 1 a minute as if you take the evolving up and downs within the minute I think it will end up throwing off the forecast function even more.

I am going to play around with different margin's of error and see that changes things. Perhaps +/- 20, 30, and 60 minutes are appropriate.
 
Larger margin of error didn't really change anything but on looking back I wouldn't think it would.

I guess the real difference is in the sample size and in that case I am leaning to the 10 min or 40 min sizes.
 
Thanks for the analysis. You may be on to something.

At the same time, I think it is important to test the hypothesis on multiple data points. I had no trouble getting very high accuracy on one cook but then on another, it would just go crazy.

I like your idea of plotting them to get a pictorial view of what it is done. When I have more time to kill, I will see if I can experiment with this.
 
Hi Amir, I want to thank you!!! I really like your software. It is really great. I was surprised when I replaced my guru with the stoker that the http interface wasn't more robust.

I've found it a vital tool, at measuring times for comps. I'm amazed how easy it is to forget to take notes, or to question them later. Your software fixes all that.

I thought I would share with you some things that I would find to be nice additions.

First, I'd like to probe field to be longer. If that is a limitation of the Stoker, you could have an additional field next to it to add a longer description of the meat. You could even have a drop down that had pictures of meat, ribs, brisket etc.

Second, I'd love it if it saved snapshots on a regular basis. If you are doing a comp, you probably don't have internet connectivity, and if you laptop crashes, you've lost everything since your last manual save.

Third, I'd love a place to take notes, maybe this just isn't the right place for it, but if there was a tab for each probe, that I could document how the meat turned out, or what recipe I used, that would be great. Now I do it in word, and just copy jpegs into word.

Finally, When the stoker loses connection, and reconnects, I think it should just leave a blank in the plotting area, not show the probes to 0, this would show less noise on the chart.

All of these are just nice to haves, as your software is awesome.

Thanks,

Team Woodfellas
 
Oops, I forgot a couple of thoughts. :-) It would be really nice if it would plot the target temperature, of the contolling sensor. It would ride on the top like a baseline, that would change, as the set point is changed.

Also, if the graph line could be set to larger, the colors would be more definitive.

I hope you don't mind the suggestions, you could ignore all of these, and I'd still buy your software if it for sale.
 
Amir - I am going to second, if not already clear, that I think this is the best thing since sliced bread.

I will try this experiment with a couple of more cooks. I have some prior logs saved some with several meats on during the cook. I will run the same analysis on each of them and send you my findings so that we have more than this one cook to base this on.

If I do this based on what i have recorded, I will have at least 3 separate cooks with a total of 6 pieces of meat being charted to compare against. Now that I have the formulas for the forecasting, etc. down, I may try to do these in 5 min breaks so that we have a 5, 15, 15, 20, 25, 30, 35, and 40 min samples to see where the breaking point may be.
 
Originally posted by Lou DeFino:
Hi Amir, I want to thank you!!! I really like your software. It is really great. I was surprised when I replaced my guru with the stoker that the http interface wasn't more robust.
Hi Lou. Thanks for the kind words and feedback. It is the "currency" that gets me going with each revision
icon_smile.gif
.

First, I'd like to probe field to be longer. If that is a limitation of the Stoker, you could have an additional field next to it to add a longer description of the meat. You could even have a drop down that had pictures of meat, ribs, brisket etc.
Do you mean where you record the name of the probe? If so, it is not too hard except that I read back the names the next time you start the program. So it takes more programming to go beyond what the stoker records.

Note that for now, the field automatically scrolls to the left. So you can type more stuff, you just won’t see it all at once.

I will think about how to implement an enhanced method for this.

Second, I'd love it if it saved snapshots on a regular basis. If you are doing a comp, you probably don't have internet connectivity, and if you laptop crashes, you've lost everything since your last manual save.
The program, in this version, is actually recoding everything it is reading from the stoker. I was thinking about turning this off for the production version. But come to think of it, with some changes, I may be able to re-read that log and populate the graph. The current data misses timestamps which I would need to add.

Alternatively, I can modify the email timer to save graphs locally instead of emailing to you.

Third, I'd love a place to take notes, maybe this just isn't the right place for it, but if there was a tab for each probe, that I could document how the meat turned out, or what recipe I used, that would be great. Now I do it in word, and just copy jpegs into word.
Yeh, I have been thinking about a log/summary report at the end with a place for notes and comments. Anyone want to suggest the exact format and how this should work? Then I can implement it.

Finally, When the stoker loses connection, and reconnects, I think it should just leave a blank in the plotting area, not show the probes to 0, this would show less noise on the chart.
I tear down the probes and recreate them on start up as the probe configuration may have changed. So saving them takes fair bit of work. Let me think about this.

All of these are just nice to haves, as your software is awesome.

Thanks,

Team Woodfellas
Keep the feedback coming. I will collect them for version 6.0.
icon_smile.gif
 
On the probe tear down, yes it does show spikes in the stoker graph, however if you are only interested in having this as a log you can use excel to chart each cook.

You have to make a copy of each stoker log file between each cook (he, would a new log file with a timestamped creation date be an option for a feature?). Then I import the log into excel and do a graph of the cook. I will go into the log file and delete all the note entries (actually I just move them to the side) and times where the connection was lost (if any) and the temps show that complete drop. Then the graph comes out nice and neat.
 
Originally posted by LarryR:
I haven't been able to get email work in v. 5. I'm with ATT and my email ext. is @sbcglobal.net. I've set mail up exactly the way I have it setup in Outlook (including port). Any ideas? I've used Stoker Timer's email feature without any issues using the same settings as I have loaded in Stokerlog. Very strange . . .

Where can I find the Port #? I use Microsoft Live mail and it only shows the servers etc...no port listed?
 
Originally posted by Jim Smithson:
<BLOCKQUOTE class="ip-ubbcode-quote"><div class="ip-ubbcode-quote-title">quote:</div><div class="ip-ubbcode-quote-content">Originally posted by LarryR:
I haven't been able to get email work in v. 5. I'm with ATT and my email ext. is @sbcglobal.net. I've set mail up exactly the way I have it setup in Outlook (including port). Any ideas? I've used Stoker Timer's email feature without any issues using the same settings as I have loaded in Stokerlog. Very strange . . .

Where can I find the Port #? I use Microsoft Live mail and it only shows the servers etc...no port listed? </div></BLOCKQUOTE>

What are you wanting to do with the ports? Windows firewall blocks ports and you can release them in control panel->windows firewall. You set up ports for outlook and other e-mail programs in the accounts section. MS live mail configures all the port setting for you, so you woul dneed to find out what port their outgoing server uses, (port 25 normally for Outlook and Outlook express), but the mail srever determines which port you should use.
 
Originally posted by Ken Brown:
What are you wanting to do with the ports? Windows firewall blocks ports and you can release them in control panel->windows firewall. You set up ports for outlook and other e-mail programs in the accounts section. MS live mail configures all the port setting for you, so you woul dneed to find out what port their outgoing server uses, (port 25 normally for Outlook and Outlook express), but the mail srever determines which port you should use.

I want to know as the Stoker log version I have asks for a port # (it defaulted to 587) in the mail settings screen.
 
I found at the Comcast website, to use port 587 when setting up Outlook Express, so i assume that is the port I would use for Stoker.

However, sending test email doesnt get any response. Just does nothing. I did get a firewall warning and now Stoker is listed as an exception.
 
I have an account at gmail so I have been using that one for my agent. However, I too am a comcast customer and after trying to use them as an agent, I find it will not work with comcast. My advice for now is to get a free gmail account.

Amir,
This is weird for 2 reasons. One, it works with my app without problems using standard ports (25) and client.EnableSsl = false
2 If I change back to my gmail settings, I have to exit you app and restart before they will work. ?? odd eh...
 

 

Back
Top