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.
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!