Development Branch

[weberbox]

I plan on submitting a pull request soon with a huge overhaul on the SocketIO side and a change from Firebase to OneSignal notifications. While it still uses Firebase on the Google side OneSignal replaces my simple AWS server instance, adds better security and makes it so I do not need to maintain the AWS instance.

For the SockeIO side I really wanted to slim down the code as it was long and almost a duplicate of the flask side that needed to be changed with most PiFire updates. I took inspiration from your api changes and incorporated it into SocketIO. This way I can just build json payload on the Android app side and send them to PiFire. When a new feature is added I should not need to edit the SocketIO section. There are some functions like deleting keys, restoring data or triggering certain things etc that the api section cannot do so there is still some code that needed to remain.

I also added a setting so the startup timer can be adjusted. Recently with the lower temps I ran across many reignites and adding 1-2 minutes to the startup timer help prevent that.

Anyway to the question. With the new Updater (which is really cool btw) it requires that PiFire is installed from git for it to work. I built and added the ant scripts to create deb packages as it was easier for me to deploy packages when testing and my thoughts were if you ever wanted to release versions then a deb would have been an easy way for people to install PiFire.

So I am thinking should we remove deb packaging as it is really only useful for local testing? It can still be kept locally just add the directories etc to the .gitignore. This way the unneeded items are not download with git pulls on new installs. Also due to the nature of the debs it has the installer script built in so it is another duplication of work when changes are made to your installer script.

Let me know what you think then I can remove or leave it and submit a pull request for the other changes.

** Edit **

Also during my SocketIO testing I found out that the api implementation cannot update a list of lists. This is an issue for example if you attempt to send an api request to update a probe profile it will erase all profiles besides the one that you posted due to it being settings[key]."update" I needed to add a separate function to handle updating lists of lists. It seems to be working ok so far.

def deep_dict_update(orig_dict, new_dict):
	for key, value in new_dict.items():
		if isinstance(value, Mapping):
			orig_dict[key] = deep_dict_update(orig_dict.get(key, {}), value)
		else:
			orig_dict[key] = value
	return orig_dict

[nebhead]

I plan on submitting a pull request soon with a huge overhaul on the SocketIO side and a change from Firebase to OneSignal notifications. While it still uses Firebase on the Google side OneSignal replaces my simple AWS server instance, adds better security and makes it so I do not need to maintain the AWS instance.

Excellent! I'm completely ignorant to the cloud side of things so I welcome your expertise here.

For the SockeIO side I really wanted to slim down the code as it was long and almost a duplicate of the flask side that needed to be changed with most PiFire updates. I took inspiration from your api changes and incorporated it into SocketIO. This way I can just build json payload on the Android app side and send them to PiFire. When a new feature is added I should not need to edit the SocketIO section. There are some functions like deleting keys, restoring data or triggering certain things etc that the api section cannot do so there is still some code that needed to remain.

That's great! I was kind of surprised at how well that API worked. My plan was to get Home Assistant using it, but I just haven't gotten around to it yet. Home Assistant is a beast to learn in itself.

I also added a setting so the startup timer can be adjusted. Recently with the lower temps I ran across many reignites and adding 1-2 minutes to the startup timer help prevent that.

I've been wanting to do that too so this would be another welcome addition to the project, thanks!

Anyway to the question. With the new Updater (which is really cool btw) it requires that PiFire is installed from git for it to work. I built and added the ant scripts to create deb packages as it was easier for me to deploy packages when testing and my thoughts were if you ever wanted to release versions then a deb would have been an easy way for people to install PiFire.

So I am thinking should we remove deb packaging as it is really only useful for local testing? It can still be kept locally just add the directories etc to the .gitignore. This way the unneeded items are not download with git pulls on new installs. Also due to the nature of the debs it has the installer script built in so it is another duplication of work when changes are made to your installer script.

Let me know what you think then I can remove or leave it and submit a pull request for the other changes.

I did take a look at the deb package scripts and they are very cool. I haven't actually used them, but I was wondering if they are any quicker or more reliable to install than the raw scripts. But yeah, it does kind of clash with the updater concept. TBH, if there was a better way to deploy updates from the internet using deb packages I might be game for that too.

** Edit **

Also during my SocketIO testing I found out that the api implementation cannot update a list of lists. This is an issue for example if you attempt to send an api request to update a probe profile it will erase all profiles besides the one that you posted due to it being settings[key]."update" I needed to add a separate function to handle updating lists of lists. It seems to be working ok so far.

def deep_dict_update(orig_dict, new_dict):
	for key, value in new_dict.items():
		if isinstance(value, Mapping):
			orig_dict[key] = deep_dict_update(orig_dict.get(key, {}), value)
		else:
			orig_dict[key] = value
	return orig_dict

Ah yes - I have the same issue with the code to restore the settings files, but it usually works because it's updating the entire settings from the file itself. This a is definitely something I should add to the API, so thanks! Looking forward to the PR. :)

