Smoke Plus Feature Discussion

[nebhead]

Moving the feature discussion here.

I've gotten the chance to try out the Smoke Plus feature this weekend and overall I think it's an impressive start. However, it is not without issues. There are some necessary fixes / improvements:

• The fan cycle time seems to get interrupted sometimes and is shorter than the allotted time & duty cycle. I think this has to do with the way that I do cycling of the auger in smoke mode.
• The slow update of the display becomes very clear in this mode as the fan icon shows up sometimes when the fan should have been cycled off. It's an artifact of the display only updating periodically. I am going to look into making this update faster.
• I also had issues initially getting the temperature high enough in smoke mode to get Smoke+ to work, but after it got going, the temperature shot up to about 200F.
• Smoke+ mode was enabled, but the button on the WebUI was not showing this - I had to manually cycle this to get it to appear.
• I think I'd like to enable this mode in Hold mode as well, to increase the smoke output. This should be easy enough, but I think we need a separate button for fan cycling in the WebUI.

I think this will keep me busy for a while. :)

[faisalhusain007]

I did notice the delay on the display when I was testing out the smoker feature but did not see the fan cycle being interrupted. However my Auger On time is slightly different, I found the sweet spot to be 23s. The Average ambient temperature here is around 77f-82f throughout the year, at 23s it gets to 160f and holds quite well there.

Smoke+ mode was enabled, but the button on the WebUI -
I thought this was by design, I had to click to enable it and to show on the WebUI

I think I'd like to enable this mode in Hold mode as well, to increase the smoke output. This should be easy enough, but I think we need a separate button for fan cycling in the WebUI. -

Again I think this would be a first, I don't think other comercial controllers have the ability to smoke much whilst running PID cycle, at least that's the case with GMG, holds temps amazing tight close to +/-2f but then very little smoke. I agree a separate button for fan cycling is a good idea.

[nebhead]

Wow! It sounds like you have had an exciting journey in your careers. I also grew up in the 80's, started programming on my family's Commodore VIC-20, and was hooked ever since. That set my trajectory to go for Computer Engineering in HW ASIC design, and finally ended up just getting hired at a big Integrated Silicon Manufacturer in California, just before the internet bubble burst and thus was very lucky to have secured a job in that time, because tech jobs were also scarce then too. However, I've been working at that same company for the last 20 years and now manage a team of BIOS engineers working with large PC OEMs. It's actually an awesome job, but very different from the kind of software that I'm developing and sharing here. :) I still consider myself a student of this stuff. And like you, I've enjoyed cooking on my smoker for many years - and it was just natural to want to try and integrate the smoker with my other passion.

[faisalhusain007]

Vic 20, brings back memories, I had a commodore 64, then latter I got the commodore Amiga. I love food and tech and bringing them together. One of my earlier projects include a dry ager, help age beef perfectly, using an old drinks fridge and an ESP32 led UV lights and small ozone generator are the highlights.

Uploading 20210115_010422.mp4…

Still loving the smoke + function, cant believe how perfect the smoke is, and the overall functionality is way better than most of the commercial controllers.

[nebhead]

I always wanted a C64 and Amiga (some friends had them) but my family wasn't able to afford it at the time. Commodore had a great computer architecture and it's a shame they made so many poor business decisions - they could have been a much bigger player these days.

The dry-ager sounds amazing - I honestly didn't even know that was something that exists! What a great idea! You're making me hungry just thinking about it. :D

I'm looking forward to testing the smoke+ function more in the coming days. When it's ready to hit primetime, I'll push it up to the main branch so anyone else following this project can give it a try.

[faisalhusain007]

Ager.mp4

Previous video didn't upload of the ESP meat ager

[nebhead]

Very nice!! I see you have some good looking steaks in there. Looks outstanding - probably a fun project too. I really like the marquee! Nice job! If I had any spare space in my house, I'd definitely set one of these up.

[nebhead]

Just FYI on the current status on this feature. Still validating the changes that are on my local dev environment - will be doing a smoked chicken tonight. :) Once I'm satisfied that I haven't broken anything too much, I'll push to the development branch here.

[faisalhusain007]

