Software progress

Hi Elco et all,

I am a seasoned brewer who also likes to build things. I am not a coder. I hate to ask these questions and/or make the suggestions but I feel that I need to!

Please could you shed some light on what progress is being made with the software for the BrewPi Spark platform??

Some will cringe at another user asking and say this is a collaborative open source project etc but the reality is that most users have parted with a reasonable wad of cash to buy the Spark hardware. This makes it much more of a commercial offering and comes with it a need to fulfill reasonable expectations. If BrewPi was just freeware for my PC, I would be full of nothing but praise. But it isn’t.

Many will be happy to have something to tinker with but I can see lots of us who are feeling disappointed. There are some, like me, who are also starting to feel a little misled. I don’t say that lightly but the reason I say that is because your product shots for the spark show a HERMS screen in use, which is seemingly not near even a beta release. The transfer of previous arduino functionality to the spark with wifi was described as essentially a straight port and yet we still don’t have a stable release or user documentation. The (for me) deal breaking added functionality of direct actuators and multiple ferments was also made out to be a mid term goal.

I was all poised to document my build and shout about BrewPi spark over at Jims Beer Kit, one of the main UK homebrew forums but feel I cant right now.

You may be making more progress than I/we realise but without an active blog, a website that is out of date nor any updates/milestones in the community we just don’t know what is going on. GitHub is not user friendly for non-coders like me and expecting us to trawl through that looking for clues is probably a bit far!

I hate to gripe but feel its only fair to let you know that some of us are really bummed to not be able to use the Spark properly yet. Feel like we could/should have waited and got an RPi 2 and with a Spark photon etc. The last thing you need is returns to deal with.

BrewPi is a great project. I just think you need to recognize the need to manage expectations and be totally clear when you are selling accompanying hardware that runs into the hundreds of euros.

All the best,

Dean.

5 Likes

Does anyone else feel the same way? I hate to admit it, because I absolutely love this project, but I can’t help but agree. In some respect, I think the spark was released too early. Now I’ve spent over 200 euros to build get the parts needed for mashing, and I can’t do it until an update comes our way. Just a little disappointed, but I have all the faith in the world that it will be worth it when Elco gets it all sorted. Please, @Elco, please get this sorted!

2 Likes

The only part of the original post I can comfortably get behind is that the product shots, e.g. the BrewPi Spark store page, are misleading. The system is not ready as a brew-day controller for HLT / mash tun / kettle (hopefully soon!).

But it’s absolutely a reality that fermentation control is working, and far better than using something like an STC-1000. It’s also a reality that the Spark platform is more noob-friendly than the Arduino was. Personally I wouldn’t have taken the plunge during the days of the Arduino platform and I suspect I’m not alone (BPi was my excuse to finally get into the larger Raspberry movement). The way I see it, migration from Arduino to Spark fostered a larger base of users & project contributors, which is essential at this stage of the project.

To be fair Elco is, AFAIK, still a student at university and juggles the demands of his studies alongside all that coding, maintaining a website and forum and store, working with hardware suppliers, etc. It’s true that a lot of BPi documentation is lacking, but having worked on software most of my adult life I know that documentation always comes last and just about anything can divert me from finishing it.

So I figure that as payback for Elco’s efforts it is now the job of the rest of the community to pitch in. Plenty of us have successfully set up a BrewPi and could flesh out the Installation docs for the benefit of noobs, write some best practices, provide example setups, etc.

So my first ask to Elco is: what will it take to enable more editors of the documentation? The forum is intentionally limited in that Random Person X can’t edit an original post by Random Person Y, although in the case of the Software Install Guide that would be a useful feature.

Second ask, echoing the OP: a rough project roadmap. I’m not even talking about milestone dates but rather just a simple ordered list, i.e. will 3-vessel mash support come before multi-chamber fermentation support, or after? Or when will us crazy Yanks be able to purchase all the mash hardware with NPT thread?

1 Like

I think your assessment of the situation is very fair and I must admit that things have not run as smoothly as I thought they would. To correct Dan, I am officially still a student, but have been working on BrewPi full time for the past year. I have been postponing my graduation project for quite a while.

