The Development Log


 
Bryan,

Thanks for taking the time to explain Imremote to me....

I understand what you are saying to a point, what I do not get is the need for battery operation. The way I see it, out at the grill you need a fan and/or servo damper, if you need to power them with a wall wart then why worry about having the probes run on battery? If perhaps you are just measuring temperature, like a weather station, I totally get it, but once you move it to the grill and add the fan/servo and power supply I see no benefit to the battery (unless you are running the fan/servo on battery too?) I mean, if you have a PS there for the fan, why not just power the remote board with it?

This train of thought is why I ran into the idea of just using two HM boards, cause if you take the Imremote board and add the servo/fan function to it and power it with a wall wart you pretty much have a stripped down HM.

Beyond that, if you do run a stripped down HM board at the grill, programming it should be easier because you could plug the grill side HM into the rPi to program it, then disconnect it and put it out at the grill. You could still have two sets of code (one for the main HM and the other for the grill side HM), just choose the right code to flash to each unit then open up the configuration page and tweak your settings and you're good to go (in my fantasy scenario! LOL)....
 
Last edited:
I guess I don't understand the additional complexity of all this. If like you said, you've got to have power at the smoker for a blower or servo, just leaving the HM out there seems a hell of a lot less complex than trying to strip it down only to remove the "expensive" part of the unit (the rPi). Personally, I just throw a ziploc over mine, or toss a tupperware or something over it and have yet to have any issues. Then again I don't try to cook in a squall like you guys. :)
 
Kyle Christensen said:
I guess I don't understand the additional complexity of all this. If like you said, you've got to have power at the smoker for a blower or servo, just leaving the HM out there seems a hell of a lot less complex than trying to strip it down only to remove the "expensive" part of the unit (the rPi). Personally, I just throw a ziploc over mine, or toss a tupperware or something over it and have yet to have any issues. Then again I don't try to cook in a squall like you guys. :)
Click to expand...

Well, the idea is to get a unit that can be left out at the grill. The HM itself is a fairly hearty unit, add the rPi and SD card etc and not so much. I think a stripped down HM with no display and no rPi could be put under some sort of rain hood and left out at the grill and it would survive. If it were wireless capable then you would be good to go. I do use the HM rain or shine, probably 4-5 times a week, and would really like my grill end to be setup and left alone if possible. I know the probes are a bit sensitive, and should be kept out of the rain, but it's not too tough to place them in a spot that will stay dry, and the heat from the sun isn't a problem for them like it is for the HM. I am (still) waiting on the high heat thermistor that Vishay said they would send to me (sample), if it works out I plan on building it into my grill and then I wouldn't need a (regular) pit probe at all. As it is I often just pull in the HM unit at the end of a cook and leave the fan, servo and probes outside, power supply too, so far so good with that....
 
Last edited:
RalphTrimble said:
... I do not get is the need for battery operation ... perhaps you are just measuring temperature, like a weather station, I totally get it, but once you move it to the grill and add the fan/servo and power supply I see no benefit to the battery
Click to expand...
Exactly! If you're just measuring the temperatures, then it is coolest to run on batteries. The lmremotes I have are smaller than the maverick probe itself and I could create a case for it (now that I have a 3D printer) which would make the whole pit probe 3" long x 3/4" wide x 1" high. No wires running to the pit probe that get in the way every time you open the lid. Also works for food probes on rotisseries which would otherwise get all tangled up.

I see that as being more useful than separating the input/output from the controller, but to each his own.
 
I don't have a rotisserie, never thought of that, fully wireless/battery operation certainly is a plus for this application. I don't quite get how a pit probe could be completely wireless though, how do you get the probe into the pit in a proper location without getting the entire package (Imremote and case) into the pit? Guess I am having a hard time visualizing what you are doing....
 
Well then a picture is worth 1000 words.


This is all the parts (sans battery) in place. The whole thing just hangs on the bent part of the probe. I was going to make a board with all the parts on it but never got around to it because I couldn't find the right size case for it. It's now something that's moved up to my back burner now that I have a printer to make the case, but not really a high priority.
 
OK, now I have the visual of what you've got going on, thanks....

...but that brings me back to round to asking about powering the fan and/or servo... I assume you have to power them with a wall wart, so the battery powered probe isnt getting you away from the wall wart anyhow....

The way I was envisioning the system would be a built in probe (or thermistor) that has a wire running to the board, which I would mount under one of the shelves. The board would power the servo and fan (therefor require a power supply) and the pit probe would stay connected to that. I figured an open bottom case would keep the rain from hitting the board so I could leave it outside. So, a stripped down HM board with an RF link seemed like the obvious way to go with this scenario....
 
Yeah the HeaterMeter unit with the fan still is plugged in, just the pit probe wire doesn't get in the way of working in the grill in that setup. With the lid up the wire normally dangles down right in the way. Not a big deal but I could see it being more useful if someone had a lid on their BBQ that they remove entirely when working on their food.