Also, I just wanted to continue to say thank you for all that you have contributed to this project from the software to the hardware. It's all been extremely helpful. So thank you again! I feel somewhat ashamed for not having tried the Android App yet, but my work locks down my Android and doesn't let me side-load applications. :( I'm going to have to resurrect an old device to see if I can get it installed.

[weberbox]

Oh this is looking Awesome!! Cant wait to play with it. I think this will make the project a lot more user friendly to install and change around later etc.

Super cool!!!

Oh and not to be a dick but dependencies is spelled wrong. I noticed because that is how I always tend to spell it and the IDE underlines it for me lol

Oh and have fun at Disneyland with the family. I haven't been in a while the prices are just crazy now days. We have a $3 or 4 hundred dollar gift certificate that we still need to use some day. We are headed out to the desert this weekend for some off roading and camping. Much needed time away.

[nebhead]

Haha! Thank you for catching that. Oh man I rely on spell check soooo much. I'll get that fixed up before I submit it. :)

Have fun in the desert! We could all use some time off these days.

[weberbox]

lol I am the worst at spelling and it's funny because my wife was an english major so she is always on me about it.

[nebhead]

lol I am the worst at spelling and it's funny because my wife was an english major so she is always on me about it.

Oh, I can imagine! Now I'm slightly paranoid that I have tons of other spelling errors in the project. :P

I submitted the configuration wizard changes on top of the development branch. Your changes for keep-warm look great, BTW. I may try to use that today, just for fun. I have a couple of other additions I want to make for the configuration wizard, but I decided that I would just commit this today before I take off.

Just jotting down some thoughts, so I don't forget.

• I will change the module loading in control.py so that we can use the wizard manifest to select the right file name for import. This should simplify the code a bit and allow for flexibility if we add new modules later.
• I wanted to add try / except handling for the module loading so that if they fail for some reason, we can go back to the prototype modules. Just a little resiliency given that we have seen some people's systems crashing due to the hardware not responding, etc.

Lastly, I'm going to do a deeper review your PR changes, I promise! But it might be until week after next. I took a brief glance, and on the surface it looks good. But I wanted to grab it, test it, etc.

Thanks and have fun in the desert this weekend!

[weberbox]

Sweet. We made it out to the desert so I will take a look when we get back or if I get some down time with enough service to load it. I am excited to check it out and play with it.

On the exception checking I think that is a great idea. I was going to bring it up to see if we could come up with something since multiple things can crash control.py. Also maybe a pop up or banner that has a message that the module was disabled would be good as well. That way the user can see there is a problem and investigate.

Absolutely no rush on the PR that was mostly just so you didn't need to browse all the code to see what I changed. If you can see a better way of doing it etc.

Have fun down in my neck of the woods at Disneyland.

[weberbox]

I really liked the pills navigation in the setup wizard. It was clean and helped keep the page from being so long. I have been playing with it in the settings page and I think I like it. With all the options being added the page is getting really long.

The only downside is the navigation row looks terrible on mobile and makes the tabs row really small so I had to install flask-mobility and check if the device is mobile or a desktop. When mobile it shows the original style

[nebhead]

Nice! I had exactly the same thought about re-organizing the settings page, but hadn't gotten to it yet. This looks great! And great idea to incorporate the Flask-mobility module - that definitely makes sense to me. Feel free to do a PR when you think it's ready. :)

[weberbox]

So I wanted to get your thoughts on this.

With the new github updater you can run into issues when updating to a new version or when switching branches if new dependencies were added. You would need to update, it will crash or fail to startup after the reboot/restart and then need to manually install any new dependencies. I figured this out when Flask-Mobility was added and I updated my grill to the latest dev branch.

With some inspiration from your install wizard I though it would be cool to have the updater output be live with some feedback and have it install any new dependencies that were added.

This approach requires a manifest json file to be updated/maintained which was not my first choice but seemed to work out. There might be a better way with just catching exceptions on start but I could not get it working reliably when it was a major dependency

I did not send a pull request for this as it is early and I have not done much testing yet. Here is the commit if you want to take a look whenever you get a chance.

[weberbox]

Yes!! This is looking awesome and the p setting was a great idea.

Can't wait to try it out. Temps have been all over where I am at and I always forget to change settings before I start a cycle so this will be a great addition.

[nebhead]

Same! It was like 90F here yesterday (which is nuts for April) and 87F in the grill when I turned it on. Would have been a great example of where these settings would help.

Will hopefully finish up the UI today and get it pushed up.

[nebhead]

Well, I finally got it put together. Updating the settings UI was a beast. I am not proud of what it looks like in the JS, but hey, I'm a novice and I'm trying to learn. :) Did some testing with my desktop machine, but not on the real hardware. I'm going to give it a whirl tomorrow with a Tri-Tip.

[weberbox]

I pulled this down and wow it is awesome. I glanced at the JS and it did not look bad though I don't really know JS well :) Hopefully I will get to try it out this coming weekend. I was out of town this past weekend on a 3 day backpacking trip and now I am exhausted and sore.

I was able to add enabled/disabled toggle and a table to view the Smart Start settings in the Android app but editing and adding new items is kind of complex so I will need to study your JS to get and idea on how I can write it up in Java.

Hope your Tri-Tip was awesome.

Tri-Tip is one of our favorites. This is the recipe my family loves. My son begs me to make it.

[nebhead]

I pulled this down and wow it is awesome. I glanced at the JS and it did not look bad though I don't really know JS well :) Hopefully I will get to try it out this coming weekend.