Software
I planned for us to be much further with the software, but a couple of things took more time than expected. Among those things are:

  • While porting the software to the Spark platform we found bugs in the old software that needed to be fixed. We rewrote a big part of the OneWire communication classes to increase reliability and speed. This will be released in 0.2.8. Moving to the new platform also exposed weaknesses in how we handle serial communication.

  • At first I planned to start with a text based UI as in the mockup to be able to release quickly. We came back from that plan and decided to use eGUI to build a proper UI from the start which would enable us to use buttons coupled to touch screen support. This took a lot of our time. You got a glimpse of this with the hardware test screen and a non-touch UI showing beer temp, fridge temp, room temp, current state and timer will be in the next release.

The past 2 weeks I have also been working a lot on the update process: refactoring the programming script, the setting restore script and downloading releases straight form GitHub. I want updating BrewPi to be a single command, without you having to upload any files.

So to answer your question about it being a straight port: it turned out not be. Partly because we needed to refactor the old version, partly because we added new functionality (with the future in mind).

All that other stuff
We did not just release a new controller, we also released a new shop and a lot of new products. Then it turned out the that the shipping plugins were not working correctly, the invoice format was not good enough for customs, and so on… I also rented an extra room in our building and set up a new warehouse.
All these things are to run smoother in the future, but it took a lot more time than I anticipated.

Matthew and I both got sick with the flu, which delayed us about another week. Matthew also has a day job and is doing BrewPi development in his free time.

I know that our website is horribly out of date, but I have had higher priority things on my list.

Getting help
I know that I am juggling too many balls. I am going to hire one or two students to help me out with the simple tasks that should not take up my time, like processing orders and assembling products/kits.

We were managing our sprints in Jira, but are going to try moving towards GitHub issues with ZenHub on top for our next sprint. This will make our road map and current activities public and will allow to community to help if they can.

Mashing
I do realize that mashing has been the reason for a lot of people to buy our hardware. The main addition that is needed in the software for this is PWM support. PWM is needed to be able to not run the heating elements on full power. The first implementation for this will be fairly simple, but already better than any STC-1000 can do:

The HLT/Fridge temperature error will result in a PWM value by simple scaling it (configurable).
The beer PWM will get its value from the PID + scaling.

With these two new actuators, you can have a direct beer heater for fermentation or a coupled HLT+ mash, where the HLT temp is dynamically set by the mash PID.

This will be part of the next sprint.

Multiple control loops
To run multiple control algorithms at once (multiple fermentors, mash + fridge at once), much bigger changes are needed. Every bit of the controller, data logging and web UI should be flexibly configurable. We suddenly don’t have a chart with 3 lines, but have a configurable chart with any number of lines. This requires a new database and a new graphing framework. Our prime candidates are inFluxDB and Grafana.

We already started with the controller, but decided to get something working with the old framework first.

Summary
To summarize: I fully understand your frustration and I have been feeling frustrated myself.

There have been many tasks that I did not account for, but now we are finally hitting a point where we are not fixing old bugs and can focus on new functionality. Please hang in there. The hardware you bought is capable of all the things I promised and we are working as hard as we can to implement all features in software. We are going to release often, but needed to make sure the update process was smooth first and the foundation was sound.

I understand that most of the frustration is about not knowing what our progress is and that most of you guys just want better updates. With moving our development planning to GitHub, I hope we can offer that transparency. We will also have an easier to read road map on this community.

Firmware roadmap
0.2.8: OneWire and serial stability updates, new controller UI (no touch), compiling for Arduino again
0.2.9: touch UI, preliminary mashing support (with control based on 2 sensors)

7 Likes

Thanks @Elco for your honest reply and to the others for illustrating the mixture of feelings in the community!

If routine tasks are taking up too much of your time and your sales are strong enough to warrant some assistance, getting help seems like a no brainer. We need your expertise elsewhere!!

