Is there any timeline for multiple control loops? Right now i am trying the new version 0.4.0 as fermentation controller in a test environment to see how stable it is. Next week i will test out the mashing functionality with around 60liter of liquid and around 6Kw heaters, But my intension would be to have separate probes and outputs to measure and control the fermentation and at the same time use the same Brewpi for mashing with its own tempprobes and outputs to control the mashing heaters.
Right now ther are lots of settings that needs to be changed and moved to change between the modes.
Ok. Today i received and installed a new TFT for my broken touch, Changed my spark to a Photon to be more future ready, and connected the SSR Expansion module which is working great.
Now i am eagerly waiting for multiple control loops
I would like to know when a new web interface will arrive. as we are getting all the new software features, the web interface or GUI to me is getting left behind.
This is near and dear to my heart; before the end of March I need to put both my fermenters on my glycol loop so I can lager two at once for Oktoberfest beers. If BrewPi isnāt ready for multi fermenters by then Iāll have to do the cheap controller route. I completely understand that these things take time, and if it isnāt ready, it isnāt ready, but I would like to know which direction I should be planning for.
Right now Iāve got my chest freezer running off cheap controllers, and it swings wildly +/- 1F versus my BrewPi controlled fridge which runs +/- 0.1F.
@Elco and @mdma I can see regular commits going into branches on Github so I know you are beavering away but any chance of a plain English update on this thread as to where things are please? Will the next release be 5.x and what is locked in in terms of features and fixes?
Really wowed by the project and hoping that I have jumped in at the right time, although even one chamber tight fermentation control seems a big step up from the STC-1000 asset the moment, especially with Brewometer integration stuff I have seen (glad you guys seem open to the benefits of additional data from other sources in your rewrite as it opens up some great possibilities).
That would be very useful, so that we can finetune our development of our own semi-professional brewery. Could you please post some sort of roadmap with a timeline of expected features next 6 months? Thanks!
a new communication protocol between Spark and server (including WiFi)
We are really focusing on modularity, so with these new pieces in place, it will be much easier to support controlling multiple processes and customizing your setup.
Iām going to try the new GitHub projects for planning and road mapping.
Once we have some basics in place, Iād like to explain the plans in a blog post.
I donāt have a road map ready to share right now.
Thanks for the update, if I may suggest another feature that would be VERY valuable. My RPi has in the last 6 months had 3 occasions when the SD card has been corrupted. Probably because of a power blip or something like that. I do have a surge protector for the RPi power now, but not a UPS. Online I have found different suggestions for making a backup of the active SD card. However, as a Linux noob, most of what I read was far too technical for me.
Just like you added that useful WiFi checker to the installation script, it would be great if you or someone that works with you on the programming, could add something to automate that backup. Either to a second SD card or USB stick attached to the RPi, or even to a Dropbox or Gdrive location. With simple instructions on how to resurrect the SD card if it gets corrupted.
Another important feature would be an automatic restart in case of communication problems in between raspberry and brewpi. Just happend to me again, no temperature regulation due to ābeeing unable to open serial portā (I will post further information seperatly).
And donāt blame my USB cables, they are expensive, have a ferrite and are only 10cm long.
Hi!
If you mean automatic restart of the controller, @elco did a patch a few revisions ago by implementing the watchdog interface of the Spark (not possible with the arduino). So, if the microcontroller hangs up, then it will reboot and your raspberry should connect again.