I will order the ips version of the screen and see if we can design another housing to incorporate that one.

The new PCB looks awesome, have you published the gerber files? I might have a go at milling the new pcb myself, I see you also included pinouts for the new display and pin ios for future use of buttons etc.

I tried a few libraries and settled for this one https://github.com/johnbryanmoore/VL53L0X_rasp_python, fairly lightweight but works quite fast. The issue I get is the way the pellets go down is like V shape, they kind of get sucked down the middle first then fall in from the side like a V pattern. I am not sure if its the same with all traegers, but I am guessing based on the design of the box thats how its meant to be. But if I place the sensor off center slightly closer to the left of the inside of the box, you can get fairly accurate readings, the pattern of usage is always the same so we can take readings and visual checks at different levels that give fairly accurate estimates to how full the box is. Not sure if I explained that well but perhaps I will take pictures so you can visualise what I am trying to say.

BTW excellent work on the new dev code I am going through testing various scenarios on my bench, the first thing I noticed the screen updates are far more accurate almost no delays between the operations and the screen display, the fan pulses almost in sync with the display. I will continue to test and report back any findings, thank you again for all your time effort and hard work.

[faisalhusain007]

BTW what size screen did you order? I have found from 1.3 up to 1.8 inch screens

[nebhead]

Something weird happened and my last comment doesn't seem to have shown up so I'm re-commenting - hopefully this works.

I will order the ips version of the screen and see if we can design another housing to incorporate that one.

I ordered the 1.3" version from AliExpress. I've also ordered some other screens (a couple others that work on SPI) which I thought might be interesting. If they don't work out, I'll use them for other projects.

The new PCB looks awesome, have you published the gerber files? I might have a go at milling the new pcb myself, I see you also included pinouts for the new display and pin ios for future use of buttons etc.

Thanks! I designed and shared the board on EasyEDA. You should be able to check them out here: https://easyeda.com/nebhead77/pifire-v2

Maybe wait until I get a chance to test this out a bit before you try to either mill it, or order it from JLCPCB (it was only $5 for 10 boards). So far so good, but I would hate for you to get something that doesn't work properly. :)

I tried a few libraries and settled for this one https://github.com/johnbryanmoore/VL53L0X_rasp_python, fairly lightweight but works quite fast. The issue I get is the way the pellets go down is like V shape, they kind of get sucked down the middle first then fall in from the side like a V pattern. I am not sure if its the same with all traegers, but I am guessing based on the design of the box thats how its meant to be. But if I place the sensor off center slightly closer to the left of the inside of the box, you can get fairly accurate readings, the pattern of usage is always the same so we can take readings and visual checks at different levels that give fairly accurate estimates to how full the box is. Not sure if I explained that well but perhaps I will take pictures so you can visualise what I am trying to say.

I think I know exactly what you are talking about. In my hopper, my pellets tend to "stick" to the sides and a crater forms right above the auger inlet. Thus I think the sensor would need to be positioned right above that, perhaps mounted to the lid? I'm also worried about the length of wire needed to run to the sensor, since I2C isn't really designed to have long cable connections. I guess we can give it a try... maybe add some pull-ups near the sensor, if we need to.

BTW excellent work on the new dev code I am going through testing various scenarios on my bench, the first thing I noticed the screen updates are far more accurate almost no delays between the operations and the screen display, the fan pulses almost in sync with the display. I will continue to test and report back any findings, thank you again for all your time effort and hard work.

Thanks again! I set the screen to update every 1 second. We can try to go faster, but I wasn't going to push it too much right now. I might try to mess with that later, or make it configurable, depending on the display that you have connected. I feel like 1 second is good enough for now and doesn't seem to cause any problems.

I'm working on the button input now. Making good progress. I've got the buttons soldered up, and it's running on my new PCB. The button input is processed by some interrupt callbacks in the display module. This will make it more configurable, per display type, if some day the display is larger and can handle a bigger menu.

[faisalhusain007]

I ordered the 1.3" version from AliExpress. I've also ordered some other screens (a couple others that work on SPI) which I thought might be interesting. If they don't work out, I'll use them for other projects.

I have ordered a 1.3" and 1.44" will add these as options for the 3d printed case.

