StokerLog Version 4.0 Preview
- Thread starter Amir
- Start date
I need some feedback on how to change the timed alarms.
A while ago, Ken was kind enough to provide pretty detailed feedback on alarms. He found a few bugs which I have fixed. But he also identified a design problem which I have not found a satisfactory solution for.
Problem is what to do if the connection to stoker gets lots and you restart the program/logging. Right now, doing so, essentially resets all the alarms to their original values because the program thinks you just started cooking.
Ken suggests that instead of relative number of minutes to set off an alarm, I should use the actual date+time. This is trivial to implement. However, I save timed alarms under settings. So one could set up a .bbq file for say, ribs. The relative times stored there will always work. But as soon as I change it to absolute date+time, they would not. I suppose I could try to save the relative times and convert to absolute. But before I do, like to get some feedback.
So let me know what you think!
Thanks.
A while ago, Ken was kind enough to provide pretty detailed feedback on alarms. He found a few bugs which I have fixed. But he also identified a design problem which I have not found a satisfactory solution for.
Problem is what to do if the connection to stoker gets lots and you restart the program/logging. Right now, doing so, essentially resets all the alarms to their original values because the program thinks you just started cooking.
Ken suggests that instead of relative number of minutes to set off an alarm, I should use the actual date+time. This is trivial to implement. However, I save timed alarms under settings. So one could set up a .bbq file for say, ribs. The relative times stored there will always work. But as soon as I change it to absolute date+time, they would not. I suppose I could try to save the relative times and convert to absolute. But before I do, like to get some feedback.
So let me know what you think!
Thanks.
I haven't used the timed alarms yet, but...
If the program were more oriented toward being used for a "cooking session" rather than just loading previously saved settings and starting to log data, the timer problem would be a lot easier to fix.
When the user starts a "cooking session," all you have to do is note the wall clock starting time and persist it; let the user pick "relative" times for the alarms, which you can then convert into absolute times based on the session start time.
Then it doesn't matter how many times the connection is lost; when it's re-established, you just verify that the settings on the Stoker are the sames ones StokerLog is using and start logging data again -- you'll have to have a "gap" in the log data for the period when there was no connection, but that shouldn't be difficult to manage.
(BTW - converting the logfile to XML right about now would go a long way toward making it more extensible in the future -- the "gap" could be a simple one-line XML tag: <LogGap duration=10/> or something like that. Plus the "session" oriented nature of the file could be implemented by wrapping the data in one set of tags <Session Settings="Ribs.bbq" StartDate="20070707 14:32:00"> ... </Session> )
You could also provide the ability to "import" settings from a previous session, which would essentially replicate the current purpose of the .bbq file - you'd convert the absolute times for the timers back to relative times and the pull over the other settings as appropriate. The user starts the session and away you go.
I'd also prefer to see the logfile separated by cooking sessions as well -- rather than one giant logfile that accumulates more and more from every use, store the data session by session. That way I can go back and reload a previous session to see what the graph looked like, etc.
Hope this helpful. If you'd like any assistance writing or debugging the source code, let me know. I'm a C#.NET guy, not a VB.NET guy, but I'll bet I can handle it...
If the program were more oriented toward being used for a "cooking session" rather than just loading previously saved settings and starting to log data, the timer problem would be a lot easier to fix.
When the user starts a "cooking session," all you have to do is note the wall clock starting time and persist it; let the user pick "relative" times for the alarms, which you can then convert into absolute times based on the session start time.
Then it doesn't matter how many times the connection is lost; when it's re-established, you just verify that the settings on the Stoker are the sames ones StokerLog is using and start logging data again -- you'll have to have a "gap" in the log data for the period when there was no connection, but that shouldn't be difficult to manage.
(BTW - converting the logfile to XML right about now would go a long way toward making it more extensible in the future -- the "gap" could be a simple one-line XML tag: <LogGap duration=10/> or something like that. Plus the "session" oriented nature of the file could be implemented by wrapping the data in one set of tags <Session Settings="Ribs.bbq" StartDate="20070707 14:32:00"> ... </Session> )
You could also provide the ability to "import" settings from a previous session, which would essentially replicate the current purpose of the .bbq file - you'd convert the absolute times for the timers back to relative times and the pull over the other settings as appropriate. The user starts the session and away you go.
I'd also prefer to see the logfile separated by cooking sessions as well -- rather than one giant logfile that accumulates more and more from every use, store the data session by session. That way I can go back and reload a previous session to see what the graph looked like, etc.
Hope this helpful. If you'd like any assistance writing or debugging the source code, let me know. I'm a C#.NET guy, not a VB.NET guy, but I'll bet I can handle it...
Thanks Marty. That's pretty good food for thought.
One idea I have had about another aspect of the program might dovetail with what you are suggesting. Today, connection to stoker and logging activities are tied together under one button. My thinking was to have a separate action, where on program start up, I would connect to stoker and that would be it. From then on, the log button would simply start/stop the monitoring.
Now, if the stoker stopped responding, you could use a menu option or function key to connect to it again. But logging would not be affected. This way, the fact that you lost connection to stoker and reconnected, would not impact the program timers, etc.
There are some holes in this logic to deal with timers but might make the problem easier to manage.
So what do you all think about changing the program to work like above regardless of timer solution?
Back to your suggestion regarding XML, I think most people use to graph with a spreadsheet program. I know current version of excel can import xml but not sure every program people use, does. What I can do is to create a second log file, this time, with unique session time stamp so the file is unique. I can use XML for this one and have it have the full set of data from stoker. Currently, I truncate the data and only capture it once every 30 seconds so that the file does not get huge. But with separate files, that should not be a problem. With all the data there, then you can do arbitrary analysis later.
So do you want to suggest an XML syntax for me to use? I would normally give you the source code to modify but this thing is such a spaghetti mess that it only makes sense to me right now. And I would be too embarrassed to show it to someone else
. Originally I thought this would be a quick weekend project so I did not pay a lot of attention to properly design its architecture although it is not too bad in this respect. One day I will re-write it properly in C# and then might take you up on helping enhance it.
One idea I have had about another aspect of the program might dovetail with what you are suggesting. Today, connection to stoker and logging activities are tied together under one button. My thinking was to have a separate action, where on program start up, I would connect to stoker and that would be it. From then on, the log button would simply start/stop the monitoring.
Now, if the stoker stopped responding, you could use a menu option or function key to connect to it again. But logging would not be affected. This way, the fact that you lost connection to stoker and reconnected, would not impact the program timers, etc.
There are some holes in this logic to deal with timers but might make the problem easier to manage.
So what do you all think about changing the program to work like above regardless of timer solution?
Back to your suggestion regarding XML, I think most people use to graph with a spreadsheet program. I know current version of excel can import xml but not sure every program people use, does. What I can do is to create a second log file, this time, with unique session time stamp so the file is unique. I can use XML for this one and have it have the full set of data from stoker. Currently, I truncate the data and only capture it once every 30 seconds so that the file does not get huge. But with separate files, that should not be a problem. With all the data there, then you can do arbitrary analysis later.
So do you want to suggest an XML syntax for me to use? I would normally give you the source code to modify but this thing is such a spaghetti mess that it only makes sense to me right now. And I would be too embarrassed to show it to someone else
Matthew Appler
TVWBB Super Fan
I like everything you suggested in your message, except for this one minor issue..
-Matt
I like everything you suggested in your message, except for this one minor issue..
-Matt </div></BLOCKQUOTE>
Ah, more feature requests
Is it possible to pass a little more info to the Web alarm?
In addition to knowing what is the active alarm, it would be nice to know current temp of each probe.
Particularly for email alerts. A timed web alert on a set interval (such as hourly) and you could get regular information updates of pit and meat temps during a cook via text message.
BTW - I am having fun using D. Penns web alert .asp
In addition to knowing what is the active alarm, it would be nice to know current temp of each probe.
Particularly for email alerts. A timed web alert on a set interval (such as hourly) and you could get regular information updates of pit and meat temps during a cook via text message.
BTW - I am having fun using D. Penns web alert .asp
Bill Sutton
TVWBB Member
Amir-
Great product!
Do you have an address where we should be sending coffee, beer or cash donations to chip in a bit for all this work?
Bill
Great product!
Do you have an address where we should be sending coffee, beer or cash donations to chip in a bit for all this work?
Bill
Thanks! No need to send cash or presents. Just the praise like this, will keep me going like a loyal dog
Really, it has been fun to write this program. I moved into management some 15 years ago and as such, it has been great to get my hands dirty on something that can feed you the next day!
At some point though, I will need some advice on how to cook tender Ribs. I can make the most fantastic chicken, brisket and pulled pork. But the darn ribs come out rather dry and not so tender. I have not tried foiling but cooking slow doesn't seem to do the job here....
If the wife likes chocolate more than you do, that is fine too. Like the old saying goes:
"If Mamma is happy . . . Everybody is happy!"
On the email syntax, I would think something simple.
The subject line would just be the alarm type. (IE- fire alarm, food alarm, or timed alarm)
The message body would be probe name and temp.
Red - 145
Blue - 148
Green - 147.5
"If Mamma is happy . . . Everybody is happy!"
On the email syntax, I would think something simple.
The subject line would just be the alarm type. (IE- fire alarm, food alarm, or timed alarm)
The message body would be probe name and temp.
Red - 145
Blue - 148
Green - 147.5
Amir, I am assuming you are talking pork ribs. While you can always add additional steps to cooking ribs, like foiling, I find the following is a successful approach on the GD. Purchase the double decker rack and hang it upside down. On this rack I have a weber foil pan filled with sand (the foil pan is something like 8" x 14"). Then add the standard rack on top of that. Place the ribs on the top rack (I have a rib rack to stand the ribs vertically so I can fit more) and cook them at 275 F for roughly 3 hours. Thanks again!
joe thomas
TVWBB Fan
Amir,
My method on a BGE, similar to GD, is as follows...
Note: I cook baby backs.
1) Peel membrane from back of ribs.
2) Pat ribs dry with paper towel.
3) Rub ribs liberally with yellow mustard, (important for moist tender ribs)
4) Apply a rub, in my case mostly turbinado sugar, sp?, mixed with salt and other spices, never the same twice, I'm still working on that.
5) Place ribs vertically on an upside down V-rack trying to leave space between the ribs.
6) Take a small disposable chafing tray and cover top with foil pushed about 1" into the chafing tray to catch grease. The dead air between the bottom of the chafing tray and top of foil keeps the grease from burning.
7) Sandwich chafing tray between upper and lower grill.
8) Place ribs in upside down V-rack on upper grill.
9) Cook ribs for 4 hrs at ~225 deg. F grill temp. (Sometimes I flip the ribs 2 hrs into the cook so they cook a little more evenly but usually not)
10) At 4th hr. I pull ribs from V-rack and lay flat on grill and flip every 15 minutes. and stick a wood toothpick in the meat. When the toothpick slides in and out without much resistance I crank the temp to 300 and start saucing and flipping them every few minutes until they look good, or until I can't wait any more, then pull and let rest for about 10 minutes.
Note: the ribs will turn out moist and tender but are not fall off the bone, (I'm not a big fan of fall of the bone ribs, I prefer a little tug)
I used to put water in the chafing tray but that added too much moisture into the cooker and mold would form in the cooker between cooks, but the ribs were a little more moist.
My method on a BGE, similar to GD, is as follows...
Note: I cook baby backs.
1) Peel membrane from back of ribs.
2) Pat ribs dry with paper towel.
3) Rub ribs liberally with yellow mustard, (important for moist tender ribs)
4) Apply a rub, in my case mostly turbinado sugar, sp?, mixed with salt and other spices, never the same twice, I'm still working on that.
5) Place ribs vertically on an upside down V-rack trying to leave space between the ribs.
6) Take a small disposable chafing tray and cover top with foil pushed about 1" into the chafing tray to catch grease. The dead air between the bottom of the chafing tray and top of foil keeps the grease from burning.
7) Sandwich chafing tray between upper and lower grill.
8) Place ribs in upside down V-rack on upper grill.
9) Cook ribs for 4 hrs at ~225 deg. F grill temp. (Sometimes I flip the ribs 2 hrs into the cook so they cook a little more evenly but usually not)
10) At 4th hr. I pull ribs from V-rack and lay flat on grill and flip every 15 minutes. and stick a wood toothpick in the meat. When the toothpick slides in and out without much resistance I crank the temp to 300 and start saucing and flipping them every few minutes until they look good, or until I can't wait any more, then pull and let rest for about 10 minutes.
Note: the ribs will turn out moist and tender but are not fall off the bone, (I'm not a big fan of fall of the bone ribs, I prefer a little tug)
I used to put water in the chafing tray but that added too much moisture into the cooker and mold would form in the cooker between cooks, but the ribs were a little more moist.
To tell the truth I have never tried cooking ribs without the sand. I used to cook ribs at 225 for roughly the same amount of time that you stated but started cooking at 275 for 3 hours after getting Dr. BBQ's book. Ribs seem to be just as juicy. Oh, I guess I should have mentioned that I place the ribs bone-side down. I also make sure that the Stoker grill temp probe is always attached to the top grate in an area that is over the sand.
Amir,
This place has been pretty quiet lately, so I thought I'd give you some more feedback on the StokerLog. I've cooked a little last week and experimented a bit the connection problem. If I purposely make the Stoker loose contact with your program, I could find no way to ever get it back without re-starting your app. What is interesting, is that, I can force a refresh (F5), and even change the target temp and do an update. The section effected seems to be the logging function only.
Ken
This place has been pretty quiet lately, so I thought I'd give you some more feedback on the StokerLog. I've cooked a little last week and experimented a bit the connection problem. If I purposely make the Stoker loose contact with your program, I could find no way to ever get it back without re-starting your app. What is interesting, is that, I can force a refresh (F5), and even change the target temp and do an update. The section effected seems to be the logging function only.
Ken
Jeff Hartford
New member
Amir,
Thank you for the terrific program!!!
It makes it so much easier and more fun to work with the stoker. Love the new alarms.
If you are looking for possible future features here is an idea: Add up/down click buttons for the target temps etc. That way much of the program could be used with mouse only, or a touch screen monitor.
Thanks
Jeff
Thank you for the terrific program!!!
It makes it so much easier and more fun to work with the stoker. Love the new alarms.
If you are looking for possible future features here is an idea: Add up/down click buttons for the target temps etc. That way much of the program could be used with mouse only, or a touch screen monitor.
Thanks
Jeff