Feature Wishlist

[nebhead]

Post your feature requests here. Things that I am planning on working on in the future:

• Support for changing from Fahrenheit to Celsius
• Evaluate using threading for control.py
• Evaluate a blocking library for file access (prevent collisions between app.py and control.py)

[nebhead]

Oh yes, and I would also like to fix the settings.json system so that when an update occurs, it overlays the updated settings on the older settings file. This is more of a bug fix, but also kind of a new feature.

[weberbox]

Native Android app
4th probe support
Maybe touchscreen?

Would be great if settings changes took affect during the current cook. Maybe the control.py threading can help with that?

[nebhead]

@weberbox just WOW!!!

I am so very impressed by this! Outstanding work. I've been looking over the changes on your fork and they are looking great. I'd say, maybe let's just merge these changes into the development branch of PiFire at the very least. I wouldn't love to get my hands on the Android app and start testing it out.

Really very cool - and I'm sure several other folks on here would be interested in trying out the app too.

[nebhead]

BTW - I wanted to ask, if you have run into an issues with the threading library and Gunicorn? A long time ago, I attempted to implement a flask app, together with threading. It worked OK until I wanted to run Gunicorn, and the whole thing sort of broke. I never did go back and figure it out. However, this was with Python 2.7 and a much older version on Gunicorn. So, just curious if it's all playing nicely in one process now? If that's the case... eventually, we could just move the control logic back into the main app process. That would be super cool because then we wouldn't have to do gymnastics with the settings / control files anymore.

[weberbox]

@nebhead Sure you can grab the source and compile the app with Android Studio. You would need to do this if you want to use Firebase push notifications as you would need your own google-services.json file and a Firebase project setup first. I just made a couple pushes with new product flavors so it can be complied easier without needing Firebase and not having to remove all the code and dependencies if you do not plan on using it.

The app does not do much without a connection to the server just FYI. I would like to someday make it so the settings and pellet manager work offline and sync when back online, I added a timestamp to the server but have not worked on it yet on the Android side.

I have been running threading and Gunicorn on the test server for about a month or so and have not experienced any issues so far. I have limited testing on actual hardware so hopefully it does not become an issue.

I do not like the way I did the QRCode on the ili display as it is blocking and cannot be exited. I did not spend a lot of time on it so maybe you could look at it and see if there is a better way?

I will make a request to the dev branch. If you play around with it let me know what you think.

[nebhead]

FYI... merged all the changes into the development branch, thank you for the pull request!

For the Android development side, maybe you can start to post the APK's in the "release" section of GitHub? This allows you to attach stuff to your repository, without disrupting the size of your overall repo or cluttering it with large binaries.

I'll take a look at the QR Code implementation. This was something I really wanted to do previously, so I'm glad you actually took the time to do it.

Also, I am thinking, since you have a 4-probe setup, that I would try to re-architect things a little with respect to how we store the probe history and display it, such that it's better integrated. This way, in the future, we can all be working off of the same branch. Also, I feel I have to give back, considering all the work you have done to get the Android side of things going. :)

[weberbox]

I did not really plan on having releases as the firebase side requires the user to compile themselves but I guess I could release the non firebase version. It would be nice if there was a way to have firebase without the need for each person to set this up but it would require an app server that stores everyone's app id and ties it to their local pirfre installation with tokens or an api. This would be nice but would require an external server and quite a bit of work to setup. Setting up Firebase and compiling the app is not that hard so it was not worth the effort.

As for the 3 vs 4 probes it would be nice not having to deal with multiple branches and versions. Currently I am only displaying one grill probe at a time with a selection for type as they are different (stock vs thermoworks). This was the best option for me so the entire UI on the webpage and display required no changes. I am fine with it remaining this way as it would be way easier to update the main branch to support that. Actually I just made a few updates so the Android app will look at the server for 3 or 4 probes and show the options accordingly. This way there does not need to be multiple versions of the app for 3 or 4 probes.

Do not feel obligated to work on the four probe version just for me. My app is useless without your awesome project so you have already given but I will not refuse working out a way for the main branch to support both. If you want take a look at my four probe version and see if it poses any issues. It might be as easy as just checking if the server is a four probe version or three probe and then showing the relevant options.

An example might be like below just check

