Awesome! Cant wait for the beta too
@Elco and team, just wanted to follow up with you guys and see what type of time frame you think the Beta might be looking at currently? I got mine updated to 5.10 you had mentioned October, and then additional coding you are incorporating. Just curious on what to set expectations around. Thanks again for all your time and hard work I know we all really appreciate it.
Hi @Elco,
Kudos to you and your team for all your hard work building a great product, running a company, re-writing the software from scratch, and remaining active answering questions in community forums. I too am excitedly awaiting the new software release and would like to share with you my sentiment that it [software] should be released only when it’s actually ready. Anything short of that will result in more time spent fixing issues and responding to complaints than if that work [testing] is done up front before release!
To anyone else that is finding it difficult to wait for the new software, I suggest spending your time reading: The Inmates Are Running The Asylum, which is full of real-world examples of failed companies due directly to rushed or poorly designed software.
The target release date is just a goal that was based on best estimates using information available at the time. If the original goal wasn’t met, a new goal can (and should) be made, but it’s not a guaranteed delivery date. Similarly, if a house isn’t ready by the deadline, one can’t simply move in early, a new goal must be made, based on new best estimates. Writing software is a highly complex venture that requires immense amounts of time and energy. A good product will last many years, and even then, is usually re-written after some time due to the nature of patching over time. Hence the very fact that @Elco is re-writing BrewPi from scratch right now and we are all waiting for it. It is the nature of software.
Cheers,
–Andy
1 Like
Thanks for all of your input and support 
Here is a short status update:
Real world hardware test
We started testing the full stack, including hardware and were happy with the results. Naturally, some bugs came to light but we had a successful test with the new platform (which will be called BrewBlox) controlling actual water temperatures.
In BrewBlox, there will be no static or pre-configured control loops or sensors. The user will have complete freedom to create blocks on the controller. A block can be for example a sensor, setpoint, PWM driver or PID.
In our test scenario we wanted to control the temperature of two water cookers, with the following caveat: we do not have enough power to turn both on at the same time. This is very much like most brewers having to choose between powering the HLT or the boil kettle.
So we set up the following blocks. This probably sounds really technical, so we doing our best to create easy to use wizards for setup.
To drive each water cooker, we set up these blocks:
- A OneWire temperature sensor
- A Setpoint
- A digital output pin
- A PWM driver to toggle that output pin
- A PID to control the PWM driver based on the sensor and setpoint
In BrewBlox, a list of constraints can be set on each of the actuators. For digital actuators, this is the minimum ON time, minimum OFF time or mutual exclusivity. For analog actuators (actuators with a range), you can set a minimum, maximum or balanced.
So in this case we have the 2 digital outputs sharing the same mutex so they alternate.
The two PWM actuators shared the same balancer so they get an equal share when the sum of their values goes over 100%.
With this setup, we could keep the 2 water cookers at 90 degrees without problems, with live data streaming to the UI widgets. We also have live updating charts, not only of the temperatures but also all internal PID parameters and every single variable in the system. This will be very helpful to analyze PID response and tune the settings.
UI progress
Lots of UX. We simplified creating dashboard widgets, improved block creation wizards, auto discover sensors, moving/copy/rearrange/delete blocks and widgets and many small usability and architecture improvements.
Deployment on the Raspberry Pi.
We also ran the entire stack on a Raspberry Pi 3. Some small bugs arose that require attention, but overall no serious issues. The Raspberry Pi 2 did not run well, so we’ll have to figure out why because we don’t want to force users to buy a new Pi. The Raspberry Pi 1 is probably a bit underpowered, but we will see how far we get.
Next major steps
- Hardware display: the Spark still shows a blank screen, we have not written new code to drive the TFT display yet.
- Support for OneWire expansion boards: I still need to create the blocks for our valve control boards and SSR extension board.
- Simplifying deployment. It is already pretty simple with a docker-compose file to create all the different microservices involved, but it is still complex. I think we should have a preconfigured raspberry pi image that requires only some small changes on the SD card before it is transferred to the pi.
- Simplify initial setup by having a lot of sensible defaults that work for most users.
- Default settings for common use cases (like PID settings for mashing, fridges, glycol)
- Styling of many UI widgets to be easy to recognize and use. The widgets look very much alike. A single glance should be enough to get the info you need. Lesser used settings and values should hidden on the dashboard and only shown in the modal popups.
- Lots of help buttons and text to explain what all the features are and how they should be used.
When can I get my hands on it?
As Andy said above, releasing too early is bad. And I think it is too early because you probably don’t want to spend a lot of time dealing with small frustrations that together eat up a lot of time.
Theoretically, the system can already be used to control a fermentation or mashing setup. But getting it set up is not smooth yet so we would like to take a bit more time before releasing a public beta.
We’re currently working with some test users that have been part of the development process and know their way around Docker, Linux, compiling firmware and debugging in general. Their feedback is very helpful and enough to improve our software and process. The software development process is completely open source, so we can’t stop anyone from trying the new stuff, but it is probably best to wait until we have made it a somewhat smoother experience.
We don’t want to hold back the software until it is perfect or complete, but a smooth deployment an absolute requirement. Once we have that, the first brave test users can try the new stack. My best estimate for this early beta release is 1-2 weeks.
If you are a UX/web designer who’d love to help us with icons, colors and widget design in Vue, get in touch for early access. Our firmware can also be simulated as a virtual controller, so doing UI work doesn’t require any specific hardware.
What will come later
Process management including the flow views, brewing steps, and valve control will not be part of the first release. The system is usable without it and it should not hold back the release. Our first release will do everything the current BrewPi does and more though.
I’ll try to make a demo video on our next hardware test!
7 Likes
When you say valve control won’t be in the first release, do you just mean for mash setups or do you mean at all? If I read right, glycol should be possible with the first release?
Will multi-process be possible in the first release?
Multi process will be possible, valves can be driven. What won’t be in the release is this type of UI to toggle many valves at once:
https://brewpi-ui-demo.herokuapp.com/processview/herms-automated-valves
Fantastic! Can’t wait. Thanks.
Elco, thank you and everybody else that has helped get BrewPi to where it is today. BrewPi has come a LONG way over the years. I’m really excited about the new platform. I do have one hope however, that I can still use my Tilt with the new BrewBlox setup. Monitoring / controlling temp is important but SG dictates the process (when to do a diacetyl rest, when to cold crash and when fermentation is done). The ultimate power would be to be able to automate temp changes based on SG (provided by something like the Tilt) and not time as that is not a true indicator of when the beer is ready for the next step.
At the end of the day, this platform is amazing and has made brewing just that much better. I did a presentation of BrewPi at my brew club and people were amazed this kind of tech exist. So keep up the good work guys!
Chris
2 Likes
We already took into account external integrations and will be able to add tilt support shortly after launching the base functionality.
I also have a long term project for a more accurate SG sensor that I’d like to use for controlling fermentation rate, with temperature being an intermediate force instead of the goal.
First things first though, the framework that will enable all of that.
5 Likes
That would be really cool. Especially if it uses non-reactive materials. The main reason I haven’t gone for a tilt-hydrometer is that I have reservations about immersing a polycarbonate container in my wort (especially for sour beers).
Hey!
Any new updates?
Would love to be able to create my own layout in the heroku app demo, if only for designing and thinking and discussing while now building my entire new system!
All updates appreciated!
@glibersat, a BrewPi contributor and owner of microbrewery Le Singe Savant in France has been brewing on the new software for 1.5 week now as our first tester. Together we found some small bugs which were quickly fixed, but overall it’s running very well.
We’re now finishing these last things we want to have ready before public beta:
- Make deployment as easy and future proof as we can now. This includes first install, firmware updates and docker pulls without losing data.
- UI improvements to explain how things work and have wizards for more complex setup tasks
- LCD display on the Spark itself. I think running blind without a on device display will make it harder to identify issues and get start for most users.
- So many of the list earlier are is still ongoing, but close to finished.
Real world testing has given us the confidence that the software is mature enough for the first users to start brewing with it. We’re mostly working on stuff to make the upgrade process smooth now.
The UI as demoed on heroku will not be part of the first release, but is expected to be ready in February. If you want to play around with a layout, the layout is editable as json files in the mocks directory. It’s a time consuming process though, it would be much easier with drag and drop.
2 Likes
Thank you! I actually cloned the repo and started editing the json but have up halv way through. it was BORING.
It’s the UI im actually most interested in, will it be released on github as opensource when it’s finished? Or can I pay to get my hands on it for my brewsystem?
Just wanted to let you know all that @Elco & all the team did a FANTASTIC job, it was worth waiting!
Using the new firmware, we can now preheat our BK + HLT during night at the same time and during brewday, the load balancer allows us to let everything run without caring about what is heating and risking a power surge : we now save a lot of time and required attention during a batch.
The UI is also quite great to use, still at the moment, targetted at advanced users but if you’re comfortable with advanced settings of brewpi and you are a bit adventurous, you should be delighted to try it, docker deployment (great Bob for that!) makes installing it a breeze.
Cheers! 
Can it be istalled today on a RBPi3 for testing?
Sure! But don’t use it for production yet, have a separate setup
You can use the following repository: https://github.com/BrewBlox/brewblox-deployment
Enjoy!
1 Like
Dumb question - I know it is still in Beta and @Elco and Team are still working out the bugs and a few other support pieces I am sure. If one upgrades to the new software firmware upgrade and things go wrong can we go back to the old firmware. Also, I know with my current setup the new software is what I have to have anyways, so I just want to make sure if I go down this path its either “no turning back” or yes you back backup if need be? I would like to start messing with it, since my electrician is working on the panel right now.
You can always go back to the old firmware. To make it easier, use a new SD card and install the new stack from scratch.
I have one important item left on my TODO list before beta release and that’s adding sensible default settings for each block you can create. Nothing is stopping you from following the instructions on above link, but that’s stopping me from officially putting it out here.
We pushed a lot of breaking changes last 2 weeks, so if you switch earlier you know what you’re in for.
Good luck with the last bits there Elco&team! Don’t feel rushed by deadlines and be proud of your product and hard work! Everyone is looking forward to it.
2 Likes
I fully appreciate this is in a pre-beta stage, and don’t expect any support, …but… 
I have successfully installed BrewBlox using the guide linked above, and flashed the spark, all worked well! Is there a getting-started guide on how to get running with a basic fermentation chamber (one-wire probe in fridge, another probe in beer and control of chamber heating and cooling as per standard BrewPi setup) ?
Or alternatively… is there a simple step to revert the spark back to BrewPi firmware so it can be returned to the old environment easily?