I’m a CEO of an organisation with a 100 or so staff. So I can totally understand that feeling of well-meaning desperation when a project gets delayed, changes or increases in scope. We will get there but hopefully my small bit of input can help you keep your customers/end users on board whilst the more technically minded contributors work on the project itself.

Thanks for the explanation about the porting process. I would echo what @Cxp073 said. It was probably a mistake to release the hardware before the software was even nearly ready, some beta testers perhaps would have been better. Still that’s done and what matters is the future…

Honestly, I would implore that you either start blogging on the main site about any and all progress or find another highly visible outlet for general bits of updates. Even if they aren’t technical. At the end of the day this is also a fan site in many ways and we need those types of articles to chat about and to be able to encourage observations, contributions and suggestions. So please don’t rely only on Github/Zenhub/Jira - they may be great tools for coders to collaborate but I’m not sure they are the best way to communicate with your end user/brewer base.

I wouldn’t underestimate the depth of support for a really good fermentation controller that isn’t HERMS enabled. If the BrewPi Spark had a polished set of software, WiFi and direct actuators working properly I would be quite happy to go out and shout about it to others. That alone represents good value for money. Multiple ferments will be a big draw for getting semi or entirely professional brewers to take note but it can wait if it is a real headache.

Obviously the brew day capability is an incredible bonus I look forward to (and for some it will be more critical) but I would be tempted to ensure the fermentation capabilities and fundamentals like WiFi, the GUI and the layout/design of the web page are perfected and stable before moving on. That way you have an entirely brilliant product to sell and end users can understand (and test the PWM support etc) whilst you pursue HERMS as the next phase.

Hopefully you might find some points of use here and it doesn’t come across as patronizing or complacent.

Inevitably I want to ask for approximate timescales for 0.2.8 and 0.2.9

Dean.

PS - Whatever happens with BrewPi. Don’t let it screw up your studies, do what you have to do… Some things are more important than beer, though not many!

1 Like

Yes, that would have been my first question too! I can appreciate everyone is chomping at the bit for updates and features they would like to see implemented. :smile:

0.2.8 is coming at the end of this week
0.2.9 will be 2 weeks later.

Our intent is to ship a point release every couple of weeks with new features, and update a wiki here with our roadmap. With the roadmap in discourse, we can get an indication from this great community what features we should prioritize.

1 Like

Cant believe I got a date out of you :smile: Even though I am a bit cheesed off, those dates still give me a flutter of excitement that I can use BrewPi for situation some time soon. Fingers firmly crossed!

I think that a two weekly release was mentioned before but never adhered to ? Perhaps it is better to set an intended release date for each milestone? That way you can allow yourselves enough time to do whats required rather than being on an arbitrary 2 week treadmill!

I all too aware that my views of what is a priority might not match the wider community, although I think most are yearning for progress. A wiki or similar would be good to get the community to list bite sized features/improvements in their order of priority.

Items that come to mind off the top of my head and in my own priority order include…(I’m ignoring the Arduino as I do feel that should be a legacy device once the rewrite/port is complete).

  1. Stable release of previous Arduino functionality for the Spark
  2. User documentation for the above
  3. Solid wireless connectivity between Pi and Spark
  4. PWM support for direct actuators such as my fermwrap heaters and/or glycol chillers
  5. Multiple fermenters (with one chamber/actuator)
  6. Multiple fermentation chambers/instances
  7. Updated design of the web page and graph functionality (Layout, incorporate a web cam etc.)
  8. Specific gravity sensor development and inclusion.
  9. HERMS monitoring and display, manual operation.
  10. Full automated HERMS functionality
  11. User documentation for the above
  12. Integration with BeerXML or similar to allow fermentation profiles and/or mash schedule to be imported or shared with software such as BeerSmith.
  13. Options for view only access or other medium for sharing a brew’s process with friends, cloud based or otherwise.

Really hoping to see a stable documented release soon so that I can properly unbox the Spark and dive in.

Thanks,

Dean.

Illness, day jobs and other comittments can disrupt the schedule, as they did recently, but other than that, internally we’ve been holding to a 2 week release. The releases weren’t made public until functionality was at the level to support expected use cases/user stories.

