May I become a "Collaborator" and get this project moving again? :)

[apbarratt]

Hi @jbruce12000,

I’ve been exploring and using your kiln-controller project recently and would love to help maintain it if you’re open to that.

I noticed there are some great PRs and community contributions waiting to be merged which I'd like to review and work with contributers on some tweaks to get in place before merging them in then I'd like to put together a little selection of next steps for future development etc before I begin adding PRs of my own too.

I’d be happy to assist with reviewing and integrating them to keep things moving, it's not that I have a desire to change ownership or direction of course, just seeing that you've not had as much time to add bits and pieces to this project, which I think is a great starting point.

If you’re comfortable, you could add me as a Collaborator with Write access (that’s enough to review and merge PRs but doesn’t give admin control).

I totally understand if you prefer to keep things limited, I just wanted to offer support to help the project stay active.

Thanks for all your work on it so far, it’s an awesome base for a lot of us doing DIY kiln automation :)

---

If you're happy to take me on to help here, a few things I'd like to assist get in place hopefully for a next release in a couple of weeks will be:

• A release candidate branch, to ensure changes can be tried out by willing victims volunteers before they are merged into master and/or given release tags.
• I'd like to return the project to using celsius as the default temperature unit.
  • Whilst I've a little bias here, not being American, I do think it'd be good to keep in line with similar projects for 3D printing and CNC equipment by having these scientific units back to the default options. I also note that in my experience, web looks ups for things like "cone 6 temperature" is more likely to return results in Celsius, but perhaps that's just google trying to be kind to me because of where I live 😅
  • To prevent breaking changes, I'd achieve this by adding a temperature unit to the profile files, and where one is not provided, the temperature unit set in the config file will be used, (as is the current functionality).
    • Not necessary but desirable would be to update the existing files to use celsius.
    • The software itself will then display the profiles in whatever temperature unit the user has specified at display time only, but the json profiles can be saved in celcius or fahrenheit as desired. This will make the files infinitely more shareable.
• Scheduling within the graphical interface. Add ability to schedule when the kiln starts #59 already addresses exactly this, so my hope is to carefully review this and work with @mburazin to get that merged in.
• MQTT integration. Added mqtt logging for temperature. #217 adds this functionality and @mlodedrwale's work also introduces the next goal in this list that I'd like to see integrated.
  • MQTT is used in smart home technology to share sensor and control data between smart devices. Anybody who has ever used the incredible work from @home-assistant will know how frequently getting this data makes a world of difference. Think having the lights in your office blink to tell you your kiln has finished working, or voice assistants announcing that cool down is complete.
  • Whilst I've already fed back to @mlodedrwale that I think they should keep their PR more feature specific, I'm sort of tempted to use their whole branch as a starting point for the next goal which is...
• Default config file. Like using celsius as a default basis, this would actually be a reversion to the way picoReflow originally operated, by providing a recomended defaults configuration file for folk to copy over in there initial setup.
  • The biggest benefits to using default files like this is that people can submit PRs to this project without accidentally submitting their own personal configurations each time. Indeed, Added mqtt logging for temperature. #217 suffers from this problem, in which @mlodedrwale's personal configuration of thermocouple choice, etc, is contaminating the rest of the setup file. Ideally, like picoReflow we would have a config.py.EXAMPLE file, no config.py in the repo at all and the name config.py would be found in the .gitignore file to ensure it can't be accidentally committed to people's own forks and thus contaminating PRs submitted for contribution :)

That's the first set of big changes I'd really like to give in a November release if possible. In December, I'm most excited for introducing a fully graphical configuration screen. No more editing scary config files for people who turn pale at the sight of code ;)

---

Hope I haven't scared you off and you've managed to read this far, please do get in touch if you think I can be of assistance and take the load off finding time to keep working on this. You will of course always be the one I'm asking if you are happy for significant changes to go ahead, though I might sometimes fight my corner for why things are a good idea, it's still your project :)

Andy

[rondoc]

Hi if the software is going to be changed I suggest going to an Arduino as it has real interrupts etc. I am not a programmer but have a few thoughts that might be useful. Using the PID method works well but it is a tricky setup and cannot handle cold starts well. My suggestion is to have a profile as exists now but use a simple ladder to follow. Then the instructions for the prgm is. Start with lowest pwm and look at kiln temp at say every 5 minutes. Compare to.profile. If temp is too low increment the pwm.if too high decrement. It can continue like this until the kiln reaches max level. This will allow a cold start without overshoot. It also will track the profile close enough for ceramics. The PID is great for industrial use where it is need to keep a system at a fixed temperature. In my kiln.b4 the pi system I used a 16 power step control and 16 steps proved ok. The app as is works well for me but it would be nice to have BT as an alternate communication. Then you wouldn't need to be Internet or have a wifi. Ronald. Anger is usually regrettable, kindness rarely.