Thanks! I designed and shared the board on EasyEDA. You should be able to check them out here: https://easyeda.com/nebhead77/pifire-v2

Maybe wait until I get a chance to test this out a bit before you try to either mill it, or order it from JLCPCB (it was only $5 for 10 boards). So far so good, but I would hate for you to get something that doesn't work properly. :)

I ordered this from JLCPCB before I saw this message but its ok will help design a 3d printable case with this option.

I think I know exactly what you are talking about. In my hopper, my pellets tend to "stick" to the sides and a crater forms right above the auger inlet. Thus I think the sensor would need to be positioned right above that, perhaps mounted to the lid? I'm also worried about the length of wire needed to run to the sensor, since I2C isn't really designed to have long cable connections. I guess we can give it a try... maybe add some pull-ups near the sensor, if we need to.

I think we are good, from what I have read we can go up to 100cm which should be enough if not we can try with the pull ups, but I have roughly measured the distance and I think it can be done.

Thanks again! I set the screen to update every 1 second. We can try to go faster, but I wasn't going to push it too much right now. I might try to mess with that later, or make it configurable, depending on the display that you have connected. I feel like 1 second is good enough for now and doesn't seem to cause any problems.

I think it's good enough now, works a treat.

I'm working on the button input now. Making good progress. I've got the buttons soldered up, and it's running on my new PCB. The button input is processed by some interrupt callbacks in the display module. This will make it more configurable, per display type, if some day the display is larger and can handle a bigger menu.

I think keep the button functions simple, I believe it's a nice to have but really prefer using the webui for most things, I will attach a video of a commercial unit have which uses a rotary encoder but lacks almost most of the functionality of the Pifire.

[nebhead]

I think keep the button functions simple, I believe it's a nice to have but really prefer using the webui for most things, I will attach a video of a commercial unit have which uses a rotary encoder but lacks almost most of the functionality of the Pifire.

Sounds good, keeping it simple. :)

Didn't get much of a chance to work on things yesterday, but did get the buttons at least working, so I know it works within the PiFire framework in terms of getting the interrupts working. Now I just need to get the menu functionality working, with the display.

[faisalhusain007]

The first video is showing the limited use of the encoder Just allows the setting of the initial cook and setting the target temp of the food probes

Physical.use.of.encoder.1.mp4

The next 2 videos are the app, but as you can see its really limited, there are no ways to control the fan, no smoke + etc. In fact your restricted to using the probes they sell as an extra, there is no way to tune other temp probes.

App.settings.mp4

This shows the use of recipes with junk still left from the developer.

App.recipies.mp4

The hardware looks well put together, unfortunately the software execution is really poor, I was planning on developing my own firmware for this but then I found PiFire.

[nebhead]

The first video is showing the limited use of the encoder Just allows the setting of the initial cook and setting the target temp of the food probes

Interesting to see how they handle the physical interface. I had played with the idea of a rotary encoder, I have a handful of them in my parts bucket, but I just don't like how imprecise they are. Sometimes they register forward motion when you are turning backward, etc. And when clicking the button, sometimes it rotates at the same time. So I like the idea of simple buttons instead.

The next 2 videos are the app, but as you can see its really limited, there are no ways to control the fan, no smoke + etc. In fact your restricted to using the probes they sell as an extra, there is no way to tune other temp probes.

Yeah, that's one thing I really like about this project is the freedom to use other probes. I had various probes laying around from different digital probes that I've had in the past and I wanted to be able to use some of those. It's not perfect, but it works well enough for me. :)

This shows the use of recipes with junk still left from the developer.

Ha! That's wild. I guess they didn't have too much quality control on this product before they shipped it out. :)

The hardware looks well put together, unfortunately the software execution is really poor, I was planning on developing my own firmware for this but then I found PiFire.

Very cool! I'm glad PiFire is working for you. It's been a fun project for me so far and I'm looking forward to making it even better.

[faisalhusain007]

I haven't got my screens yet but I have found some dimensions for the 1.3" IPS screen so I Updated the face plate to include that. It looks like we can go up to a 1.8" screen without any problems.

This is for the 1.3" IPS.