Thanks! I'm just a novice at JS and so I kind of just feel my way around and try to steal where I can. The main difficulty was enforcing the temperature ranges so that users couldn't enter a value that was lower than the previous temperature in the list. It pretty quickly became spaghetti, but somehow it seems to work. Someday I may go try to clean it up.

I was out of town this past weekend on a 3 day backpacking trip and now I am exhausted and sore.

Oh man that sounds great, well not the soreness part, but the backpacking. It's been a while, but I do love to get away and do some backpacking. Last trip was to Point Reyes and it was a bit chilly, but overall really amazing.

I was able to add enabled/disabled toggle and a table to view the Smart Start settings in the Android app but editing and adding new items is kind of complex so I will need to study your JS to get and idea on how I can write it up in Java.

Just let me know if you have any questions, as I said above, my code is admittedly obtuse right now. Basically the way it's setup is that we have profiles, in a list (in the settings.json) and temperatures in a list that correspond to those profiles. The first temperature is the first profile, in that anything less than that temperature, will correspond to that profile. Then the next profile will correspond to the next temperature in the list, such that that profile is applied if it is less than that temperature. And so on... where the last profile is anything greater than the previous temperature in the list.

Hope your Tri-Tip was awesome.

It was, thanks!

Tri-Tip is one of our favorites.

It's definitely one of our favorites too, but haven't had it so often recently because prices for a full Tri-Tip are going up to over $10/lb which is a bit tough to swallow. Now it's more of a special treat that I try to make every couple weeks. :)

This is the recipe my family loves. My son begs me to make it.

That looks amazing! I love a good coffee rub. I think I used one in the past which was basically instant coffee, sugar and salt and it was really, really good. I might have to come back do that again some day.

[nebhead]

FYI, I'm messing around with the new Chart.js 3.x in PiFire today. There are some performance improvements and visual improvements over the 2.x version that is currently being used. Considering adding the streaming plugin to get smoother chart animation. Should be fun.

I've also been mulling around the idea that I would like to change-up the dashboard gauges. Though I'm not sure what I would change them to. There is a cool project here: https://bernii.github.io/gauge.js/ that looks super simple to integrate. Might consider giving that a whirl at some point.

[nebhead]

FYI... just used the new and improved updater for the first time and it's great! Seemed to work flawlessly. Nice job!

[weberbox]

Awesome. I have updated a few times now and it seems to be working great. I think the real test will be when some new dependencies are added. I did test and removed a few then ran the updater and it worked but of course I cannot anticipate everything that might happen.

[nebhead]

It's great! And I think it's ready for prime time on the main branch. If I were to merge dev back to main this week, would it break the Android app? Should I wait on that?

[weberbox]

It's great! And I think it's ready for prime time on the main branch. If I were to merge dev back to main this week, would it break the Android app? Should I wait on that?

I think it is good to go. It might break some function in older app versions but when you push to main I will do the same with the app and push a release that supports everything in the PiFire dev branch.

[nebhead]

Perfect! I'll probably start to prepare the merge for tomorrow. Stay tuned!

[nebhead]

FYI: I see that the Raspberry Pi OS is removing the 'pi' default user, which is a good thing for security but may mean that we need to update our installation scripts, etc. (https://www.tomshardware.com/news/raspberry-pi-default-username-removed).

Might be a good time to move to the .deb install option instead. I'm going to look into what needs to be changed in the bash install script for now, but I'm thinking of heading that way.

[weberbox]

I see you committed the changes for /usr/local. Awesome should also make installing PiFire on a non raspberry pi easier as well. I never like to install things to the user directories as they can change etc. I was surprised to see that they are removing pi completely, I mean it makes sense though. It was great for easy install etc. but the security vulnerabilities outweigh that.

[nebhead]

I see you committed the changes for /usr/local.

Yep, thanks for the inspiration! I saw this in your installation script and was like, duh, I should have done this from the start. :) Anyway, simplifies the install so that the supervisor config files don't need to be edited. I believe that was the only area that had a real dependency on the Pi user folder.

[weberbox]

I just did a fresh install on a spare zero w to verify a few things. I seem to be having issues with flask send_file() with max_age being an invalid argument. It seems it happens on any function that has it. It works fine on my diet-pi dev server but actual hardware it is a no go

Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/flask/app.py", line 2447, in wsgi_app
    response = self.full_dispatch_request()
  File "/usr/lib/python3/dist-packages/flask/app.py", line 1952, in full_dispatch_request
    rv = self.handle_user_exception(e)
  File "/usr/lib/python3/dist-packages/flask/app.py", line 1821, in handle_user_exception
    reraise(exc_type, exc_value, tb)
  File "/usr/lib/python3/dist-packages/flask/_compat.py", line 39, in reraise
    raise value
  File "/usr/lib/python3/dist-packages/flask/app.py", line 1950, in full_dispatch_request
    rv = self.dispatch_request()
  File "/usr/lib/python3/dist-packages/flask/app.py", line 1936, in dispatch_request
    return self.view_functions[rule.endpoint](**req.view_args)
  File "/usr/local/bin/pifire/app.py", line 1113, in adminpage
    return send_file(backupfile, as_attachment=True, max_age=0)
TypeError: send_file() got an unexpected keyword argument 'max_age'

[weberbox]

Looks like Flask 1.1.2 is the version pre installed

pi@testpifire:/usr/local/bin/pifire $ flask --version
Python 3.9.2
Flask 1.1.2
Werkzeug 1.0.1

pi@testpifire:/usr/local/bin/pifire $ cat /etc/os-release
PRETTY_NAME="Raspbian GNU/Linux 11 (bullseye)"
NAME="Raspbian GNU/Linux"
VERSION_ID="11"
VERSION="11 (bullseye)"
VERSION_CODENAME=bullseye
ID=raspbian
ID_LIKE=debian
HOME_URL="http://www.raspbian.org/"
SUPPORT_URL="http://www.raspbian.org/RaspbianForums"
BUG_REPORT_URL="http://www.raspbian.org/RaspbianBugs"

[nebhead]

Strange... here's what I get on my fresh install:

pi@pifire:~ $ flask --version
Python 3.9.2
Flask 2.1.1
Werkzeug 2.1.1

pi@pifire:~ $ cat /etc/os-release
PRETTY_NAME="Raspbian GNU/Linux 11 (bullseye)"
NAME="Raspbian GNU/Linux"
VERSION_ID="11"
VERSION="11 (bullseye)"
VERSION_CODENAME=bullseye
ID=raspbian
ID_LIKE=debian
HOME_URL="http://www.raspbian.org/"
SUPPORT_URL="http://www.raspbian.org/RaspbianForums"
BUG_REPORT_URL="http://www.raspbian.org/RaspbianBugs"

However, I installed this on a Pi Zero 2 W... I wonder if that might be the difference.

[weberbox]

Ok wiped and installed again. Seems flask is version 2.1.1. Not sure what happened but I must have been an idiot and messed up somewhere so just ignore this lol

Was also a Zero W (not 2) so should be fine either way.

pi@testpifire:~ $ flask --version
Python 3.9.2
Flask 2.1.1
Werkzeug 2.1.1
pi@testpifire:~ $

[nebhead]

Ha! Glad to hear it worked ok. Phew! I got a little concerned for a second.

[weberbox]

lol so did I

[nebhead]

FYI: I'm thinking of moving to a more regular cadence of merging the development branch to the main branch, and doing releases. Something predictable, like first Sunday of the month, or something like that. I feel like keeping on a regular cadence will force me to make sure I keep the main branch up to date and people are getting the best out of PiFire. Anyway, let me know your thoughts and opinions here.

Take care!

[nebhead]

OK, my current development branch is feeling relatively stable at the moment, even with all of the latest display overhaul changes. With that said, I plan to go forth and merge development back to main for a new release this coming weekend. Just a heads up for anyone who is maybe following along.

[nebhead]

Adding Annotations with v1.3.4-dev!

Spent a bit of time today adding annotations to the history graph. It still needs a little bit of refinement, but it seems to be working well. Grab the latest development branch to give it a test out.

[weberbox]

@nebhead Unfortunately I found a bug that was introduced when the dash.js was updated to properly clear the display notifications. Since the grill probe uses setpoints-grill for both the actual hold mode setpoint and the notification, when clearing the notification the grill hold setpoint is also changed to 0. This is not desired behavior and I am not sure what the physical grill will do if it is left that way for a long period. I guess it would kind of just be like smoke mode but with strange auger times.

I can think of three ways to fix this but there are probably more.

1. Revert the dash.js fix so the grill setpoint is not changed to 0 when clearing the notification. This will leave the blue "notification" setpoint on the display which is not really desired since the notification was cleared. The only good part about this is since the display does not show what the actual setpoint is this gives you an idea but could be misleading since it is related/associated to notifications in my mind.

2. Instead of using setpoint for both the notification and actual hold setpoint split them up and create a new variable like notif_temp or hold_point etc. but this would require it to be done a certain way to not break previous versions of the android app or require an update. For example if hold_point was used it would need to be automatically set from setpoint when in hold mode otherwise the app would break and require an update to specifically set hold_point.

3. Have the displays check if notify_req is set to false instead and clear the blue "notification" setpoint. This will leave the actual setpoint at whatever it previously was in the background but would clear the "notification" from the display. Since there seems to only be one notify_req so this would also need to split up into three to account for each probe having a notification. (This would also require an app update and break older versions)

Maybe I am looking at the blue setpoint wrong. To me they indicate a notification/setpoint since that is how they kind of work with probe 1 and 2. Maybe a better option would be to add something to the display that actually indicates a notification specific to a probe? I know there is the bell that comes up for any notification is that good enough? am I overthinking this?

[weberbox]

The app uses the setpoint kind of the same way dash.js does. When setting a hold temp it is just sending a json payload with setpoint grill and notify_req should be included as well i believe. For push notifications that is done from the server it just uses the same method as any other service. If there is a setpoint and notify_req is true the server sends a json payload to onesignal and they push it to the device.

I was thinking about it after and it makes sense to have two I think. That way you could have a notification or just set a temp to switch to hold or shutdown etc. I would think that you would want a notification when that happens but maybe not I guess.

The only trouble would be how to show both. The space is limited on the display and making it smaller would be bad for the tiny displays. Maybe a color change or a symbol next to it I dunno.