…

On Sat, Oct 18, 2025, 6:03 AM Andy Barratt ***@***.***> wrote: *apbarratt* created an issue (jbruce12000/kiln-controller#250) <#250> Hi @jbruce12000 <https://github.com/jbruce12000>, I’ve been exploring and using your kiln-controller project recently and would love to help maintain it if you’re open to that. I noticed there are some great PRs and community contributions waiting to be merged which I'd like to review and work with contributers on some tweaks to get in place before merging them in then I'd like to put together a little selection of next steps for future development etc before I begin adding PRs of my own too. I’d be happy to assist with reviewing and integrating them to keep things moving, it's not that I have a desire to change ownership or direction of course, just seeing that you've not had as much time to add bits and pieces to this project, which I think is a great starting point. If you’re comfortable, you could add me as a Collaborator with Write access (that’s enough to review and merge PRs but doesn’t give admin control). I totally understand if you prefer to keep things limited, I just wanted to offer support to help the project stay active. Thanks for all your work on it so far, it’s an awesome base for a lot of us doing DIY kiln automation :) ------------------------------ If you're happy to take me on to help here, a few things I'd like to assist get in place hopefully for a next release in a couple of weeks will be: - A release candidate branch, to ensure changes can be tried out by willing victims volunteers before they are merged into master and/or given release tags. - I'd like to return the project to using celsius as the default temperature unit. - Whilst I've a little bias here, not being American, I do think it'd be good to keep in line with similar projects for 3D printing and CNC equipment by having these scientific units back to the default options. I also note that in my experience, web looks ups for things like "cone 6 temperature" is more likely to return results in Celsius, but perhaps that's just google trying to be kind to me because of where I live 😅 - To prevent breaking changes, I'd achieve this by adding a temperature unit to the profile files, and where one is not provided, the temperature unit set in the config file will be used, (as is the current functionality). - Not necessary but desirable would be to update the existing files to use celsius. - The software itself will then display the profiles in whatever temperature unit the user has specified at display time only, but the json profiles can be saved in celcius or fahrenheit as desired. This will make the files infinitely more shareable. - Scheduling within the graphical interface. #59 <#59> already addresses exactly this, so my hope is to carefully review this and work with @mburazin <https://github.com/mburazin> to get that merged in. - MQTT integration. #217 <#217> adds this functionality and @mlodedrwale <https://github.com/mlodedrwale>'s work also introduces the next goal in this list that I'd like to see integrated. - MQTT is used in smart home technology to share sensor and control data between smart devices. Anybody who has ever used the incredible work from @home-assistant <https://github.com/home-assistant> will know how frequently getting this data makes a world of difference. Think having the lights in your office blink to tell you your kiln has finished working, or voice assistants announcing that cool down is complete. - Whilst I've already fed back to @mlodedrwale <https://github.com/mlodedrwale> that I think they should keep their PR more feature specific, I'm sort of tempted to use their whole branch as a starting point for the next goal which is... - Default config file. Like using celsius as a default basis, this would actually be a reversion to the way PicoRelow originally operated, by providing a recomended defaults configuration file for folk to copy over in there initial setup. - The biggest benefits to using default files like this is that people can submit PRs to this project without accidentally submitting their own personal configurations each time. Indeed, #217 <#217> suffers from this problem, in which @mlodedrwale <https://github.com/mlodedrwale>'s personal configuration of thermocouple choice, etc, is contaminating the rest of the setup file. Ideally, like apollo-ng/picoReflow we would have a config.py.EXAMPLE file, no config.py in the repo at all and the name config.py would be found in the .gitignore file to ensure it can't be accidentally committed to people's own forks and thus contaminating PRs submitted for contribution :) That's the first set of big changes I'd really like to give in a November release if possible. In December, I'm most excited for introducing a fully graphical configuration screen. No more editing scary config files for people who turn pale at the sight of code ;) ------------------------------ Hope I haven't scared you off and you've managed to read this far, please do get in touch if you think I can be of assistance and take the load off finding time to keep working on this. You will of course always be the one I'm asking if you are happy for significant changes to go ahead, though I might sometimes fight my corner for why things are a good idea, it's still your project :) — Reply to this email directly, view it on GitHub <#250>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AXA65GZXPGEO4P2QCWLX6VT3YI3CLAVCNFSM6AAAAACJRWR6RGVHI2DSMVQWIX3LMV43ASLTON2WKOZTGUZDQOBQG4YTQMI> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>