Delivering every 2 weeks ensures we don’t head down a rabbit-hole of constant feature creep. Not to be too critical of previous work, but the previous brewpi major release was delayed months simply because of the desire to get in extra features, that were of course useful, but no reason to halt delivery. It also means we can respond quickly with bugfixes and features that can be coded in a Sprint, while still allowing for larger features to be developed over multiple sprints. Agile, man!

Totally sound logic, with which I cannot argue!

Again, the fact that none of us knew the above leads to the confusion.

Looking forward to the next few weeks…

:sunglasses:

1 Like

I am pleased with the current status of BrewSpark. I can ferment my beer, thats all i need.

But i am happy to hear there will be updates soon! :smile:

2 Likes

Nice run down of feature requests - was what my “Wishlist” thread was meant to be :smile:

Personally, I dont see the value in multiple ferment without multiple chamber. If you’re doing multiple brews in one chamber, wouldn’t one FV be the same temp as the other? Therefore, one temp sensor should suffice?

Multiple chambers is what I’m chomping at the bit for - still have a cheap chinese STC-100 on one chamber, and it’s always a gamble whether its used on a delicious ale for me, or a bland boring lager for the boss!

1 Like

While I’m here - I’ve made decent progress with an Android App. It’s still ugly as sin, but retrieves the data well, and i’m working on notifications at the moment, then configurable alert settings…

Questions for somebody who knows the software roadmap (@elco @mdma ?) I’m using the /data/json files from the current release of the web interface to get the latest data. How long are they likely to be available for? I know you’re looking at InfluxDB in the future, and the update class will be abstracted to some extent, but if they’re going to change any time soon I’ll hold off for a while.

Unless you can propose a better method to retrieve the current data that will remain available in future releases?

Cheers,

Ben

I think there’s value in multi-ferment. If you have multiple beers fermenting in different size fermenters, the max and min beer temperatures end up becoming very important.

But how would you control and manage it if you only have one chamber?

Unless you’re thinking of a “chamber” differently to me…just a fridge / freezer? Or do you have a cooling system independent of the chamber?

Totes - why not copy and paste over to your wishlist thread so we can discuss those features over there?

It’s good to hear what you guys want. We’ll try to do it in wishlist order, but sometimes that’s not always possible since a simple sounding feature can be very hard to implement, and vice versa. For example, porting brewpi firmware to the spark (sans display etc…) - we had the code running ages ago because of good hardware abstractions - heck we even had the code running on a PC! To some people, that would be quite a difficult feature to implement - it was made easy by the firmware design.

In contrast, an easy sounding feature like adding another fermentor or sensor is presently very difficult to implement because of the current system design. The concept of there being one fermentor and beer/fridge/room sensors is hard-wired into all parts of the system. Because of this, and a few other issues we’d like to address, all parts of the system will be rebuilt from scratch. This of course will take time, which is why we want to get the present brewpi system working well for fermenting and mashing so that you guys who bought shields/sparks have software to run for the simple case, while we then spend time build brewpi v2.

This is just my example, but this is why I think there’s value in multi-ferment. I have a chamber that will hold a ~13 gallon fermenter plus two better bottles. I currently have the probe on the larger fermenter, but the smaller ones change temperature more quickly than the larger one.

So, if there were multiple beer sensors, the chamber could start cooling to bring them all to the target temp, but then cut off whenever one of the fermenters got too close to the target minimum temperature. As set up, it’s possible to drop the smaller ones too much while bringing the bigger one down.

1 Like

Is 0.2.8 out now? My girlfriend wants my spark off the dresser and into the brew shed!

It’s done, together with a big update to the script and the update process.
I am just holding off release until morning so I can monitor it.

1 Like

I’d love to know the connection between a software release and you keeping your brewpi spark on the dresser. I can’t imagine how they could possibly be related :stuck_out_tongue:

Well, I’ve been playing with the pi in our room because there is a TV there to hook it up to. I promised it would be out when the update came :wink: