Even though we still have some big plans, the software is gradually becoming more stable.
This means we want to pay more attention to small annoyances and possible improvements.
Bugs and important features will still be prioritized, but we can (and do) squeeze in small fixes.
That said: what are your suggestions for things that can be fixed or improved?
Temp sensor blocks take up a ton more grid space than the information they present. General optimization of the ratio between grid-space consumed and information presented would be appreciated.
Valid point. Most information presented is relevant for configuration, but not for day-to-day use.
As we get better at UI design, weāll likely see some general improvements to widget layout.
A more immediate solution would be to add a minimalistic display mode. This would remove the type name, and reduce title font size / space used by the widget toolbar. It could be toggled by an action in the widget action menu (dropdown button).
Would this be what you are looking for?
Something like that could work. Or just change the font of the sensor reading font and either remove the āvalueā label or place the reading to the right of that label. I feel like that would get this widget pretty close to fitting within one grid row. Anything that could make it either fit in a 1x3 block or 2x2 block.
Valid point.
Note that the PID widget displays the sensor, setpoint and actuator state. You can since recently also alter the setpoint from the PID widget (pencil icon). So you donāt need to have a widget of all blocks on your dashboard.
I was wondering whether I can delete temp sensor widgets that my PIDs depend on from the dashboard. If I can, I can just use the new metrics widget instead.
From dashboards: you can. The PID depends on a Block on the controller. The widget is comparable to a shortcut: it will show and let you edit the block, but you can delete or copy the widget without changing/removing anything on the controller.
Slightly different story for the service page: there we automatically render default widgets for each block found on the controller.
Suggestion-1: Display PIN actuator state on Spark screen.
I would like to know if/when the Spark is calling for heat.
Suggestion-2: Dynamic adjustment of āblockā color on Spark screen.
Allow color of block to be determined by some parameter that is relevant for the block type.
Using āsuggestion-1ā as an example, an actuator would get two colors, set color-1 when pin is āonā, set color-2 when pin is āoffā. A Mutex might could display color-1 when allowing the ācool-pinā to be āonā and color-2 when allowing the āheat-pinā to be on. An SSP might dynamically adjust between color-1 and color-2 (position along a linear gradient) based on the āsizeā of difference between current value and setpoint value.
Suggestion-3: Delete names from old blocks.
If a block is created, then later deleted, the name of that block is still saved somewhere. For instance, if I add a graph to a dashboard, names of deleted blocks still show in the list of choices in the graph configuration. AFAIK, the only way to delete these old names is to re-run brewblox setup and delete all history.
If any of these are not āsmallā, please point me to the appropriate github project where I can create issues.
Up-front display of important states is something we can add. Weāll probably be conservative with the colors, as information overload already is an issue.
Old names are still in the database because they do have data associated with them.
Both ignoring old datasets, and removing them are on the backlog. ETA depends a bit on how our current experiments with the service page work out.
Edit: I just noticed you said āspark screenā, and not āuiā.
It still sounds like a good idea, but may have to wait until some more high prio firmware issues are done (valve support, and an elusive bug with rebooting Sparks)
If you add a PID to the screen on the spark youāll see top to bottom:
Input: setting - actual
Output: setting - actual
Lines: P, I and D
Icons: for a pwm actuator it will show the on/off state
So the data you want is there, solid or outline dot for pwm. Too subtle?
Yes, itās quite subtle. I never noticed until you mentioned it. Itās pretty hard to see unless Iām close to the Spark screen. Aside from making it bigger, my only thoughts for indicating ācalling for heatā are a bigger dot, some type of animation (flashing dot? point-dot-circle sequence?) or, again, change background color of the block on the screen.
I think perhaps this is ultimately a minor point in the grand scheme of things. Iāll continue to rely on the āheater powerā indicator on my control box and also the BrewBlox web interface.
I think the suggestion for āSpark screen block color change based on block stateā could still be useful, but I wonāt hold my breath for it being anything other than lowest priority.
Kudos to you, @Elco and @Bob_Steers for doing an amazing job with this software!!!
Will the general direction of this product and the UI take it back towards something normal people who just want to brew could use? Iāve installed BrewBlox over my old BrewPi setup and iāve got it working thanks to your wizard and some notes, but it is running on the edge of my abilities with PID / mutex / rules etc - i just want to brew and control a couple of fridges. Appreciate the highly advanced stuff needs to be there in the background, but will there ever be a fully dumbed down overlay for people like me?
Yes. The general idea is to offer full customization during setup, and have a simple interface for brewing.
For common configurations you should be able to skip most of the setup by running a wizard.
Our approach to implementation is to first make it possible, and then make it easy. Right now weāre mostly happy with what is possible (especially with the standardization of actuators in the upcoming release).
The next big thing is to make whatās possible also easy. Think more wizards and default values, fewer buttons, and fewer technical terms.
In the meantime, feel free to point out what to you are the most confusing / complex aspects: we take things one step at a time, and itās good to get feedback on what is most in need of improvement.
Thanks Bob. I could show my kids BrewPi and they would know whatās happening, and where to change the temperature of the beer/fridge/profile. They would need to dig into a couple of blocks, worry about drivers and PIDās and the duty on PWMās and read about the knock on effect of tweaking the values in BrewBlox, i suspect the pure volume of information on the screen would deter any other brewers I have previously pushed towards BrewPi.
Iām pleased to hear (and see) that progress is good, and making it easy in future will be the cherry on the cake for brewers who want to start simple. Iām adding a second fridge (something I had in mind when I bought all this gear years back) and I am considering controlling the whole process as you guys add features. Great works, thanks again.
Thanks for the feedback, we are very much aware of this problem and it is our biggest challenge.
As you understand, creating an easy to use UI for a system that is really flexible and can be set up to control multiple processes for any brewery is much harder than the UI for BrewPi, which was a pretty rigid single process controller.
As Bob already said, these blocks will continue to exist, because they make the system configurable and flexible. In addition to these blocks, we will have more user focused UI widgets for common brewing setups.
More hierarchy in the UI is part of the solution I think, because now all these blocks exist on the same level and all attract your attention.
A simpler daily interaction interface on top of the blocks, with the full power underneath is what we need to build next.
The ability to do free rise fermentations for certain beers would be very useful.
Apologies if this is already in there but I have been moving house so I have only had the briefest plays with one of the earlier releases.
Itās something weāre aware of, but Iām not sure we have an issue for it. Iāll check and add if needed.
Edit: existing plans are to have min/max temp per point in setpoint profile. Setting your max to something silly high would function as free rise.
No timetable on it though. Current prio is to ensure that if you have a common setup, you donāt need to interact with low-level components.
As a temporary workaround, just disable your heater when you want to free-rise.
Cheers and I think you have your priorities right, just thought I would make sure it was down as something nice to have.
@Bob_Steers Assume this is a small request.
Would it be possible to have the Pump in the Process View interact with an actuator pin?
I was controlling my pump using a DC/DC SSR and the Actuator value symbol connected to a pin on the Spark, but this now only allows a Block Type of āMotor Valveā
Hope that make sense.