@wergeld said:

I have been working on this idea as well. My issue was finding probes that would survive the higher temps and run off a minimal power supply (batteries) - while still being cheap. It is the last item that has prevented me from moving forward. At the prices I have seen for temp probe/IC it is actually cheaper just to get a store bought meat thermometer with a remote display that is locked in. I suppose one could figure out their transmission protocol and port it to some radio receiver to an arduino. I have not even looked at making the grill react to inputs yet but I like that idea.

To me, this part is what sets this idea apart from others. For example, if you see that your food is cooking too fast, you could remotely turn down your cook temperature to slow it down a bit. Or you could script your controller to adjust the cooking temperature at a certain time or after a particular condition is met.

So here's my initial attempt at putting something together. Fair disclaimer, this was done while staying up all night doing a cook after being awake all day. I think it probably has a good overall structure of what needs to be done, but the content can be improved in almost every area.

EggCooker20160618.ino

I see a couple things needing to happen:

• Get reading from multiple probes
• Send readings to controller via MySensors formatting
• Get setting from controller via MySensors API for grill temperature setpoint.
• Use grill probe reading and grill temp setpoint with PID controller library to control fan

Hopefully this will get some discussion started. Any inputs on the best way to tackle this?

Also, how about a good name for this project?

I believe I purchased my probes from AuberIns.com. I see that they have a PID controller that can be used to control the grill temp, and it's fairly priced. What it doesn't do is give you a way to remotely monitor or set parameters, and it only has one probe to measure the grill temp.

What they do offer is a pre-configured blower with adapters for several different types of smokers. Buying one of these may be better than trying to fab your own.

@hek - glad to see some interest. I'll let this post settle for a couple days and see how much interest there is. I purchased all the components (probes, fan, etc.) some time ago, and never got around to finishing this project.

One thing I've learned about smoking over the years is consistency in temperature is the key. I started with a home built offset cooker that was near impossible to control. I then built a Stumps-style smoker after seeing them. That was way too big to be practical, so I moved on to a Big Green Egg, which I love.

Back on topic...I really hope we can get this going.

Re: BBQ Temp Controller Build

Although my time is very limited, I'd really like to get some more interest in this project and get some working code up for others to contribute to.

Background: I enjoy smoking different types of meat on my smoker, however it is always a challenge as some cooks can go as long as 12+ hours. When you expect to have guests over mid-afternoon, it means a really long night of monitoring and making minor adjustments to ensure temperatures stay where they should on both the smoker and the meat being cooked.

Goal: To build a temperature control system for charcoal/wood burning smokers that allows monitoring of the grill temperature as well as 1-2 probes for the internal temperature of the item(s) being cooked. It should be able to be integrated into a controller such as OpenHAB easily using the mysensors API. It should also have the capability to control a small fan which blows into the firebox of the smoker to increase the cooking temperature to a specified value. There are commercial versions of these, but if we are building home automation sensors and switches with arduinos, why stop there? Commercial versions can be found here or here.

Any takers to help develop this for others to use? I'm far from the best coder, but would love to get some help putting a working package together for others to use. My time is scarce these days, which is the main reason I keep putting off this project. If you're willing to contribute in some way, let me know and I'll post up my progress on the code and we can divide and conquer.

If there's no interest, I'll keep it on my project list and eventually try to work it out myself.

Eventually, the repeated requests seem to calm down and it works as expected. What I'm trying to figure out is why the repeated messages occur.

If I'm reading the code correctly, the only time the 'if(subType == I_CONFIG)' should be invoked is when the request for config units is made from the sensor node. I've confirmed that the sensor node only requests the I_CONFIG units once, and the gateway only receives it once. I can't seem to make sense out of why the gateway replies so many times...

It seems as if the problem I'm seeing is more with the controller/gateway than with the node. The gateway is sending out the I_CONFIG units repeatedly (like hundreds of times). The node is only requesting the units once.

That is why I'm not sure if it is a gateway problem or a controller (rules) problem. I can comment out the following section:

if(subType == I_CONFIG){
println("Request config units") 
sendCommand(Arduino, nodeId + ";" + childId + ";" + msgType + ";" + ack + ";" + subType + ";" + core_Units.state + "\n")
println("Sent measurement units:" + core_Units.state )
}

and the sensor node is no longer flooded with responses after it asks for config units. I'm just not sure why this is "flooding" the sensor node with responses.

I tried asking this on the OpenHAB forums, but I haven't received any feedback. I'm having problems properly sending the I_CONFIG value to my sensors.

Below is my "Arduino sends to Openhab" rule that I've added the I_CONFIG variable to:

rule "Arduino sends to Openhab"
when
Item Arduino received update
then
var String lineBuffer = Arduino.state.toString.split("\n")
for (String line : lineBuffer) {
var String[] message = line.split(";")
var Integer nodeId = new Integer(message.get(0))
var Integer childId = new Integer(message.get(1))
var Integer msgType = new Integer(message.get(2))
var Integer ack = new Integer(message.get(3))
var Integer subType = new Integer(message.get(4))
var String msg = message.get(5)
if(msgType == 1 ){
if (subType == V_TEMP){ 
postUpdate(sensorToItemsMap.get( nodeId + ";" + childId + ";"), msg)
println ("Temp item: " + sensorToItemsMap.get( nodeId + ";" + childId + ";") + " temp: " + msg )
}
if (subType == V_HUM){
postUpdate(sensorToItemsMap.get( nodeId + ";" + childId + ";"), msg)
println ("Hum item: " + sensorToItemsMap.get( nodeId + ";" + childId + ";") + " hum: " + msg )
}
}
if(msgType == 3){
if(subType == I_BATTERY_LEVEL){
postUpdate(sensorToItemsMap.get( nodeId + ";" + childId + ";"), msg)
println ("Battery level received: " + msg)
}
if(subType == I_CONFIG){
println("Request config units") 
sendCommand(Arduino, nodeId + ";" + childId + ";" + msgType + ";" + ack + ";" + subType + ";" + core_Units.state + "\n")
println("Sent measurement units:" + core_Units.state )
}
if(subType == I_SKETCH_NAME){
println("Sketch name: " + msg )
sketchName=msg
}
if(subType == I_SKETCH_VERSION){
println("Sketch version: " + msg )
postUpdate(sensorToItemsMap.get( nodeId + ";" + childId + ";"), sketchName+" " +msg )
sketchName=""
}
}
}

end

In it's current state, the sensor node gets repeated responses from the controller/gateway with the units (I or M), based on the value of the item Core_Units.state. I'm trying to figure out why this doesn't just sendCommand one time to the sensor node. The response received by the sensor node seems correct, I just get hundreds of them. Below is the output from my sensor node after requesting the I_CONFIG value from the controller:

read: 0-0-105 s=255,c=3,t=6,pt=0,l=1,sg=0:I

This appears correct to me. Any thoughts?

Thanks for that info. I'm sure I'm not the first that has thought of it, but I wonder if it would be possible to have the remote actuator "poll" the controller for a status and wait for a response? There would be a delay, but maybe there could be a compromise between battery life and lag in commands being carried out by the actuator.

I haven't looked, but maybe someone has tried this already...

I have been planning a build for a blind controller along with my openHAB/Arduino serial gateway. I currently have things running the the bench with a USB powered Uno. I was under the impression that this could potentially be accomplished using battery power on a pro mini.

I just read this post, and now I'm second guessing that this can be done. My plan was to power the arduino with 2AA batteries, and power the servo with 4 AA batteries.

Am I understanding correctly that having the remote actuator "listening" for commands from my serial gateway will consume batteries quickly? If so, is there any way around this?