From eBower Wiki
Revision as of 08:13, 5 July 2014 by Jdbower (talk | contribs) (Jdbower moved page Stoker to Cooking/Stoker)
Jump to: navigation, search

The Stoker is a Power Draft Controller.

Stoker Architecture

The Stoker is really just a small, microcontroller-based computer system. As such, it's a fairly flexible device that can be used and abused however you see fit.

Basic Theory

When you're using a barbecue you can control the temperature by controlling the fuel or by controlling the airflow. With gas grills, you control the fuel. With charcoal, you control the temperature (and add tasty flavors!). Traditionally you have two dampers you need to set, one near the bottom to let air flow into the cooker and one near the top to let hot air escape. Adjusting these two correctly in a proper cooker like a Komodo Kamado means that you can get a precise and stable temperature. But often people end up "chasing the dragon" - adjusting the dampers, letting it get too hot, adjusting again until it cools off and then the fire goes out, then you make it too hot again, and once you get things perfect your cooker gets heat soaked and changes the fuel consumption rates so you need to adjust again.

The Stoker makes this much easier. It consists of a temperature probe (called a pit probe) you put near the meat. It gets associated with a blower, essentially a fan you mount to the side of the cooker. Now you crack the top damper a bit and close off the bottom damper. When the temperature is less than the set temperature the fan turns on. When it's higher, the fan turns off. The logic is a bit more complicated than this, but after a while your Stoker will learn your cooker's details and be able to maintain a steady temperature. On my nicely insulated Komodo Kamado I see temperature fluctuations of about +/-1 degree - better than most electric ovens.

In addition to basic pit temperature control, you also get meat probes. This lets you set alarms and get visibility into your cook and essentially replaces all of your wireless temperature probes but technically they aren't a necessary part of the Stoker.


The Stoker Consists of a small metal box with a wired Ethernet port, a power switch, and a bunch of 1/4" jacks. There's a reset button and a front panel display with a few selection buttons. Additionally, the WiFi version has a large antenna. The device itself isn't waterproof, but it does seem to handle humidity and the occasional sprinkle well.


The probes are accessed via an I2C (like?) controller which means that the probes themselves need an identifier by way of a small circuit in the probe connector. Modern probes also include a controllable LED to allow for remote visual notifications, older probes lack this. There is no functional difference between a pit and a meat probe, but a meat probe is long and sharp while a pit probe is short and blunt. The nice thing is you can add multiple probes via standard splitters, the probe ports provide a common bus for them. Unlike the BBQ Gurus this allows for a lot more expansion ability far beyond what you'd need unless you're a competition cooker.


Blowers should be plugged directly into the unit. The power is drawn from the unit itself over the probe ports, since the blowers require a lot of power putting multiples on the same "circuit", having extended cables, or splitters could compromise the power supply. The Stoker also supports multiple blowers for multiple cookers, but this may mean that you should get an upgraded power supply.


The power input is 5V and the case is labeled as 2A, however it seems like additional power may be able to be supplied through the probe ports. I have yet to find a spec as to how this is done or what the limits are. I may dissect one to find out.


The software is produced by Kaytat but development seems to be stalled. The software is fairly feature rich and it's a simple product, this isn't necessarily a dead end.


There really is none. This falls into the Internet of Things security nightmare category. Something like Shodan can discover Stokers on the Internet. Since there is no username/password control anyone could just log into one and set the pit temperature to 1000 degrees. There is no great way to fix this on the box itself, but you can abuse your NAT to have a minimal number of controls. Assuming nobody has breached your network (a bad assumption) you should never open up firewall ports to the Stoker. There is one use case where this can work, by hitting the /ro.html URL you can change the web interface into read-only. Only when this is done could you open up the Stoker's web interface to the Internet with some modicum of security.

The better bet is to install a proxy. Use a machine on your network to control the Stoker. This can be via software like Stokerlog and an RDP session into a Windows box or Pit Pal and a remote login into an Android device. I'll also be rewriting stoker_mon since neither of these options are very palatable to me.


Here's the good news: the Stoker will grab a global IPv6 address if needed.

Here's the bad news: the Stoker relies on a NAT for security.

Here's the mitigating news: there isn't a great way to find the IPv6 address the Stoker has besides telnetting in and running ipconfig.

Front Panel

You can actually do anything you want from the front panel UI. You can set basic information like the probe temperature targets, assign a pit probe to a blower, and (perhaps most useful) view or set the IP address. You can't set up the WiFi network, so you do need a wired connection to start with.

Web UI

Many of the URLs are not linked from the main page so you need to hunt around the Interwebz to find them. If you go to http://[stoker_ip]/ you get the base page which is a simple table of the probes and blowers you've got installed and their names/states. There are also the following pages I've found:

  • /ro.html I would highly recommend hitting this page, it lets you password-protect changes to the probe settings. Note that the password is sent in plaintext and it's hardly a highly secure method, plus it doesn't protect you against other exploits on other services, but it's better than nothing.
  • /wifi.html This allows you to set the WiFi parameters. There isn't much in the way of nice features like scanning networks, but it works. Note that WPA is called "PSK" (Pre-Shared Key) here.
  • /twitter.html This is deprecated since they can't implement OATH-based authentication and the API proxy was shut down.