I was also going to look into showing the shutdown and keep warm icons when selected. I do that in the app now but wanted to see if I could add it to the server dashboard and/or displays as well.

The red flag and square with wavy lines

[nebhead]

The app uses the setpoint kind of the same way dash.js does. When setting a hold temp it is just sending a json payload with setpoint grill and notify_req should be included as well i believe. For push notifications that is done from the server it just uses the same method as any other service. If there is a setpoint and notify_req is true the server sends a json payload to onesignal and they push it to the device.

Got it. I'll spend some time this afternoon taking a look. Work has picked up a bit for me so I'm going to be busy this morning. Somewhere down the road, I think this part of the design is due for an overhaul. I'd like to make it more modular, such that we can have multiple ADC/RTDs and probes mapped to the ADC/RTDs as the user defines. That would mean a much bigger architecture change, but I think it would help with fixing these types of issues. But for now... let's go with the addition of a notify_grill_setpoint (or something), and work around the problem.

I was thinking about it after and it makes sense to have two I think. That way you could have a notification or just set a temp to switch to hold or shutdown etc. I would think that you would want a notification when that happens but maybe not I guess.
The only trouble would be how to show both. The space is limited on the display and making it smaller would be bad for the tiny displays. Maybe a color change or a symbol next to it I dunno.

My thought is to add another tick for the notification setpoint... but not have a the temperature spelled out for the notification setpoint in the display. That way, if you are in hold mode, the setpoint for the grill can still have a tick and the spelled out temperature, but the setpoint for the notification can be just an additional tick on the circle. In other modes (smoke, monitor), we could have it be a tick and show the notification setpoint perhaps. Or maybe that's too confusing. Sigh.

I was also going to look into showing the shutdown and keep warm icons when selected. I do that in the app now but wanted to see if I could add it to the server dashboard and/or displays as well.

Oh yes, that is a smart idea! I like it. You know, it would be nice to redesign the circles on the WebUI/Server so that they can display more information inside them. I'm restricted to what Circliful.js can handle - and I haven't spent too much time looking at different solutions, but that is an option. Either way, adding another icon for those modes would be cool! Nice idea!

[nebhead]

OK, just pushed changes to the development branch.

Basically, I just created another setpoint called 'grill_notify'. This setpoint is used only for notifications. Hopefully I've got the bug squashed where the user cancels the notification and the grill setpoint gets zeroed out. I've also modified the display so that it's got a blue tick for the hold mode setpoint and a yellow tick for the notification setpoint. I think this makes sense, since the bell icon is also yellow and the hold point text is blue.

I've done some basic testing on my PC with the pygame_240x320b display and it seems to be working well. Please give it a whirl on your side to see if it's working out. Then I'll let you go crazy with adding icons to the dash. :P

Thanks!

[weberbox]

Awesome. I have not been able to check this out yet unfortunately. I started a new job about a week ago so I am in training and trying to stay focused as it is pass/fail and if I happen to fail I am jobless lol.

Once training is over and I have passed or failed then I should have some time to see what I can do with the dashboard. Hopefully I don's have an abundance of time haha.

I also ordered a bunch of components from Digi-Key for the new 12v PWM PCB design. I need to go over the PCB again when I have some extra time and then get those ordered up.

[nebhead]

Good luck with the job! That is definitely the most important thing. :)

[weberbox]

@nebhead So I am starting to work on PWM a bit and I will probably have a few questions along the way.

1. Currently I am building a grillplat_pifire_pwm file with the intention of it eventually being merged into the standard grillplat_pifire. There are a couple of reasons for this. 1 is so there is less duplication of code. 2 has to do with setting up PiFire using the wizard. I figure in there it could ask if the user has a DC PWM fan or a AC fan and adjust the global settings accordingly vs it just using an entirely different grillplat file. Also if they are to stay seperate I think I would need to modify the wizard to be able to change settings without user display or interaction. The only way I see to change settings now is if there is a settings dependency but those are all shown to the user. There needs to be global settings indicating if a dc fan is being used so the question is would you prefer a separate pwm grillplat or for it all to be in the standard grillpat? During initial testing I think a separate file is fine.

2. I looked at faisalhusain007pull request to get an idea on how he decided to implement pwm. It was a good starting point but I do not think the fan speed control should be done in the grillpat file. It should be controlled from the control.py file similar to how smoke plus works. In my eyes the grillplat file is kind of like a hardware interface and not a place to do logic coding. We could do many things with pwm fan control including fan ramping instead of on off, adjust fan speed during start up or fluctuate with temp etc. This is all better suited to be in control.py for many reasons. I would prefer if all logic was in control.py do you agree?

3. I would also like to switch grillplat over to gpiozero. It is cleaner to write and we are already using it in the displays. This would cause some code in control and the the displays to change from a 0,1 checking gpio status to a true,false for checking whether the device is active or not. Also I think pwm is much better controlled in gpiozero. Any issues with making the change?