[nebhead]

Very cool. My screen has arrived, so I may try to get it setup over the weekend. I was also going to try the HC-SR04 Ultrasonic sensor over the weekend, as I'm have a heck of a time getting the TOF sensor working properly. Your mileage may vary, but give the latest a spin over on the development branch. I feel like something must be going wrong with it.

[faisalhusain007]

Sure will test and report back.

[nebhead]

Ugh, so the version of the screen (ST7789) that I picked up with I2C based, which is what I wanted, but it looks like there aren't any python libraries to support this version yet. All of them appear to be SPI based. :( I should have done more research, luckily they are cheap. Let me know if you have any luck finding anything. I may look at some other screens to see what else we can use. Another option to use a larger screen may be to mount it so that it's more on the outside of the grill body, not flush with the surface. Maybe even angled up a little so that it's easier to see.

In the meantime, I may work on improving some of the dashboard buttons w/Javascript... I'm a novice at JS, but learning as I go which is fun.

[nebhead]

Yep I read that people have got it world working better to use this lib
https://github.com/solinnovay/Python_ST7789

Cool. If I can find some time tomorrow, I'll try to also hook it up.

[faisalhusain007]

I got my screen working with some example code but my screen is the waveshare type 1.54". https://www.waveshare.com/wiki/1.54inch_LCD_Module
I used their python library.

[nebhead]

Did yours come with the right pinout printed on the device? I hooked mine up last night, but haven't gotten it to work yet.

[faisalhusain007]

Yes it did, but I needed to change the pin outs in the waveshare lib. This is the screen I got

In the /lib/lcdconfig.py I changed the pins for backlight, cs and reset to match the pins of PCB V2.

I also tested out the adafruit libs they also work great too. (adafruit-circuitpython-rgb-display)

[faisalhusain007]

I think the adafruit libs are better documented, so far I can upload images and draw different shapes etc

Looking at trying to connect to PiFire as a display but still learning python

test.scrn.mp4

[nebhead]

Very cool! Keep hacking at it. You can get started by copying the SSD1306.py module and then swapping out the imported libraries to use this display. Then just replace the commands, etc. for painting the screen. Might be a good way to learn. :) BTW, I highly recommend this channel on youtube: https://www.youtube.com/channel/UC6HfeAa0vWeSWS6IcNAjZ2A to learn more of the deeper Python functionality. The way he goes through his lessons is excellent for learning. I'm still not having any luck getting mine up and running. I'm sure I've got some pins swapped somewhere, but I need to just spend time to guess and check. :) I'll try the Adafruit libraries... I just hate adding an extra layer (circuitpython) on top of all the other libraries that are already loaded (RPI.GPIO).

…

On Wed, Jan 27, 2021 at 4:31 AM faisalhusain007 ***@***.***> wrote: I think the adafruit libs are better documented, so far I can upload images and draw different shapes etc [image: image] <https://user-images.githubusercontent.com/36872476/105991105-5d583480-60de-11eb-989f-6cac0f62db3c.png> Looking at trying to connect to PiFire as a display but still learning python — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#20 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AEXUYFUQU2UFAJAYDTWBOMDS4ABRDANCNFSM4V54AIJA> .

[faisalhusain007]

Wow that looks really good, I am ordering the screen now. Thank you for all your time and effort in developing this project, I believe it's easily the most comprehensive detailed guide on the net so far. I have placed an order for the same screen.

For me so far the pelet level sensor is working really accurately and reliably well. I did however need to edit the last development branch for the sensor to get it to work.

In distance_vl53l0x.py

Line 22 changed from >common import DebugWrite >from common import WriteLog
Line 58 changed from >DebugWrite(event) > WriteLog(event)

everything else seems to be ok.

And trying to get the prototype running on my machine (MAC) seems to exit out with a weird error will try and debug latter.

Here is the message when it crashes
Traceback (most recent call last):
File "control.py", line 1161, in
Monitor(grill_platform, adc_device, display_device, dist_device)
File "control.py", line 604, in Monitor
WriteHistory(in_data)
File "/Users/Faisal/Downloads/pifire research/PiFire-developmentV4/common.py", line 572, in WriteHistory
if(int(temp_array[0]) >= maxsizelines):
ValueError: invalid literal for int() with base 10: ''

