Great idea for the enclosure, esp if the grill is exposed to the elements. Mine is under a leanto on my patio so I could expose the screen.
11F RTD temp on your grill??!!! And I thought it was cold here in Idaho! It’s like summer here compared to where you are.
BTW, did you use the TOF pellet bin sensor or ADC probes? I haven’t tested those yet, but they should work.
Ha, yeah and it gets colder than that. I made a makeshift windbreak out of old pallets to help shield the smoker and make its life a bit easier. It is under an overhanging roof off my house, but snow does still blow in there from time to time and I thought having a way to close it right in would be nice.
I think I’ll redesign a box with a touch more room in it, but a similar idea since this works quite well for my use case.
I don’t have a TOF rigged up, or the ADC, however I do have a couple ads1115 modules and so I’d like to see about getting that going sometime as that seems like a handy feature. I may get a larger unit in the future, at which point I’ll be more likely to add the TOF to it but not this little one.
I’ll report back when I get the extra adc on there, but maybe once I’ve redone the enclosure and given myself some more space to work in there. Oh, and you’ll notice I haven’t implemented any buttons or rotary encoder but I’d definitely like to especially with my current wifi issues.
Has anyone successfully installed the ADS1115 chip? Unless I’m missing something, it appears this PCB is sending 5V directly to the ESP32 SDA and SCL lines. I think there needs to be a level shifter incorporated into the PCB to safely step the signal down to 3.3V for the ESP32. I am measuring 3.8V and 4.1V on the GPIO9 and GPIO40 pins with the ADS1115 installed.
It also seems to me that the MAX6675 should be powered by 3.3V instead of 5V to keep the shared SPI bus safe.
I’m definitely not an expert here. I’ve just been spending the last several hours troubleshooting the ADC board with Gemini, and this is the conclusion I came to. Am I overlooking a hardware feature on this board?
I’ll be perfectly honest here. I added the adc board as an optional component and only briefly tested it - my bad if it’s not wired right. I figured folks might want such a feature and thought I wired it correctly.
I use RFX wireless temp sensors and only briefly played with the ADC sensor. I can say the same for the TOF sensor. One day I’ll add that sensor. I can vouch for the rest of the board tho… I’ve cooked a dozen briskets successfully 
The max6675 works fine the way it is, The MAX6675 thermocouple-to-digital converter operates on a supply voltage of 3.0V to 5.5V , making it compatible with both 3.3V and 5v.
Brilliant! I knew someone would run with this and improve it. Looks great!
Lets see it in action once you install it. looks like you used the firepot temp sensor as well? You’ll really appreciate the auto relight routines after your first flame out 
It also looks like the TOF sensor works - fantastic!
The probes… I hope you have better luck w/ those than I did. The ADC chip is key because the ADC on the ESP absolutely sucks, but you’ll really have to get calibration data for the probe type you use. Boiling water and ice water tests will only get you so far… let us know how you make out.
I’m totally stealing your new UI
oh, btw, there’s a bug in the fan shutdown routine. I finished a cook a few days ago and came out in the AM and the fan was still running.
I have so many other irons in the fire I haven’t looked at that yet. I’m sure it’s something simple.
I work next to the metrology lab at work. I can probably toss them in the bath sometime to get the precise values. Or just get a few rough values and see if I can figure out what the curve should be.
As for the fan shutdown bug here is what Claude has to say about it.
"Bug #1: Infinite loop in on_turn_off handler
When the fan switch is turned off and the grill is still hot (>175°F), the handler immediately
turns the fan back on and also calls sc_shutdown. This means you can never manually turn off
the fan while the grill is hot — it fights you.
Bug #2: Double state management causing race conditions
After turning the fan back on, there’s a switch.turn_on followed 1 second later by a
publish_state(true). These redundant calls can cause state inconsistency between the actual
GPIO and what ESPHome/HA think the state is.
Bug #3: The sc_shutdown script recursively calls itself
It runs fans → waits 20 minutes → if still hot → calls sc_shutdown again. This is actually
intentional behavior (cooling loop), but combined with Bug #1 it means the on_turn_off handler
and sc_shutdown are both trying to manage the fan at the same time, potentially stepping on
each other.
Bug #4: No hysteresis on the 175°F threshold
If the temperature oscillates around 175°F (e.g. 174.9° → 175.1°), the fan will rapidly cycle
on and off."
Looks like you have all the info to solve the bug! Can you tell the AI to recode it?
You can see the commits on there. There is also a potential fix for the screen issue on startup.
I also asked about the ADS issue and it thinks the code is incorrect for using pull downs instead of pull up resistors. I have not tested or implemented that yet.
I have the ADS working now.
I had one rather stupid issue in that I soldered it on backwards so that wasn’t helping.
Since everything I looked at said that 5 volts on the esp32 was bad I cut some traces and fed the ADS, meat probes, and rotary encoder from 3.3 volts.
That got the ADS actually reading something.
Next issue is my Broil king meat probes are actually PT1000 RTD’s so I changed two of the 150kohm resistors to 1 kohm to have a more reasonable reading range.
Getting close to having this run a pellet grill but just want to be done with soldering before I get there.
Noted about the ADS - I’m glad someone was finally able to test it. If I order more boards I’ll certainly make that change, but it’s an easy fix to cut a couple traces as you did.
You’d get the the most accurate readings from PT1000 probes if you used a MAX31865. But, if you play with mapping values long enough in the filter definition of the adc input pin it may work fine. The PiFire project guys report good results using an adc for a ton of different probes.
I’m gonna change my display to 20mhz. I bet that fixes the initial power on blank screen problem. Sometimes it takes a village!
Jeff
I added a delay and that seemed to fix the screen but I’m still not certain that is a permanent fix.
PT1000 probes are working with the ADS and 1kohm reference resistors. It actually came out pretty accurate in an ice and boiling water bath. At least as far as BBQ accuracy needs to be.
Here is what it currently looks like.
That looks fantastic! Really well done.
I tried the change from 40mhz to 20mhz on the display. Unplugging it for 30s to let the caps discharge and then powering it on still shows a problem. It’s got a faint, fuzzy, distorted image (it used to be blank) but the touch screen works. A quick power off and back on fixes it. I’m wondering if an RC Power up reset circuit somewhere (either on the display or the EPS32) might be required if we can’t fix it in software.
I think the fix for the display is going to be more hardware involved.
I bodged on a 100uFD cap and a 100 ohm resistor to hold the Disp_RESET pin low longer on power up. This gets the display to start up reliably but now you see Static for a while before the display gets drawn for the first time.
The suggestion by the bot is to connect the LED pin to GPIO16 and only turn it on after the first frame is drawn so you don’t see the static. I’m far from an expert on these displays but it sounds plausible. I’ll give it a try tomorrow and let you know.
The back of this board is starting to look a bit like a rats nest with all the bodge wires.
Sometimes things get messy… this stuff is all half baked. Dev boards are just that. Development boards. Trust me, I’m taking notes on all of this. Never once did I say it was all perfect. Hopefully we find solutions to each of the issues and I can update the circuit board design.
At one point I had laid out a circuit board with an ESP32 chip and supporting components but holy cow - imagine trying to debug these kinds of issues now…
I have literally HUNDREDS of hours invested in this and its related projects. The obstacles all seemed insurmountable initially and I just trudged on, breaking down each issue into its basic components and solving for each of them. Discord is your friend here. Sometimes I wanted to give up… but I never did.
If all this was easy, it would have been done before. This design is a first. I’m really enjoying you guys and your gusto in trying to improve it. I’m all in. Happy to send anyone who bought circuit boards from me new ones for free once we iron out all the bugs. I’m certainly not in this to make money…
but now you see Static for a while before the display gets drawn for the first time.
Hmmm… I’m thinking it might be the display that needs to initialize first and then the esp, so perhaps the power up reset delayneeds to be on the esp32… ??
Jeff
I’m having lots of fun working out the bugs as well.
I’ve learned more about esp32’s in the last week than I ever expected.
Do you think controlling the LED pin will work as I have been led to believe?
Got the fix working on the display.
Needed a 1 k pulldown on gpio16 and using it to control the backlight.
It took some code variation to get it right but between this and the RC on the reset line the display powers on reliably and does not show static.
This does add a slight delay but I’m happy with it.
The code is on github.
So I finally got this up and running on the actual BBQ.
And the out of the box experience is better than the factory controller as far as tuning goes. Just shows how poorly the Broil King tuning is.
I spent about half a bag of pellets tuning things up and now have great control at the range of temperatures I use.
Might do a bit of work on the smoke mode to line up better with how my burn pot works.
By the way it turns out the software and hardware fix for the display are not working. The static issue is solved but it still hangs on boot. What I found was that the ESP is hanging not just the display. Tried a bigger cap on the PSU but I’m fine with just rebooting it as needed.
congrats! ESP hang - we might try feeding that into AI specifying the exact chip and type of display and see if there are any suggestions. Also, @Sseib on Discord might have some ideas - he’s well versed in these things.
When I have time, I’ll try this fix. In the meantime, if someone else wants to take a stab at it - go for it!
My Grok prompt as well as feeding it the full config file:
Upon boot up, the display is blank. Resetting the esp32 makes it work. Unplug it for 1 min and plug it back in and the display is blank again. Unplug it for a few seconds and then back on and it works.
Fixed! The blank display on cold boot (long power-off) but working after short unplug or software reset is a very common ILI9341 + ESP32-S3 issue.
Root Cause
• On a true cold boot (caps fully discharged), the ILI9341 powers up with its reset pin floating/high.
• The built-in reset_pin: GPIO6 in the ili9xxx component runs its reset too late (during normal component setup).
• The display ends up in an unknown internal state → blank screen.
• Short power cycles or software reset leave residual charge/state, so it “luckily” works.
Solution (2 small changes)
Remove the automatic reset_pin from the display (we will control it manually).
Add a forced hard-reset sequence at the very beginning of boot (priority: -200).
Change #1 – Add this output block anywhere in the YAML (e.g. right after the spi: block)
output:
- platform: gpio
pin: GPIO6
id: tft_reset
inverted: false # most ILI9341 modules reset on LOW
Change #2 – Replace your entire on_boot: section with this updated one
priority: -200 # <- MUST be earlier than -100
then:
- logger.log: "=== MANUAL DISPLAY HARD RESET ==="
# Force hardware reset (critical for cold boot)
- output.set_level:
id: tft_reset
level: 0
- delay: 150ms # long enough reset pulse
- output.set_level:
id: tft_reset
level: 1
- delay: 120ms # ILI9341 needs ~120ms after reset before commands
# Original boot logic
- lambda: id(status_msg).publish_state("Ready");
# Check RTD temperature and turn on fans if needed
- if:
condition:
lambda: return id(rtd_temperature_f).state > 175.0;
then:
- switch.turn_on: fans_on_off_sw
- lambda: id(status_msg).publish_state("Hot startup - Fans ON");
else:
- switch.turn_off: fans_on_off_sw
- lambda: id(status_msg).publish_state("Ready!");
Change #3 – Update the display block (remove the reset_pin line)
display:
- platform: ili9xxx
id: mydisplay
spi_id: spi_bus
data_rate: 20MHz
model: ILI9341
dc_pin: GPIO5
cs_pin: GPIO7
# reset_pin: GPIO6 ←←← DELETE THIS LINE (or comment it out)
color_palette: 8BIT
rotation: 0
update_interval: 0.5s
invert_colors: true
show_test_card: false
...
Why this fixes it
• The hard reset now happens before any SPI communication or display component setup.
• Works on every cold boot (1 min+ unplugged).
• Still works perfectly on quick power cycles and software resets.
• No other changes needed.
Flash this updated YAML and test:
Unplug for 2 minutes → plug back in.
Display should now come on immediately with the “Ready!” message.
EDIT: this problem is fixed. A modified version of this is now in the codebase.