4. I have a question regarding the selector switch and how it operates. I looked over the code and from what I can tell the only thing it really does is cause the power relay to turn on during boot and remain on if the switch is in the on position. I reviewed the wiring diagram and I do not really see why this is needed. Maybe I am missing something but I only see this as a negative. For anyone using mechanical relays this means the power relay is energized 100% of the time once the grill is powered on if the selector switch is in the on position or jumped. This seems to create unneeded wear and electrical waste on the mechanical relay. I was thinking maybe this could become a wizard setup question to ask if they are running standalone or alongside the oem controller, this way the selector is just ignored if standalone is chosen, thoughts? Also when going to a DC fan the OEM controller really cannot be used anymore. Ultimately my question is why is the power relay continuously on after the grill boots when the work cycle would turn it on anyway?

[nebhead]

1. Currently I am building a grillplat_pifire_pwm file with the intention of it eventually being merged into the standard grillplat_pifire. 

I'm with you here, would prefer a separate grillplat file for the PWM version.

2. I would prefer if all logic was in control.py do you agree?

Yes, I think that makes sense. And if you have an AC fan, it could either ignore the PWM or could potentially simulate it if you have a SSR that can handle fast switching.

3. I would also like to switch grillplat over to gpiozero. It is cleaner to write and we are already using it in the displays. This would cause some code in control and the the displays to change from a 0,1 checking gpio status to a true,false for checking whether the device is active or not. Also I think pwm is much better controlled in gpiozero. Any issues with making the change?

I'm OK with that, I think. The module also makes it easier to setup threads to see changes in inputs. So that might be nice to implement in the future.

4. I have a question regarding the selector switch and how it operates. I looked over the code and from what I can tell the only thing it really does is cause the power relay to turn on during boot and remain on if the switch is in the on position. I reviewed the wiring diagram and I do not really see why this is needed. Maybe I am missing something but I only see this as a negative. 

OK, so this is a question that I have wanted to come back to because it is a vestige of the older design where I had both controllers installed in parallel. It used to be more stringent and prevent the PiFire system from operating if the switch was set, but it became more of a burden as I started to use the PiFire controller more and more. Thus I had changed this to really only prevent the Traeger controller from working by default.

I was thinking maybe this could become a wizard setup question to ask if they are running standalone or alongside the oem controller, this way the selector is just ignored if standalone is chosen, thoughts? Also when going to a DC fan the OEM controller really cannot be used anymore.

I think this would be a really good solution. This way we can retain the functionality for anyone that might still be using the old OEM controller at the same time.

Ultimately my question is why is the power relay continuously on after the grill boots when the work cycle would turn it on anyway?

Yeah, I suppose that it's not necessary at all. :) We can remove that functionality.

[nebhead]

@weberbox - Was thinking I would merge the current development branch to main for another release before we do any more significant updates (i.e. your impending changes). Am I OK to do that, or are there any issues with breaking the Android app?

[nebhead]

@nebhead it will break setting grill probe notifications due to the addition of grill_notify. I think everything else is fine.

I have already made the changes to the Android app with backwards compatibility. I have a release ready so go ahead I will push it once main has been updated.

Sounds good, I'll plan to push something soon then.

For the pwm stuff I was going to say maybe there should be a new branch based on development so it does not delay any pushes to master. I got a little carried away and did some code clean up etc so once ready it will be a pretty big commit. Also there are a lot of changes to control.py for pwm.

Ah, yeah, I was thinking a feature branch might be a good idea in this case. Let's do that. Would it be best for me to create a branch that you can raise a pull request on?

With pwm there are so many possibilities it is hard to keep on track. I started to experiment with fan ramping/cycling as well as PID PWM fan control.

I am having trouble deciding what will be the most effective usage of pwm.

PID control would be nice but I worry the auger pid and fan pid might clash. I did some initial testing and it seemed ok but only time would tell. In its current implementation this would override smoke plus so I do not like it as much.

Ramping the fan is neat but is it really better then just cycling on and off.

My thought for smoke plus is to do a gradual 5 second ramp up from 0 to maybe 75% speed (or whatever makes sense), hold this for 5 seconds or so, then hard off. I'm curious if the gradual ramp will encourage the smouldering to increase smoke output. Perhaps not, but worth a try.

My most recent though is to ramp or cycle but adjust fan speed based on the grill set temp.

I feel this is probably a good strategy - but I'm with you on your logic.

The best option for PID I think might be to have the fan and auger both controlled by the same PID so they are aware of each other but honestly that might be over my head on getting it to work or would take a lot of trial and error.

Do you have any thoughts on what you wanted PWM to be or do?

I'm far from any expertise when it comes to tuning or creating a PID (which is one of the reasons I borrowed the code from @DBorello). I did look into different PID libraries, but they were all basically similar. Frankly, I'm not sure how we would track two variable inputs into a PID. This will require some more research. If I recall, there was someone on the discussion boards who had some previous experience with industrial PID design. Maybe I can search through the old messages to see if I can find who that was.

[nebhead]

FYI - Just pushed a branch called 'feature-pwmfan' for you to use when you do a pull request in the future.

[weberbox]

FYI - Just pushed a branch called 'feature-pwmfan' for you to use when you do a pull request in the future.

Awesome I think that is the way to go for now since control will have so many updates.

[weberbox]

My thought for smoke plus is to do a gradual 5 second ramp up from 0 to maybe 75% speed (or whatever makes sense), hold this for 5 seconds or so, then hard off. I'm curious if the gradual ramp will encourage the smouldering to increase smoke output. Perhaps not, but worth a try.