[nebhead]

Wow that looks really good, I am ordering the screen now. Thank you for all your time and effort in developing this project, I believe it's easily the most comprehensive detailed guide on the net so far. I have placed an order for the same screen.

Thanks! It's been a lot of fun.

For me so far the pelet level sensor is working really accurately and reliably well. I did however need to edit the last development branch for the sensor to get it to work.

Excellent! One of these days I will wire up the new PCB and the distance sensor on my actual grill. I've been putting it off, but I think it's probably time. I'm going just remove my Traeger controller and use PiFire full time. I haven't used the Traeger controller since basically May last year.

In distance_vl53l0x.py

Line 22 changed from >common import DebugWrite >from common import WriteLog
Line 58 changed from >DebugWrite(event) > WriteLog(event)

everything else seems to be ok.

Yep, that's a bug. :) I'll get that fixed up for the next release.

And trying to get the prototype running on my machine (MAC) seems to exit out with a weird error will try and debug latter.

Here is the message when it crashes
Traceback (most recent call last):
File "control.py", line 1161, in
Monitor(grill_platform, adc_device, display_device, dist_device)
File "control.py", line 604, in Monitor
WriteHistory(in_data)
File "/Users/Faisal/Downloads/pifire research/PiFire-developmentV4/common.py", line 572, in WriteHistory
if(int(temp_array[0]) >= maxsizelines):
ValueError: invalid literal for int() with base 10: ''

Yeah, that is probably an error with how the Mac is returning output from the 'wc' command. It must be doing something different on the Mac. Can you try just running the command at the terminal:

wc -l /tmp/history.log

Then see what the output is? I suspect it's either not working or returning something unexpected.

[faisalhusain007]

wc -l /tmp/history.log

I get the following

   3 /tmp/history.log

I think it is returning spaces when I compare the results on my pi
I try and fix this by piping through sed but it doesn't work wc -l /tmp/history.log |sed 's/^ *//' or at least I don't know how to include the ' in python using os command.

[nebhead]

Yeah, it's probably adding a line or something. Perhaps we can try to see what the output is by putting some print statements in.

	command = 'wc -l /tmp/history.log' # Use the Word Count CLI tool to get number of lines
	history_file = os.popen(command)
	history_lines = history_file.readlines()
	history_file.close()
	temp_array = history_lines[0].split(' ') # Split result line into parts
        
        # Add print statements here
        print(temp_array)
        print(history_lines[0])
        print(history_lines[1]) 

The other option is just to comment out the following if statement:

	#if(int(temp_array[0]) >= maxsizelines):
		#WriteLog('File: history.log at maximum set size, removing an hour of data from beginning.')
		#os.system('tail -n ' + str(maxsizelines - 1200) + ' /tmp/history.log > /tmp/history.bak')
		#os.system('rm /tmp/history.log && mv /tmp/history.bak /tmp/history.log')

This will just skip the check for the history log size. This really only matters if you've been running the program/logging history for more than 24 hours or so - just to prevent the file size from getting too big. It's a case that won't happen on your Mac (probably), so we don't really need to check for it.

[faisalhusain007]

Thanks for that, I opted to comment out the lines as there are known issues with wc and its weird formatting on MAC. Now it seems to work ok without crashing out.

[nebhead]

I like it. I'm cool if you want to do a pull request on the dev branch with your edits / additions for this and maybe document what you have done to install the luma module in the header of the display_st7789.py file. Once I get my new screen, I can start to play with it from there. But take your time, I'm not in any rush at the moment, still waiting on shipping. :)

BTW... I found (and ordered) some much more high end 2.5mm jacks to use for the probes. This has been a weak point in my current hardware setup, because my jacks are very low quality and don't work well with all my probes. Not sure where else these could be sourced, and they are expensive, but might be worth it. https://www.amazon.com/gp/product/B01M2AZTUQ

[faisalhusain007]

I still think there are some bugs that need ironing out, once I have finished I will update the and document as best as I can.