Last night I started learning a new javascript library I want to bring in to simplify a lot of the webui: knockout. I played around with making some classes for the config data which I'm hoping will eventually lead to an easy alarm editor and will eventually work it's way into the home page. Ugly UI here but maybe you can see where this is going
 
Bryan Mayland said:
Last night I started learning a new javascript library I want to bring in to simplify a lot of the webui: knockout. I played around with making some classes for the config data which I'm hoping will eventually lead to an easy alarm editor and will eventually work it's way into the home page.
Click to expand...

Quickly looking at this toolkit it seems that this would help with separating the ui from the logic, making it easier to integrate different views based on browser, ie iPhone/Android devices vs desktop browsers.
 
Work's got me pulling 11 hour days so by the time I get home there's not much energy for doing side projects. Just one more week of that.

I changed the light page at /luci/lm/light to have the ability to change the setpoint (if you log in) and it refreshes every 10 seconds if not logged in, 30 seconds if logged in. The longer refresh is because it can be insanely frustrating to try and type in a new setpoint while the page keeps refreshing. Before you say "Can't you just pause the update if the user is editin..." NA! No javascript on that page
emot-colbert.gif
 
I know I often say I redesign the heatermeter home page then throw it out, but why not post them? I did this while trying to get a VPN connected last week. The outputs would have bars like the current version does, and obviously it is just a rough outline. The overwhelming thing I want to do is get rid of the need to go to the configuration page so everything would be done right from the home page. The little Vs on each of the probes would drop down a menu to allow you to set the alarms, probe configuration, show/hide, etc.

Not sure how much I like this design, seems a little too white. Maybe if some icons were added and a slideout sidebar for jumping to network/email config or something, or maybe I'll just abandon it.
 
Very clean & modern looking. I like this vs current homepage, but I'm a form follows function guy, not an artist (stick people are fine with me...) Config on-page would be nice as well.
 
From a purely selfish perspective. I'd like to see most of the elements on the main page be shown/hidden via slideToggle calls. Being able to just see the pit temp and large graph would be nice.

Also, after stumbling upon the HM being able to calculate approx cooking time based on the high temp alarm value on a meat probe, I think it would be really neat to say "I'd like this cook done in X hours" and have the HM make pit temp adjustments in order to achieve the desired cook time. It could make hourly adjustments to slowly ramp up the pit temp and could have a "not to exceed" maximum temp.
 
Last edited:
I really like that idea to set a target time, that's something we're all doing in our head anyway. I'm not sure how well that would work though given the stall and how much you can change the temperature without affecting the food temperature that much. It might be possible though, so I added it to the TODO list.

A problem I have with this web design is that it isn't very touch friendly, everything is too close together. The page is also too short for portrait mode and too tall for landscape mode so you either get a lot of blank space or the graph gets cut off.
 
Another request to help with touch screens - In the graph range dropdown list, if you choose something less than 24 hours, it would be nice to have Previous and Next buttons that allow you to view the zoomed in graph in 1, 6, and 12 hour blocks at a time. This would somewhat overcome the inability to click and drag the overview graph.
 
You can't do that because there's no data. There's only 1 hour of data at the 1 hour resolution, etc. This may change at some point but I'll keep the scrolling idea in mind.
 
Back to lmremote, last night I finished splitting apart the receive sync code from the temperature measurement code. Instead of the temp getting measured every N receive intervals, it is now back to measuring on its own schedule independent of the the RF receive. Still need to move the fan and servo code into it, as well as be able to disable receiving completely.
 
Updated the base firmware image to support the newer rPi models with the "circle M" RAM chips.

Also tried out the new idea to put the blower MOSFET switch on the high side, which makes the blower ground now ground. Works just like I hoped it would! The smaller component doesn't have the same amperage rating as the existing part, by a long shot, but even without a heatsink it can push an amp without getting hot. Seems like it should be sufficient for our purposes, and it costs than the existing MOSFET costs even with the support components.

Actually all the ideas I had seem to be working, apart from the RJ11 footprint. The part I had picked is smaller, however it is so small I can't fit the 2.5mm jack into the same footprint. As luck would have it, I found another part that looks like it will fit on the RJ11 spot I have. If that's the case then the barrel jack can coexist. I used my Amazon Millions to order a handful of the new part so let's see how that goes.
 
Did a little more work on this, fleshing it out


I've also spent a bunch of time trying to get two bits of code (grillpid) to compile differently depending on the project it is in. This is something that is easy in regular C projects, but due to how Arduino builds the projects (copying the libraries first and building them separately) you can't have two different included conf headers. The conf file is in the project directory and is something that would "just work" with a -I. in a Makefile. I might spend a little more time on it but I might just resort to the solution I hate which is copying grillpid to the lmremote directory to build.

EDIT: Also switched to the SLUB kernel allocator in the kernel, which gives about 5-10% more I/O performance, not that we need it.
 
You must log in or register to reply here.

 

Back
Top