Ok I was kind of thinking the same thing at first and wrote that function in with fade in, fade out and on time, off time as settings so you could decide how long the fade was and how long it was on and off for. I deleted it last night lol. The issue I ran into was dynamically changing the final speed since the ramping was running in a background thread. I will take a look again and maybe it will be easier to just ramp up once then hard power off.

This would conflict with the fan speed adjustment based on temp though so not sure how that would work.

My most recent though is to ramp or cycle but adjust fan speed based on the grill set temp.

I feel this is probably a good strategy - but I'm with you on your logic.

This idea came while I was testing the ramping and fan pid. I noticed that at a constant low fan speed it wanted to produce more smoke but that was only after the pellets were allowed smother. Hence the idea to still cycle but also run at a lower speed once temps are met.

I want to test that out this weekend and see if it is worth pursuing.

Do you have any thoughts on what you wanted PWM to be or do?

I'm far from any expertise when it comes to tuning or creating a PID (which is one of the reasons I borrowed the code from @DBorello). I did look into different PID libraries, but they were all basically similar. Frankly, I'm not sure how we would track two variable inputs into a PID. This will require some more research. If I recall, there was someone on the discussion boards who had some previous experience with industrial PID design. Maybe I can search through the old messages to see if I can find who that was.

This might be an ultimate goal but I have a feeling it will take a lot of time thought and testing to get a PID working unless we have a good starting point. I tried to quickly search around but could not really find much that matched the needs.

I have been trying to clean up control.py while I am in a rut thinking about what to do with pwm. Goal is to reduce duplicated code and fix most of the lint warnings.

So far I have combined manual and monitor into work mode that was a huge reduction alone.

I also combined the notifications so that code is not duplicated. Then decided to move that to a new notifications.py to help clean up.

Was able to take control from like 1800+ lines to around 980ish. It will need some thorough testing but it is working ok so far and will be nice not to worry about updating multiple work functions every time there is a change.

[nebhead]

Ok I was kind of thinking the same thing at first and wrote that function in with fade in, fade out and on time, off time as settings so you could decide how long the fade was and how long it was on and off for. I deleted it last night lol. The issue I ran into was dynamically changing the final speed since the ramping was running in a background thread. I will take a look again and maybe it will be easier to just ramp up once then hard power off.

Yeah, I think this might be the simplest... but might not be any better than simple on/off. Worth a shot though.

This would conflict with the fan speed adjustment based on temp though so not sure how that would work.

Yep, this sure would. :( I think for now, maybe we just get fan working for smoke plus.

This might be an ultimate goal but I have a feeling it will take a lot of time thought and testing to get a PID working unless we have a good starting point. I tried to quickly search around but could not really find much that matched the needs.

Let's maybe file this under future plans for now. Sounds like a tougher problem to solve and might need a more coordinated effort.

I have been trying to clean up control.py while I am in a rut thinking about what to do with pwm. Goal is to reduce duplicated code and fix most of the lint warnings.
So far I have combined manual and monitor into work mode that was a huge reduction alone.
I also combined the notifications so that code is not duplicated. Then decided to move that to a new notifications.py to help clean up.
Was able to take control from like 1800+ lines to around 980ish. It will need some thorough testing but it is working ok so far and will be nice not to worry about updating multiple work functions every time there is a change.

Awesome!! Thanks for doing the cleanup, this is something that has been on the back burner for me, but I'm glad you've taken it up. And good idea moving notifications out to another file. Makes it much cleaner.

[faisalhusain007]

Using 2 different pids caused a clash when i tested it. The auger eventually dumped too many pellets snuffing the fire out. I gave up in the end.

…

On Sun, 17 Jul 2022, 01:17 nebhead, ***@***.***> wrote: FYI - Just pushed a branch called 'feature-pwmfan' for you to use when you do a pull request in the future. — Reply to this email directly, view it on GitHub <#81 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AIZKCHAUSIRLD27KWGTFPLLVULVEDANCNFSM5NUTXGFQ> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[weberbox]

I was worried that is what would eventually happen. If the fan and auger are not aware of each other they will fight at some point. I thought of even having the same pid output control the fan and auger at the same time but I worry that is also not enough.

I think the same pid would need to control both but additional logic would be needed to prevent them fighting. It would require a lot of testing and different scenarios to eventually get it working properly. And lots of pellets to waste lol.

[weberbox]

Ok so I submitted a PR for the PWM Feature. It is a lot of changes including a ton that are unrelated to PWM. I should have done a few different PR's with PWM only and others with all the clean up etc. but when I got stumped on a PWM thing I just started working on other files/features so it all ended up in this branch.

Unfortunately I have been really busy with work and have not had a lot of time to test everything out. It will need quite a bit of testing since so much changed. I hope I can get back on it soon but I am not sure when that will be yet. I was contemplating just waiting until I could start again but figured I would just send it over so you can play with it if you want. It surely will need some bug fixes as more testing is done. I did a couple cooks on my table top but a few minor things changed since then.

I added a PWM control function that will adjust the duty cycle based on grill temp. This will probably need a lot more tweaking. It worked but I think it can do better.

I also messed up the commit history when I did a rebase and squashed some commits. I pulled in your annotations and data storage commits but they were squashed into my commits since they were somewhere in the middle of my own. I think it is showing it cannot merge due to conflicts because of this.

If you want to separate out pwm and the other changes I would understand and you can reject this PR. I can try to separate them but I cant give a timeline on when that would be.

[nebhead]

（°ο°）

That is a lot of work. I'll probably wait until tomorrow to dig in, but wow - good stuff. :)

I can definitely relate with work being busy. It's definitely picked up for me recently as well - on top of the fact that I've killed a couple of my old laptops which I was using to do PiFire development. Fortunately, I have a new laptop on order and will hopefully get back into the swing of things soon.

[weberbox]

Take your time no rush at all. It is a huge amount of changes lol.

Hope the new PC is awesome, bummer on the old ones but new stuff is always fun :)