The new sockets look awesome, I haven't had any issues with the ones I got from RS components here. I just checked from Amazon it will cost $11 to ship here, might hold back a while.

[nebhead]

I still think there are some bugs that need ironing out, once I have finished I will update the and document as best as I can.

No worries! Take your time, and once I get my screen I'll probably reach out to get some guidance.

The new sockets look awesome, I haven't had any issues with the ones I got from RS components here. I just checked from Amazon it will cost $11 to ship here, might hold back a while.

Yeah, these ones are not cheap. :) I did just look on ebay and found the same / similar jacks for a bit cheaper. My keywords for the search were Philmore 2.5mm, which popped up quite a few options.

[nebhead]

Awesome! Have fun! I'm going to start adding the physical button controls to the display module, but will probably prototype it in PyGame first.

…

On Sat, Feb 20, 2021 at 9:21 PM faisalhusain007 ***@***.***> wrote: Thanks for that, I opted to comment out the lines as there are known issues with wc and its weird formatting on MAC. Now it seems to work ok without crashing out. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#20 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AEXUYFR2AN3AS2INKOPCMIDTACJ53ANCNFSM4V54AIJA> .

[faisalhusain007]

Was thinking since the screen is a touch screen, we could use that instead of physical buttons?

…

On Mon, 22 Feb 2021 at 01:46, nebhead ***@***.***> wrote: Awesome! Have fun! I'm going to start adding the physical button controls to the display module, but will probably prototype it in PyGame first. On Sat, Feb 20, 2021 at 9:21 PM faisalhusain007 ***@***.***> wrote: > Thanks for that, I opted to comment out the lines as there are known > issues with wc and its weird formatting on MAC. Now it seems to work ok > without crashing out. > > — > You are receiving this because you commented. > Reply to this email directly, view it on GitHub > < #20 (reply in thread) >, > or unsubscribe > < https://github.com/notifications/unsubscribe-auth/AEXUYFR2AN3AS2INKOPCMIDTACJ53ANCNFSM4V54AIJA > > . > — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#20 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AIZKCHHZYV6XP425QWDFO63TAFBJFANCNFSM4V54AIJA> .

[nebhead]

Good thought. I'll look into it. It might take a fair amount of re-architecture to get the touch to work properly. Also, might require another library for the touch support. Right now I'm using the version without the touch screen, but I do believe I have the touch screen version as well. On Mon, Feb 22, 2021 at 2:46 AM faisalhusain007 <notifications@github.com> wrote:

…

Was thinking since the screen is a touch screen, we could use that instead of physical buttons? On Mon, 22 Feb 2021 at 01:46, nebhead ***@***.***> wrote: > Awesome! Have fun! I'm going to start adding the physical button controls > to the display module, but will probably prototype it in PyGame first. > > On Sat, Feb 20, 2021 at 9:21 PM faisalhusain007 < ***@***.***> > wrote: > > > Thanks for that, I opted to comment out the lines as there are known > > issues with wc and its weird formatting on MAC. Now it seems to work ok > > without crashing out. > > > > — > > You are receiving this because you commented. > > Reply to this email directly, view it on GitHub > > < > #20 (reply in thread) > >, > > or unsubscribe > > < > https://github.com/notifications/unsubscribe-auth/AEXUYFR2AN3AS2INKOPCMIDTACJ53ANCNFSM4V54AIJA > > > > . > > > > — > You are receiving this because you commented. > Reply to this email directly, view it on GitHub > < #20 (comment) >, > or unsubscribe > < https://github.com/notifications/unsubscribe-auth/AIZKCHHZYV6XP425QWDFO63TAFBJFANCNFSM4V54AIJA > > . > — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#20 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AEXUYFTEEFSI4Y5D56MENNTTAIYYJANCNFSM4V54AIJA> .

[nebhead]

Oh that is very cool! I need to learn to use Fusion or OnShape better so I can do things like this. TinkerCad is great, but being able to more easily design these types of projects is really amazing. I'm going to make a more concerted effort to learn so that I also work on this. Anyway, looking forward to what you come up with. Have you thought about how to mount the electronics? Maybe a separate box underneath?

[faisalhusain007]

