@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?

As a disclaimer, I'm not a programmer by any means, but I'm learning. I have OpenHAB setup and working and haven't touched the setup in about a year. I'm using MySensors with two sensor nodes currently. They are both powered (not battery) and only capturing temp and humidity values and sending to my serial gateway via NF radios.

Hardware is currently RPi and Arduino UNO GW, and Nano sensors. I would like to expand my setup and include some additional sensors. I'd like advice on moving forward.

1. I had problems getting the sensors working initially. I had to set the Node ID's manually, which I believe is a limitation of OpenHAB. I also could not for the life of me get the measurement units to work in °F. I had to somehow manually set each node to send in °F as opposed to °C. I would like to have this work correctly if possible from the get-go.

2. I would like to battery power my arduino sensors. I plan to replace my current hardware with Arduino Pro Mini 3v (8MHz) with the low power mods done. The gateway will likely be run on a Nano instead of the UNO. My current goal is to have four types of sensors: (1) Temp/Humidity, (2) Servo - Blinds, (3) Door, (4) Light Level. I hope to have these all be able to run for an extended period of time on battery power only. The servo for blinds will probably be the most difficult to do this, however I have some ideas.

3. I would also like to be able to integrate other wireless technologies. I currently have an Aeon Labs Z-Stick 2 for Z-Wave devices (although I don't have any Z-Wave devices to test/use currently), and I have my eyes on a couple Zigbee devices that I would like to be able to incorporate. What is the best way to do this?

Any advice on how to move forward would be appreciated. It looks like there isn't a whole lot of activity in this forum, but many people who are using OpenHAB with MySensors. I'd love to get feedback before re-inventing something that is already done.

Glad you got yours working. I tried changing the code on mine to see if it would respond, but it didn't. I may have hard coded the sensors to imperial though. I believe mine is catching the I_CONFIG variable, because I would get an output on the console when the sensor started up where I had a println command. Hopefully it was just my syntax that was wrong.

On another note, can you trigger a "sendCommand" with xxx;255;3;0;6;<I or M> at any time, or can it only be in response to the request from the sensor node?

I was able to see the request come into the gw on mine, however I'm not sure how the reply should be structured given the sensor node is 101.

@Chester good point, but I was restarting the arduino and still couldn't get this to work correctly. Also, the missing "end" was just missed out of the paste here, it was in my code.

@Jan-Gatzke I'm not sure that I understand what you mean. Maybe you're referring to the + after status? If so, I think you may be right, but I would assume that will only affect what is printed in the console, and not what is sent to the remote sensor. In the example above, I believe that 101;255;3;0;6;I\n would be sent if the switch was on, and 101;255;3;0;6;M\n would be sent if the switch was off.

I believe that most of my problem is trying to figure out what should be sent to the remote sensor to enable this. In the above case, my remote sensor is ID 101. Ideally, I'd like to send the message to all sensors, and not just a certain node ID. Would that be 255;255;3;0;6;I\n?

At one point, I thought I had this working, but it wasn't repeatable.

@5546dug That's an interesting build. I've come across several using a PID controller similar to that, however they have mostly been on electric smokers. My original intent was to do a PWM fan that could be speed controlled, but it was very hard (impossible) for me to find a blower type fan that was PWM-capable. My very initial testing showed that an on/off model would work as well but I haven't tried this on the Big Green Egg yet.

My main concern is being able to feed a temp from my phone back to the arduino controlling this, and being reliable if for some reason wireless connectivity was lost from the arduino. I don't think this should be too hard, but will probably take some trial and error on my part.

@BulldogLowell
That looks like an interesting project as well. This originally started very similar to that one, and I was planning on using a local LCD on it for the display. I quickly realized that the local LCD would not give me the "warm fuzzy" that checking this remotely would give me. When I started going towards a web interface design, I then realized that I really didn't need the local LCD at all.

I'm not at all good with the programming piece, but I've gotten by so far. We'll see how this works out.

Below is a very rough sketch of what I have so far. This is not working or tested even yet, but it does compile in Arduino IDE. I will breadboard the sensors I have in the next couple of days and get the basics working, then I will have to figure out how to send the temperatures over to my gateway. Next will be configuring for receiving commands from the gateway/controller to allow me to set my target temperature on the Arduino. Any recommendations are welcomed.

This program is my attempt at creating a BBQ controller for my Big Green Egg using
an arduino to monitor grill and meat temps as well as control a fan to
regulate the grill temperature.

Components used:
- Arduino UNO
- 10CFM Brushless DC Blower
- Level Shifter
- K-type Thermocouple
- K-type Grill Probe
- K-type Meat Probe


Pin assignments:

*/

/*
Tasks:
- Selftest
  - Fan 0-100-0
  - Check for Probes

- Set Grill Temp

- Setup Display
  - Grill Temp
  - Probe 1
  - Probe 2
  - Fan Status
  - Elapsed Time

- Measure Temperature
  - Grill
  - Probe 1
  - Probe 2

- Analyze Temperature
  - PID Contol

- Control Fan
  - PWM Value
  - On/Off

*/

//-------------------------------- Classes ------------------------


//-------------------------------- Includes -----------------------

#include <MySensor.h>
#include <OneWire.h>
#include <DallasTemperature.h>
#include <SPI.h>
#include <PID_v1.h>

//-------------------------------- Defines ------------------------


#define oneWirePin 9
#define TempPrecision 9
#define MAX_ATTACHED_DS18B20 16

OneWire oneWire(oneWirePin); //Setup oneWire instance to communiate with any oneWire devices
DallasTemperature sensors(&oneWire); //Pass our oneWire referenceto Dallas Temperature.
DeviceAddress Probe0, Probe1, Probe2, Probe3; //Define arrays to hold device addresses.
MySensor gw;
unsigned long SLEEP_TIME = 15000;
float lastTemperature[MAX_ATTACHED_DS18B20];
int numSensors = 3;
boolean receivedConfig = false;
boolean metric = true;
MyMessage msg(0,V_TEMP);

void sketchInfo () {
  gw.begin();
  gw.sendSketchInfo("Temperature Sensor","1.0");
}

void setupProbes () {
  sensors.begin();
  sensors.getAddress(Probe0, 0);
  sensors.getAddress(Probe1, 1);
  sensors.setResolution(Probe0, TempPrecision);
  sensors.setResolution(Probe1, TempPrecision);
}

// Cycle fan from 0-100-0% power over 10 seconds.
void selftestFan () {

}

// Verify which probes are connected and report status for 10 seconds
void selftestProbes () {

}

void printTemperature(DeviceAddress deviceAddress)
{
  float tempC = sensors.getTempC(deviceAddress);
  //Display Temp in °C
  //Serial.print("Temp C: ");
  //Serial.print(tempC);
  //Display Temp in °F
  Serial.print(DallasTemperature::toFahrenheit(tempC));
  Serial.print(" F ");
}

void printData(DeviceAddress deviceAddress)
{
  //Serial.print("Device Address: ");
  //printAddress(deviceAddress);
  //Serial.print(" ");
  printTemperature(deviceAddress);
  //Serial.println();
}

void sendTemps () {
  for (int i=0; i<numSensors && i<MAX_ATTACHED_DS18B20; i++) {
    float temperature = static_cast<float>(static_cast<int>((gw.getConfig().isMetric?sensors.getTempCByIndex(i):sensors.getTempFByIndex(i)) * 10.)) /10.;
    gw.send(msg.setSensor(i).set(temperature,1));
    lastTemperature[i]=temperature;
  }
 gw.sleep(SLEEP_TIME);
}
  
void setup() {

  Serial.begin(9600);
  sketchInfo();
  setupProbes();
  //selftestFan();
  //selftestLCD();
}



void loop() {
  // put your main code here, to run repeatedly:

  gw.process();
  sensors.requestTemperatures();
  printTemperature(Probe1);
  printTemperature(Probe2);
  sendTemps();
  //readTemps(Probe0);
  //readTemps(Probe1);
}

I'm in the process of building a BBQ temp controller, and was trying to figure out the best way to remotely monitor/control it. After coming across this website a month or so ago, I'm now running OpenHAB on a RPi2 and have a couple temp sensors deployed around my house.

This project is a little more involved, and I'm sure I'm going to run into roadblocks along the way. My goal is to have a sitemap in OpenHAB that will allow me to set and monitor my desired grill temp, which will control a small fan on my BBQ using a PID algorithm, as well as display the temps of the meat probes so I can know how things are going.

I currently have the sitemap setup in OpenHAB, and have had the code working for the thermocouple temp probes that I will be using for the grill and meat temps. Today I will start trying to get the two to work together, based on the MySensors Serial API. I'll be using the NRF24L01+ radio modules for this. I'll post my code periodically, and hopefully will have some chime in on how to make it work or improve it.