[nebhead]

Take your time no rush at all. It is a huge amount of changes lol.

Man, you really cleaned up my messes. Style-wise and all, I owe you a beer (or twelve!). I've managed to merge these changes to the feature_pwm branch without much difficulty. I'll see if I can get it all merged into the current development branch... then I think it will be a tiny bit more difficult, but I going to try to merge my cookfile changes on top of that. That will take some time due the amount of changes there. But I do want to get all of this pulled together so that we can test.

Hope the new PC is awesome, bummer on the old ones but new stuff is always fun :)

Yep, I'm pretty excited. I'm going with a new Framework (https://frame.work) laptop, which is fully modular and repairable. Unfortunately, that means I have to wait a little while longer. It will teach me some patience I suppose. :)

[nebhead]

Well, I suppose I got a little excited and decided to go ahead an merge everything today (apologies to my day job). At this point, I have development, feature-pwm, and feature-cookfile branches all aligned with the latest. I fixed up the conflicts and did some cleanup after merging everything together. I've done some quick testing and everything appears to be working OK. Feel free to clone the latest and start banging on this version.

[nebhead]

I'm thinking it may be time to do another release from the development branch. Things seem stable and working well, so just thought I would throw it out there.

@weberbox - Let me know if there are any concerns with respect to the Android app.

[weberbox]

I'm thinking it may be time to do another release from the development branch. Things seem stable and working well, so just thought I would throw it out there.

@weberbox - Let me know if there are any concerns with respect to the Android app.

I do not think anything changed that will break the app so good to go.

I will work on getting the next version of the app released that include the new features in the dev branch.

[nebhead]

Thanks! Looking to do this tomorrow, after I attempt a rack of beef ribs.

[faisalhusain007]

Hey guys, sorry I have been a bit quite for the last year I guess, awesome work from everyone on this project. I was tinkering the other day (making a school boy error, running the latest dev on a live cook and almost ruining wifeys dinner plans..) with the latest dev. I found what might be a bug for me atleast. So when the startup time runs out everything crashes the only way back is to stop and restart control. Otherwise the igniter, fan, auger temps etc will freeze in their last state. Here I believe none of the safety features will work as control is broken.

Anyway the problem maybe linked to a new feature for detecting the lid open feature. This is what I managed to capture

• Control Settings Updated. Mode: Startup, Units Change: False
• Clearing History and Current Log on Startup Mode.
  Startup Mode started.
• Power ON, Fan ON, Igniter OFF, Auger OFF
• Igniter ON
• Auger ON
• Cycle Event: Auger Off
• Cycle Event: Auger On
• Cycle Event: Auger Off
• Cycle Event: Auger On
• Auger OFF, Igniter OFF
  Startup mode ended.
• Control Settings Updated. Mode: Smoke, Units Change: False
  Smoke Mode started.
• Power ON, Fan ON, Igniter OFF, Auger OFF
• Auger ON
  Traceback (most recent call last):
  File "/usr/local/bin/pifire/control.py", line 1110, in
  _work_cycle('Smoke', grill_platform, adc_device, display_device, dist_device)
  File "/usr/local/bin/pifire/control.py", line 772, in _work_cycle
  if LidOpenDetect and time.time() > LidOpenEventExpires:
  UnboundLocalError: local variable 'LidOpenDetect' referenced before assignment

[nebhead]

@faisalhusain007 - OK, updated the development branch with a a couple of fixes. Hopefully this should resolve the issue!

[nebhead]

I was thinking perhaps we should have a separate process that monitors control, my grill went nuts kept feeding pellets and the temp climbed dangerously high, by chance I saw smoke coming out the pellet box thinking that's never happened before, something is wrong, realised control was frozen managed to switch off and burn off the pellets by running the fan in manual mode.

I think this is a good idea for safety. Perhaps just a thread that monitors the main control thread for a heartbeat or something. and if it appears hung, then restart the entire process. I will add to my list of todos.

[faisalhusain007]

@faisalhusain007 - OK, updated the development branch with a a couple of fixes. Hopefully this should resolve the issue!

wow that was supper quick will check it out soon, Thanks for that

[faisalhusain007]

Ok looks like its fixed, at least the testing I have done, I was wondering if we could have the fan go off also when the lid open is detected or have it as an option?

[nebhead]

That could be an option, but I would worry that the pellets might not stay lit if the lid stays open for too long without a fan blowing on them. I suppose people could choose if they want that enabled.