To be honest I have only really started using Fusion the past year or so, previously I also used tinkercad but found it was limited to what I needed to do, but because I didn't know how to use Fusion I kept getting frustrated and going back to tinkercad. Then I guess I just stuck at it until I figured it out and watched lots of youtube tutorials on the things I got stuck on, then slowly figured things out. 

The first design I had the unit screwed to the back everything was plugged in stripboard and mounted on the front plate.

However using your new PCB I mounted it at the bottom with a cable connecting it to the front panel. I made two boxes the relay PCB sits at the bottom and is completely isolated.

The PCB and Pi fit in other section on top.

It looks like this together

I will take pictures in a few days, I will upload the new STL's on thingiverse too.

[nebhead]

Thanks for sharing! Yeah, I think the best option is to have a separate "control box" that can be mounted below. I guess the main concern I have is to be able to access things like the terminals for probes, and maybe the SD card. But in general, the electronics should be at least somewhat protected from moisture, dust, unintentional bumps, etc.

[faisalhusain007]

I just got the 2.8" touch LCD. I printed out the new front panel to see if it fits, I think I need to make some minor adjustments, I also need to attach it to the grill to see if the header pins clear the back of the grill. Great work by the way on the LCD GUI, it looks really good.

I have not included cut outs for the physical buttons, because I am hoping to try and get the touch buttons working. I haven't found much info yet.

[nebhead]

Thank you for the praise! This design is looking good, but yeah it would good to close the gap around the edges a bit. What do you think about a thin protective piece of clear plastic for the screen? Maybe a phone screen protector cut down to size? Just to prevent unwanted dust/water/scratches on the screen?

For the touch screen part, I have been doing some poking around. I have a similar 2.8" touch screen that I pulled out of my parts box and it has an XPT2046 touch controller on it. Doing some searching on pypi and GitHub, I found a few options, but nothing that 100% perfect. Some of the libraries are using circuitpython or WiringPi which might conflict with the RPi.GPIO libraries - but that might need to be tested. The search continues.

My thought is that we can add a function to the display class for polling the touch screen for input. So for every loop in the work cycle in PiFire, we can just call something like display_device.CheckTouchScreen(). This allows us to check the touch screen input and then call the callback functions that exist for physical buttons UpCallback, DownCallback, or EnterCallback if the correct place on the screen is being touched.

This means that we will need to add this polling capability to all of the display modules, but for the ones that don't have button input, they can just be a dummy call. Anyway, let me know if you find anything that can work for us as far as a library.

[nebhead]

Unfortunately, in smoke mode, since it's just a dumb cycle, it's generally going to run hotter. You could extend the cycle, reduce the amount of auger on time and see if that helps. Your best bet is to get an Amaz'n Smoker ( https://www.amazon.com/MAZE-N-Pellet-Smoker-Smoking-Works/dp/B007ROPJ1M) which will basically smoke at very low temperatures. It's temperamental though. Also, for cheese, I've found that you will want to refrigerate your cheese for at least 24 hours after a smoke to ensure full penetration. Don't try tasting the cheese right after smoking - you will be disappointed. :)

…

On Sun, May 30, 2021 at 4:27 PM cptcave ***@***.***> wrote: I'm not sure if this is the place for this question, but I was wondering about cold smoking. Has anyone tried and was wondering if they could so what's the coldest they'd be able to do it without a dedicatedcold smoking device? I know my grill will technically do about 180 but verticals will do colder, like about 150. I'd like to do cheese and the like. I've seen people use ice baths on barrel versions and I'd do the same. I was just wondering if its possible to do cooler with these types of pids controllers or if it's limited to the type of smoker. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#20 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AEXUYFS477EMWC5VSGRUGSTTQLCXVANCNFSM4V54AIJA> .

[weberbox]

So I really like the smoke+ option as it does seem to help produce much more smoke and seems the grill can hold temps better for the cook but in my opinion there are two things that I feel are issues.

1. Toggling smoke+ will break the current work mode loop and restart it. This is fine in Smoke mode but when using Hold with PID I believe this causes a restart of the PID causing temps to over shoot and then need to stabilize again. This seems to be caused by control updated = True from app.py upon change.

