Hey guys great work so far Bob and Elco. I was discouraged by the Brewblox UI, but feel I have an OK handle on it now. I do have a few very basic question that I hope I don’t sound dumb asking. How do you set a ferm temp for a beer? Should this be done in the cool pid, the heat pid, the beer pid, should you use either the fermentation profile or the beer pid? If you turn one on are there scenarios that the others should be disabled? Secondly what is the easiest way to turn the ferment temp control off? Disable all pids perhaps?
If you want beer constant mode, make sure you have everything enabled, and then set the beer Setpoint setting.
You can access it through the beer PID: the top pencil button.
To use a profile, add points in the Setpoint Profile widget: it will override its target setpoint.
Easiest way to stop all control is to disable heat and cool PWMs.
Hi Elco, Bob and everyone.
Let me begin by saying that i was a legacy Brewpi user, having bought the Arduino version back in 2014. Elco has done an amazing job and i’ve brewed a lot of successful batches with it and my modified fridge.
This year ive decided to upgrade to the Spark version which is, indeed, a lot more advanced than the legacy one.
I have to congratulate Elco and Bob for the ton of work they have put up with Spark and BrewBlox. I have installed the software on a fresh Pi without incidents and have read a bit of the technical documentation regarding blocks, PID, PWM, etc., connected the fridge (actuators, sensors) to the Spark and installed the “Classic Arrangement” via the interface.
BrewBlox is indeed a powerful environment to control basically anything and i see a lot of potential in it. However, im struggling with the UI which you guys have already said are working on improving it.
In my opinion, it seems to be too much of a “Dev” UI with too much widgets with information which is not usefull for a day-to-day use on a brewery. Granted that if you know by heart the mechanics of a PID algorithm you know how the system is performing, but as a brewer, i couldn’t care less. Its an additional unneeded worry for a brewday that can get stressful very quickly if something goes wrong. If you must have a manual nearby to quickly adjust a parameter… Its just not optimal.
Dont get me wrong, this information should be displayed but, maybe, on an advanced dashboard or something.
I loved the simplicity of BrewPi and the ease you could start/stop a fermentation and log process with the touch of one button. Maybe you guys can also do this but with simplified widgets that “aggregate” blocks and stop all PWMs, for instance. In a nutshell, a simplified UI more dedicated to get the job done and the technology doing it, hidden on the background. Again, for the control freaks, with an “Advanced” visualization option. A look more like Brumat by Siemens would be a dream!
Obviously, take this as constructive criticism and since i have a small Brewing R&D company, i will be more than gladly to help improving and testing BrewBlox.
Finally i have some questions and an issue im having with the latest Edge version:
As i stated, ive installed BrewBlox, sensors, actuators, and the “Classic Arrangement” dashboard. Everything went ok with the fridge starting to cool right away (another thing to fix). I could access the dashboard and the graphic and widgets were all working.
How do we tell if BrewBlox is logging information? For example, the graph data? Also there seems to not exist a master “start/stop” process button.
My fridge has a fan actuator. I just cant figure how to implement it on the process of the classic arrangement. I wish that the fan be turned on during cooling and heating and that it stays on for 5-10 min after cool/heating is turned off. Is it possible? How? The form of implementing relations between blocks is a bit unintuitive. I think this could also be simplified…
Since the initial installation, ive turned off the Spark and the Pi and a day or two later, turned them back on. Ive noticed that the “Fermentation Dashboard” was gone, with only the “Home Dashboard” on the list. The blocks are all there tough, which is a bit odd. Does anyone know what happened?
Which is the proper shutdown procedure of the system? Execute first “brewblox-ctl down” and then “shutdown” to avoid any data loss?
Sorry for the long post and i really hope to be brewing with BrewBlox very shortly
Happy to hear the system is working well.
The new step view widget could be used to implement the start/stop button for all actuators you describe.We’ll be adding a preconfigured step view to the setup generated by the classic wizard as soon as we’re satisfied that the step view is working as intended.
A major feature is that you can use the same controller to manage multiple unrelated processes. While we may implement a “stop everything” button, we’re somewhat reluctant to add the corresponding “start everything” button.
Medium-term planning is to add a dashboard that manages a control loop without you having to manage all components of it. This should somewhat resemble your description of a simplified UI to get the job done on brew days.
As to your specific questions:
If the service is running, it’s logging information. It may leave out some fields (values for disabled blocks), but by default logging is always on. To prevent database flooding, we only keep averaged values (1m, 10m, 1h, 6h periods) for data older than a day.
There is a feature in development to accomplish exactly this. Technically it can already be done using a clever combination of Blocks and settings, but we’re very much entering “advanced usage” territory there.
Do you have a preference for how relations should be set? We have multiple plans lined up, but ideas are always welcome.
This sounds like an issue with the database in the front end. Dashboards and widgets are stored separately from blocks and block names. For performance reasons we also first store values locally in the browser, and then synchronize with the remote database in the background.
Disappearing dashboards sound like the synchronization failed. This can technically happen, but should’ve displayed a clear error message. I’ll look into that.
Pretty much. To avoid SD card issues on the Raspberry Pi, it is advisable you use
shutdown -hinstead of the regular shutdown though. This make it:
brewblox-ctl down shutdown -h now
Thanks for the feedback! Most of our efforts right now are aimed at making the system simpler to use. Both positive and negative feedback are very helpful.
Hi Bob, thanks for your reply!
On the legacy BrewPi, there was a Button to start/stop logging and choose a name of the “brew” (file). Isnt it possible to implement the same on BrewBlox? This would eliminate the problem of db flooding…
First, the block relations.
It seems there are blocks that can be condensed in one. For example, an actuator can be on/off (a relay) or PWM (for example, a fan). Why not just create a block with both options and a drop list to choose the actuator? At the moment it seems to be more than one block to achieve this (1.PID -> 2.PWM -> 3.ACTUATOR). As for the the blocks input/output relations, have you guys considered something similar to the interface of NodeRED or even Blockly? I use a domotics software (Domoticz) that has Blockly implemented to “program” events based on sensor readings, actuators, etc, and its pretty much straightforward…
Now the FAN (or something else)
This could be an updated actuator block that has its input triggered with the same condition that triggers the “cool pin” block (as on the example). As for the time, this could be achieved with an “on delay” (it would only turn on after a set time) and an “off delay” for the opposite.
Can this scenario that happened to me be related to power off the Spark/Pi without running the “brewblox-ctl down” command? And how can i restore the “fermentation dashboard”? delete the created blocks, rename the actuators and run the wizard again?
On the weekend im going to take another look at the system to see if i can come up with more ideias.
Thanks again Bob!
Based on some napkin math assuming our current settings and 5 Spark controllers full of blocks (+/- 80) it’d be some years before size becomes an issue on a 32GB SD card. Your SD card is more likely to die from constant use first.
You can use the Session View widget to easily view data for specific brews: each session has a start and end date, along with the relevant fields in history.
From the perspective of the firmware the chain is
Analog Actuator -> (maybe)
Digital Actuator. The PWM is an analog actuator that has a digital actuator as output, but we may introduce more analog actuators. (
Actuator Analog (Mock) already exists, but doesn’t really count).
In the UI we’re already laying the foundations for reducing the number of blocks the user has to deal with.
This is where the concept of Control Loops come in. We want users to interact with the bigger picture (the control loop).
Further down the road, control loops will be integrated with the Process View widget, so you’re looking at a model of a brewery, with values or buttons in appropriate places.
For the foreseeable future, the core system is inherently declarative. Even when using pre-defined steps, the user initiates configuration changes. If someone wants to add Blockly(like) functionality, they’re welcome, but for us it won’t be a priority.
Node-RED looks nice. We already offer static relation diagrams. Making them editable is a logical next step. It’s also a non-trivial amount of work, so I can’t make any guarantees about time frames.
The current design for the Logic Block that would activate your fan is very much like the Mutex. The logic block would use have input(s), a Boolean logic flag, some additional settings, and an output.
- input: HeatPin, CoolPin
- flag: OR
- output: FanPin
This would turn on the fan pin if HeatPin and/or CoolPin are active, and only turn it off 5 minutes after the condition became false.
Disclaimer: the timeline on this is soon™, and design changes are very common.
It’s unlikely your dashboard disappeared during Pi shutdown. SD card corruptions usually manifest as weird crashes.
Deleting created blocks and re-running the wizard is one approach. You can also create a new dashboard, and select the “copy to widget” action for each block that you want displayed on it.
Thanks for writing all of that down @Titvs.
The modularity of the control blocks is what makes the system flexible and powerful, but it should not be
the daily use interface. We’re aware of that.
We’re working on more user focused UI widgets that interact with the blocks but have a more abstracted interface suitable for brew day. This will also involve blocks that configure multiple blocks for a specific brewing task.
The very first work towards that is the new step widget in which you can program multiple changes to blocks that should be applied at once. We don’t have presets yet, so we place the burden of knowing what to change on the user. The basics to control a brewery are in place now, so we can shift focus towards UX.
For the fan functionality, I have already started work towards it. IT will be a simple logic block that turns the output on whenever one of its input is active, possibly with a start or stop delay. This block will also be needed to control a pump for a glycol system with single pump and valves branching off to each fermenter.
Regarding logging, we log everything all the time in BrewBlox. So even afterward, you can get your data for a brew. You don’t have to start or stop logging.
With the session widget you can define a session as a start and stop date and a set of data keys. But I don’t like the complexity of the interface myself.
I think we need a global UI concept around brewing processes, like tagging each block to what it belongs (fermentation, mash, etc). This will help to bring some structure to the big pile of interacting things.