Telnet Interface

There is a telnet interface into the Stoker which seems to be the fastest way to get data.

WiFi Behavior

The interface used to have a username/password of "root/tini" which should give you access to just about anything you want to do, but now it seems to just automatically log in and scroll data similar to the bbq -temps command but ignoring any attempt to run bbq -k. The format of this output is described here.

420000127E79E330: 3.0 23.9 75.0 -5.0 -0.1 0.9 0.8 23.8 74.8 
370000127E6A0130: 3.0 24.6 76.3 -5.6 -0.1 1.0 0.8 24.1 75.4 PID: NORM tgt:121.1 temp below low threshold blwr:on

420000127E79E330 is my meat probe. Most of the numbers can be tossed, but the last two entries are the current temp in C followed by the temp in the user defined units. The other values are anyone's guess as they're all debug (although some are suspiciously close to the current temp).

370000127E6A0130 is my pit probe. The first part looks the same as my meat probe, but you can see here that we're:

  • NORM state, this could also be TEMPORARY DELAY for disabling the fan when you open the lid.
  • Targeting 121.1C (250F).
  • below threshold, but this could also include:
    • Debug messages err:[int] drive:[int] istate:[int] AND
    • on:[on_pct] where [on_pct] is an integer representing 1/10th the percent of time the blower is on (1 means 10%) AND
    • off:[off_pct] where [off_pct] is an integer representing 1/10th the percent of time the blower is off (9 means 90%)
  • blwr:[current_blower_state] means the blower is on or off.

As you can see, the information here is very limited. There are no probe names or meat probe target temperatures - just raw data. This may be the best way to get fed information from the Stoker asynchronously, but you'll want to use the web/JSON interface to get and set data.

While this seems to be a fairly secure method of doing things, the fact that it logs in seems to indicate that I wouldn't trust that you can't escape into the shell and execute commands.

Wired Behavior

Here root/tini seems to work on the telnet interface.

  • ipconfig gets and sets the IP information.
ipconfig [options]

Configure or display the network settings.
 [-a IP -m mask]     Set IPv4 address and subnet mask.
 [-n domainname]     Set domain name
 [-g IP]             Set gateway address
 [-p IP]             Set primary DNS address
 [-s IP]             Set secondary DNS address
 [-t dnstimeout]     Set DNS timeout (set to 0 for backoff/retry)
 [-d]                Use DHCP to lease an IP address
 [-r]                Release currently held DHCP IP address
 [-x]                Show all Interface data
 [-f]                Don't prompt for confirmation
  • ping is an ICMP ping
ping [-c number of pings] [-t ttl] [-W timeout] HOST 

Sends ICMP ECHO_REQUEST packets to network hosts.
  • reboot reboots the system
reboot [options]

    [-f] Don't prompt for confirmation
    [-h] Clear heap on reboot
    [-a] Clear heap and system memory on reboot
  • stats shows the uptime, memory, and daemon status.
  • bbq the Stoker Daemon
bbq - Run bbq
-k Kill the current instance of the stoker
-temps Force the current instance of the Stoker software to output tempeatures to the terminal
-t Enable the temperature output
-dbg_all Enable all debug output
    Enable module debug.  More than one can be specified.

There are also some hidden commands:

  • java can be used to run some Java code
java [OPTIONS] FILE [&]

Executes the given Java class.
'&' indicates a background process.

   where OPTIONS includes:
-classpath ARG     Sets the classpath for the new process.
-bootclasspath ARG Sets the driver/boot classpath for the new process.
-DPROP             Gives the new process a system property PROP.


There is a JSON API at /stoker.json. The output of this is the following:

{"stoker":{"sensors":[{"id":"370000127E6A0130","name":"Pit Probe","al":0,"ta":250,"th":32,"tl":32,"tc":74.8,"blower":"C900000012027F05"},
{"id":"420000127E79E330","name":"Meat Probe","al":0,"ta":195,"th":32,"tl":32,"tc":74.2,"blower":null}],
"blowers":[{"id":"C900000012027F05","name":"10 CFM Blower","on":1}]}}

The reformatted output of this is as follows:

            "name":"Pit Probe",
            "name":"Meat Probe",
            "name":"10 CFM Blower",

To repeat the object definition: Stoker object contains two other objects

First object is called “sensors”

  • “sensors” object is an array of sensor entries. Each sensor entry has:
    • id – 16 character serial number
    • name – User defined name
    • al – alarm, which can be 0, 1, 2
      • 0 – no alarms
      • 1 – Target
      • 2 – Fire hi/low
    • ta – Target temperature
    • th – Fire high
    • tl – Fire low
    • tc – Current temp
  • blower – 16 character serial number of the blower, if any. If no blower, then the value is null. The second object is called “blowers”, an array of blower entries. Each blower entry has:
    • id – 16 character name
    • name – User defined name
    • on – 0 for blower off, 1 for blower on

You can also call /stoker.json?version=true to see the current software version.

Finally, a POST may be used of a JSON entry, expect a 200 for a success and a 400 for a fail.

Oddly, the JSON API seems slower than the web API somehow.