if('setmodesmokeplus' in response):
			if(response['setmodesmokeplus']=='true'):
				control['updated'] = True
				control['s_plus'] = True
			else:
				control['updated'] = True
				control['s_plus'] = False 

Do you think we could control this with a global or something else so the work cycle loop is not restarted but still be able to toggle it on and off if needed? This might be more moot if # 2 can be implemented.

2. From my experience when in Hold mode and the min smoke+ temp is say 160 and you have set hold mode to 250 it takes forever to get up to temp due to fan cycling, it also way over shoots the temp because it is dumping too many pellets trying to overcome the slow temp increase due to fan cycling. I think it would be a good idea while in Hold mode with smoke+ enabled to not cycle the fan until the grill has achieved the hold set temp then return to specified smoke+ settings.

Maybe something like below

# Set Hold Mode Target Temp Boolean
target_temp_achieved = False

# ============ Main Work Cycle ============
while(status == 'Active'):

     ..........

		# If in Smoke Plus Mode, Cycle the Fan
		if(((mode == 'Smoke') or (mode == 'Hold')) and (control['s_plus'] == True)):
			if(AvgGT >= control['setpoints']['grill'] or target_temp_achieved or (mode == 'Smoke')):
				# Set target temp achieved to revert back to normal smoke plus temp settings
				target_temp_achieved = True
				# If Temperature is > settings['smoke_plus']['max_temp'] then turn on fan
				if(AvgGT > settings['smoke_plus']['max_temp']):
					grill_platform.FanOn()
				# elif Temperature is < settings['smoke_plus']['min_temp'] then turn on fan
				elif(AvgGT < settings['smoke_plus']['min_temp']):
					grill_platform.FanOn()
				# elif now - sp_cycletoggletime > settings['smoke_plus']['cycle'] / 2 then toggle fan, reset sp_cycletoggletime = now
				elif((now - sp_cycletoggletime) > (settings['smoke_plus']['cycle']*0.5)):
					grill_platform.FanToggle()
					sp_cycletoggletime = now
					if(settings['globals']['debug_mode'] == True):
						event = '* Smoke Plus: Fan Toggled'
						print(event)
						WriteLog(event)

You could add a toggle in settings as well I guess.

I have not tested this just thought it up today. If you don't mind let me know your thought on this and if it would be a good or bad idea.

[nebhead]

Yeah, but it's worth a test on the real hardware. What I really need to do is build out second test rig for PiFire so that I can run tests on the real hardware without having to go out and use the grill. :) Anyway, I think the PiZero can handle it. I think I should be able to test it out on just a PiZero without all the hardware and see if it can keep up.

[weberbox]

I have been thinking the same thing. It would be nice to setup a second hardware test device without having to use the physical grill. Even put LED's for the outputs etc. I might do this as I think I need to pull the Pi anyway to put on an external antenna. Once the Pi goes up into the pellet box area and the bottom cover is put back on it kind of creates a faraday cage and it gets terrible reception. I am gong to add an external antenna inside the screen box for better reception and so I can put the bottom cover back on the pellet box.

[nebhead]

I am gong to add an external antenna inside the screen box for better reception and so I can put the bottom cover back on the pellet box.

Oh that's really smart. I have an AP that is really close by, so it's not too bad for me. But I can imagine it's not great for anyone who doesn't have a nearby AP.

[weberbox]

Ok found a bug in the Smoke Plus changes during a cook today. When control['updated'] = True was removed it created an issue where if Smoke Plus is toggled off when the fan is in an off state the fan never resumes again since the cycle is never restarted. I submitted a pull request that I think will resolve the issue.

Other than that the changes to keep the fan running until temp is reached is great and lets the grill hit temp so much quicker.

[qorncat]

Wow thats owesome :D sorry for my english

[qorncat]

I like this project

[nebhead]

Thanks!

[qorncat]

you have discord i have a question very private question
if you have qorncat#9434 contact on discord

[Abdullahalsharif21]

hello every one i need some help i want to connect a multiplexer TCA9548A to my raspberry pi with 8 multiplexer and i tried https://github.com/johnbryanmoore sample multiplexer is only reading but the sensors is not could some one advise me