Feature request? drop back temperature


 
J

John Case

TVWBB Member
I was wondering if it would be possible to have a temp setting to go to when the food probe reaches a certain temp?
Lets say I'm doing a pork butt, I set the food probe to 200 degrees. It would be nice if there was a box to set a drop down temp to.
If you set it to 0 (zero) it would shut down the smoker, or maybe enter a temp to keep warm at maybe 170 degrees.

For a longer smoke especially where you may not be watching it as closely, or even a short cook where you're enjoying too much of your home brew :rolleyes: the smoker would drop back to whatever temp you want.

What do you think?

EDIT:
I do realize that this can be accomplished by scripting, but for us non programmers it might be a nice addition. Nothing fancy, just a drop back temp.
 
Last edited:
There is a controller out there that boasts to be the only controller with the "ramp and hold" feature that will back the pit down to a holding temperature when the food has reached the target temp. I kinda get a laugh out of that, cause the HM is WAY more versatile than that controller. I'm thinking it would be nice to build this feature into the HM (without requiring scripting) just to take the wind out of that sail...
 
Yeah it has been on the TODO for a long time. I do it with a script and haven't touched it since then so it isn't a really big priority for me.
 
Bryan, sometimes you take for granted your knowledge of the HM and programming in general and assume things are done easily enough, but what you view as easy is way over other peoples heads. I know it's not difficult to copy and paste in this script, but a lot of people are CLUELESS and afraid to mess with things like scripts.... (not suggesting Mr Case is one of them)

Another example, recently I had asked if the new feature "run fan at 100% only" could be changed to allow the user to select at what percent the fan turns on (rather than being hard set at 100%). You replied that this can be accomplish with PID tuning. While you're certainly correct, PID tuning is a PITA to most people, very time consuming and hard to understand. I have been using the fan plus servo mode for a while now and I have seen it cycle from 100% with the fan blowing to something below with the fan off, then slowly ramp back to 100% and run the fan briefly, and repeat over and over. Meanwhile it is taking way too long to reach the target temperature, which could be achieved much quicker if the fan would just stay running a bit longer. I poked around with PID settings for a while and so far haven't really nailed it down yet. It would be SO MUCH EASIER for me and most other people if I could just tell the fan to run above say 95% instead of having to do special PID tuning to achieve the desired result. Perhaps to you changing PID settings is an easy solution, to most other people it would be way easier to just select the % when the fan should come on.... Reason being, we see the fan running (or not), we see the % the HM is running the damper/fan.... when the pit is still way too cold and the fan turns off when the damper moves to 96% we WISH the fan were still running. These are real world things we can see happen and understand much easier than PID tuning... To you what is under the hood of the HM is real world info you can wrap your head around, to most people they only see/understand what is physically in front of them...
 
Last edited:
Oh I know it isn't exactly easy to script it, but I do have to prioritize things. The other half of not being a programmer is not seeing all the complexity of a situation.

"All I want" is a box where when the temperature reaches the a certain temperature the pit temperature ramps down. Does it key off the alarm temperature? Does the alarm still go off when it hits that temperature? Does it beep? Does it trigger the script as well? Do you get to enter any temperature you want? Where is that value stored? Does this occur on the HeaterMeter or from the linkmeterd? What's the UI look like? Does it fit on the config page that already has 900 items it? Does the temperature ramp down? What slope? Should it start before it hits the target temperature so it doesn't overshoot the temperature? How far below should it start? Is that based on time or temperature? Can this be on any probe? Why can't I also have it change the setpoint if the temperature goes too low? Can this be added in a way that won't f*&%k up the configuration EEPROM so everyone needs to reset their config?

Those are just the first questions that all have to be answered and that doesn't even include the actual implementation details. Find me a group of people who answer the same answer to all of those questions and then you'll know what direction to start going. Every time you answer "just add an option for" go back to square one and start again. I have other things to work on and if something works by requiring the user at least skim a couple paragraphs then paste a couple lines of text into a box, I think that's close enough for now. Like I said though, it is on my todo list and I'm glad I haven't done it yet because I've actually had a decent idea how it should be partially implemented in the UI recently in a way that integrates with all the other alarm settings. I'd hate to have implemented it already because then it would already be somewhat set in stone so the new way should be backward compatible in some way.

As for the fan % thing, you're saying that you've got like 13 different knobs you can use to control the output of the system and but you can't get those to work right so if there were just one more knob then everything would work perfectly. If the pit is still way too cold and you're at 96%, you should be at 100%. If your pit can't maintain temperature at 99% servo without the fan, you don't just need a boost in the N-100% range you need to use the fan the whole time and back down on your output.

Anyway it all comes down to time and wanting to have things done right. I can't drop everything every time an idea comes up and go work on that. I'd never get anything done. Most importantly I do this for fun so I want to have fun working on what I want to work on. That usually coincides with what users want. Sometimes I really want to do something, like the alarm setup page, but I've already taken a few stabs at it and not been pleased. I put it aside and come back to it with a fresh outlook later.
 
Last edited:
I completely understand all those points, and appreciate WHATEVER you decide to implement or not in the HM, cause I love my HM even if it doesn't have every setting or bells and whistles I or anyone else may request....

...but you kinda made my point with your answer in a way, your head is very wrapped up in all the under the hood aspects of all this and therefore it is hard for you to see things the way regular HM users do. What is intuitive to you may be counter intuitive to an average user because you have all the background information in your head. The end user just knows what they want the thing to do...

I could certainly throw out answers to most of the questions you raised pretty easily, whether my answers will be the same as the next guys or completely based in reality is another thing, so point taken.... Still I think a set of "reasonable" answers could be compiled that would be doable and satisfy most everyone.

The bottom line on everything I suggest to you is they are SUGGESTIONS, something to keep in mind as you move forward with development and may have the opportunity to implement some of them.
 
Bryan,
Was just hoping to open up a little discussion and if it seems like a good idea, have it added to a todo list.

Thanks,

John
 
I can totally sympathize with Bryan on being wary of adding new features because of the work to integrate them well. I have spent WAAAY more time on PitDroid tweaking the UI than actually getting the internals working. I had the admin stuff done in an hour or two, but I spent at least a full day trying to figure out how to best expose it to the user. Writing good internal functions is fairly easy, because in general you know the input and output. Dealing with humans is terrible though, because there are so many ways they can screw things up. I actually do enjoy trying to make a nice UI, but it is definitely a lot of work too.

(Oh, and to be clear, I'm not trying to hold PitDroid up as a shining example of excellent UI, I'm just saying I've put some effort into making it not total crap!)
 
Colin Bonstead said:
I can totally sympathize with Bryan on being wary of adding new features because of the work to integrate them well. I have spent WAAAY more time on PitDroid tweaking the UI than actually getting the internals working. I had the admin stuff done in an hour or two, but I spent at least a full day trying to figure out how to best expose it to the user. Writing good internal functions is fairly easy, because in general you know the input and output. Dealing with humans is terrible though, because there are so many ways they can screw things up. I actually do enjoy trying to make a nice UI, but it is definitely a lot of work too.

(Oh, and to be clear, I'm not trying to hold PitDroid up as a shining example of excellent UI, I'm just saying I've put some effort into making it not total crap!)
Click to expand...

Colin,
Thanks for developing PitDroid, I use it on my smokes to monitor temps.
 
You must log in or register to reply here.

 

Back
Top