if (settings['globals']['four_probes']):
		if (settings['grill_probe_settings']['grill_probe_enabled'][0] == 1):
			AvgGT = adc_data['Grill1Temp']
		else:
			AvgGT = adc_data['Grill2Temp']
	else:
		AvgGT = adc_data['Grill1Temp']

But maybe there is a better way than a bunch of if else

[SeanDMaloney]

Hello all! First off, I wanted to say how impressive your project is, and thank you for your efforts.

I had started working on something similar using @DBorello’s project as a framework a couple years ago, but was diverted by life towards other projects. Your move away from Firebase was something that I had wanted to pursue as well, but I lack the experience that you have in making that happen.

I am looking at doing something similar with a couple of smokers that I have, and am curious to see what it may take to implement the ability to control multiple smokers simultaneously with the GUI interface you have created, or something similar to it. Building in a way to have profiles for different smokers would be something I would be interested in as well, given that I have several smokers that would require different durations of auger run times in order to maintain temperatures and sustain the fires. Two of my three smokers I am working on have augers that feed, more or less, directly into a burn pot, rather than a feed tube like the Traeger.

[SeanDMaloney]

Multiple devices had always been my conclusion as well for the reasons you stated, as well as allowing a higher level of independence between smokers.

I’m also curious to see what would be involved in developing an iOS native app that could potentially utilize your API. Working up something that would be able to monitor and control the smokers outside of my local network is my long term goal, preferably without using a VPN, but that’s a ways out.

[nebhead]

OK, cool, I think it would just come down to where you run the WebUI for aggregating the data for all of the smokers at once. Something to consider as I'm sure that would come in handy for folks at competitions, etc.

Once I get it fixed up, the API would be perfect for using with an Android, iOS, or PC application. Unfortunately, I don't have any expertise in creating an iOS application myself and I don't own any Apple devices (aside from some super-old ipods). I would welcome anyone to take a crack at this.

As for accessing outside the network without VPN, the current web interface isn't secure by any measure. There is no user/password management or security otherwise built in. It's something we could implement, but would be quite a bit of work. If we were just exposing the API, that could be done relatively easily utilizing the built-in nginx reverse proxy. However, again, it's a little bit risky given you've got things that make fire, exposed to the internet. :)

[DBorello]

Greetings All!

I am glad to hear the smoker control community is alive and well!

I am always delighted to see the derivatives of PiSmoker. It was a fun little hacky project 6 years ago, with almost no progress since. However, it is still running strong.

I can't blame you for dropping Firebase. I am not a fan of the external dependency on a third party. However, it has been convenient to not have to mess with port forwarding, etc. I like the comments on exposing fire devices to the internet :) I do recall using the same Pi (whoops) for development of another project. I didn't realize I was toggling GPIOs connected to an igniter.

Also, can someone please write a better controller than my simple PID :)

[nebhead]

@DBorello! Thanks for dropping in on the conversation!

Your PiSmoker project has definitely been an inspiration for me and for many other folks out there. I basically just put a different WebUI on it. :)

And I feel your PID works pretty well as-is. In fact, I'd say it's better than my original Traeger controller by a mile. I'd toyed around with the idea of trying a few other PID modules that are floating around on GitHub, but hadn't gotten around to it yet. I lack experience with PID's in general to really drill down into the design. With that said I do think there may be some lurkers here in this project that have more experience and could potentially help out to make it better.

[SeanDMaloney]

I couldn’t agree more about the potential security risks associated with an unprotected combustion appliance exposed to the masses. I would definitely be implementing some sort of security protocols to mitigate those concerns, as I have no desire to create a spontaneously igniting smoker or grill. My workshop has enough fire hazards (acetylene hoses that decide the flame comes out the hose instead of torch, just to name one) without eliciting outside assistance!

@DBorello I am happy to see you are still active, given your project gave me the confidence and groundwork to undertake this myself.

While my current modern programming experience is vastly dwarfed by most of the contributors here, I do have a tremendous amount of practical experience rebuilding and troubleshooting most all things pellet smoker. I have all of the currently produced Traeger controllers (Pro, Arc, and AC version of the WiFire controller), Louisiana controllers, and a Pit Boss controller for my vertical cabinet smoker. I also have a fairly developed knowledge of the workings of the new DC controllers that Traeger is using, so if there are any questions, details, or insights that I can offer, it would be my privilege to do so.