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