RoastAid did not start as something I intended to use while roasting.
In fact, it really started somewhere else entirely.
Before RoastAid there was RoastSignal: a fairly simple question wrapped around a growing pile of roast recordings.
Could I take audio recorded from the Gene Café CBR-301, compare it with the roast data afterwards, and find useful candidate first-crack activity that I might have missed while standing beside the machine?
That work was deliberately retrospective.
The roast happened first.
Then the audio, Gene Café data and my own observations were brought together afterwards and examined.
Across the first substantial RoastSignal run, 31 paired audio-and-roast captures were processed. Twenty-eight contained useful enough material to analyse, and 27 made it through to the final comparison set.
The interesting result wasn’t that software suddenly became brilliant at announcing first crack.
It didn’t.
The useful result was that the recordings contained enough structured information to make the experiment worth continuing.
Sometimes the audio suggested candidate activity earlier than I had marked it.
Sometimes later.
Sometimes it broadly agreed with me.
And sometimes the coffee was simply too quiet or the machine too noisy for any confident conclusion.
That is really where RoastAid came from.
I started wondering whether some of that information could be available during the roast rather than only afterwards.
Not to control the Gene Café.
Not to automate roasting.
Just to give me a little more context while I was making decisions.
From analysis tool to capture system
The first version of RoastAid was therefore much less clever than the name might suggest.
It was essentially a Raspberry Pi 5 sitting beside the roaster and recording what happened.
That sounds modest, but getting a trustworthy record of a live roast involves rather more than pointing a microphone at the machine.
For each roast I wanted RoastAid to know:
- what coffee I was roasting
- how much green coffee went in
- what plan I intended to follow
- what the Gene Café reported during the roast
- what the machine sounded like
- what the electrical load was doing
- when I manually noticed something important
- when I decided to stop
- how much roasted coffee came out
- and whether all of those pieces actually survived the process
That meant RoastAid needed to become part of a wider system rather than another standalone gadget.
The natural place for that system to begin and end was the Green Bean Ledger.
The roast starts in the Ledger
The Green Bean Ledger is where the coffee already lives.
It knows the lot, the stock, previous roasts and the basic information I want to carry forward.
So instead of standing at the roaster and typing the same information into another device, the idea became:
stage the roast in the Ledger first.
A roast job can be prepared with the coffee identity and relevant planned information, then placed into a queue for RoastAid.
When I arrive at the Gene Café, the Raspberry Pi already knows which roast I am about to do.
That sounds like a tiny convenience.
In practice it removes one of the easiest ways to corrupt an experiment: typing something differently in two places.
If the coffee in RoastAid is the same staged job that came from the Ledger, then the capture already has an identity that can follow it all the way back again.
A touchscreen beside the roaster
The Pi now runs a touchscreen interface designed to be used while roasting.
That requirement shaped quite a lot of the project.
A keyboard sitting beside a hot coffee roaster is not particularly appealing, and neither is stopping halfway through a roast to enter metadata.
The interface therefore needs to be very simple.
Select the staged roast.
Start the capture.
Add markers if something worth noting happens.
Finish the roast.
Enter the final roasted weight.
Complete the capture.
Behind that fairly plain interface, several things start recording together.
That is the bit I care about.
RoastAid is not trying to replace my observation.
It is trying to give my observation a timeline.
Listening with the UMIK-1
Audio comes from a miniDSP UMIK-1 measurement microphone.
The current capture is mono at 48 kHz.
The microphone has gradually become much more important than I expected.
Initially it existed because I wanted better evidence around first crack.
Now it is also helping build a picture of what the Gene Café itself sounds like: its repeating mechanical rhythm, changes in acoustic character during the roast and the difference between normal machine activity and less easily explained transient sounds.
That changes the role of the microphone.
It is no longer merely a first-crack detector waiting to happen.
It is another sensor.
And like every other RoastAid sensor, its job is to contribute evidence rather than declare an answer.
Reading the Gene Café — but not controlling it
At the same time, RoastAid receives information from the Gene Café over Bluetooth.
This connection is intentionally read-only.
That point is worth making very clearly.
RoastAid does not control the Gene Café CBR-301.
It does not change the target temperature.
It does not alter the fan.
It does not change drum agitation.
It does not start cooling.
It does not decide when the roast is finished.
The Gene Café remains under my control using its own controls.
RoastAid listens to the information the machine exposes and records it alongside everything else.
That separation is deliberate.
I don’t currently want an experimental Raspberry Pi application sending commands into a 1.5 kW heating appliance while I am still learning what the underlying data means.
More importantly, automation is not really the problem I am trying to solve.
My problem is uncertainty.
RoastPower adds another view
Electrical power adds another useful layer.
RoastPower watches the Gene Café’s electrical consumption.
That lets me see when the heater is drawing full power and when it is cycling out.
This has already been useful because some behaviour that appears mysterious if I look only at temperature or audio becomes less mysterious when power state is added.
If the sound changes and the heater has just switched state, that matters.
If something unusual appears in the audio but the roaster’s temperature, BLE state and electrical behaviour all look normal, that matters too.
No single channel gets to decide what happened.
Audio does not get to declare first crack.
Power does not get to declare an overheat event.
BLE does not tell me what the beans taste like.
The value comes from putting the observations beside each other.
And I still press buttons
RoastAid also has a wonderfully low-tech sensor.
Me.
During the roast I can add manual markers.
If I hear something crack-like, notice a strong change in aroma, see an interesting colour transition or simply think, “something happened there,” I can record that moment.
That marker isn’t treated as truth either.
It is an operator observation.
That becomes especially useful later.
I can compare what I thought I heard at the time against the microphone recording, the temperature trace, the electrical state and anything else happening nearby.
Sometimes I will probably have been right.
Sometimes the machine will have fooled me.
That is fine.
A system designed to help me learn needs to preserve those mistakes rather than quietly correct them afterwards.
The final weight matters
Once the roast is finished, there is one final measurement I definitely want: roasted weight.
Green input weight and roasted output weight give the weight loss percentage.
For the Gene Café, that has become one of my most useful simple comparison measures.
First crack can be quiet.
Colour inside the glass chamber can be deceptive.
Two roasts with similar total roast times can still finish differently.
Weight loss doesn’t solve any of those problems by itself, but it gives me another objective result to put beside them.
So RoastAid asks for the output weight before the roast is completed.
At least, that was the plan.
This is also where one of our more educational bugs appeared.
The button that wouldn’t let me finish
Before trusting the system with coffee, I ran a non-roasting rehearsal.
The Gene Café was powered, RoastAid was connected, audio was being recorded and the whole workflow was exercised without actually roasting anything.
Everything worked nicely until I attempted to finish.
The software demanded an output weight.
Which makes perfect sense during a real roast.
It makes considerably less sense when there were never any beans in the machine.
And because the Pi was being used only through the touchscreen, there was no convenient keyboard escape route.
So the test capture could not be completed without inventing a fake weight.
That was exactly the sort of thing the rehearsal was intended to find.
The interface was patched with a COMPLETE TEST — NO WEIGHT option.
The next rehearsal completed properly, with the output weight and weight-loss fields left genuinely empty rather than populated with made-up data.
That may be one of the least glamorous software achievements in the whole project.
It is also one of my favourites.
The correct answer to missing data is sometimes simply missing data.
Capture Check
Finishing the screen is not enough.
RoastAid also performs what I have been calling Capture Check.
The intention is straightforward:
Before I trust a roast capture, confirm that the things I expected to collect were actually collected.
Was the user interface session recorded?
Did the UMIK-1 audio file exist?
Was the Gene Café BLE feed present?
Did RoastPower produce data?
Were the session and capture identifiers present?
Did the canonical roast record get written?
The non-roasting rehearsal passed those checks.
That was an important moment because it meant the overall architecture had worked from one end to the other without needing coffee to prove it.
It also exposed a few less dramatic problems.
Some interface and component labels still reported an older software version after a patch.
One queue state appeared to contain a stale pending entry.
The audio subsystem returned a status code that looked like a failure even though the WAV file, raw recording and audio validation were all good.
None of those things ruined the captured data.
But they are precisely the sort of inconsistencies I want to remove before I start trusting a live guidance system.
A green tick should mean something.
Then we actually roasted coffee
The next gate was obvious.
Use it during a real roast.
That worked — mostly.
A live session produced the files I wanted: the raw and WAV audio, BLE logs, manual metadata, RoastPower data, event records, a capture manifest and the canonical RoastAid JSON.
The audio alone was around 110 MB.
So, yes, the little Raspberry Pi had definitely been paying attention.
The more important result was that all of those different streams belonged to the same roast session.
That is what makes the data useful later.
But the real roast also reminded me that software behaves differently once there is hot coffee and a human being trying to do several things at once.
The final-weight dialogue became troublesome again.
I entered the weight and pressed Save roast.
The interface asked again.
I pressed it again.
It still wanted attention.
The underlying canonical JSON had been written, so the roast itself had not disappeared, but the user experience clearly wasn’t finished.
That matters.
During a roast I don’t want to troubleshoot software.
And I definitely don’t want a Raspberry Pi demanding administrative attention while I am trying to discharge hot beans from a Gene Café.
The whole interface has to become quieter than that.
Closing the loop back into the Ledger
The final intention is that the captured roast returns to the Green Bean Ledger.
The Ledger stages the planned job.
RoastAid captures what actually happened.
Then the completed capture can be collected and imported back into the Ledger.
That closes the loop:
plan → roast → capture → verify → import → compare → learn
The import tooling now exists and the canonical RoastAid capture has been deliberately structured around that handoff.
I am still treating the end-to-end workflow carefully rather than pretending it is a finished appliance.
The important part is that RoastAid does not become a second independent database containing its own version of the truth.
The Green Bean Ledger remains the long-term record.
RoastAid is the temporary observer beside the roaster.
So what is the actual destination?
It would be very easy from here to chase automation.
Once you have a Raspberry Pi, live temperature, audio, power monitoring and a touchscreen, the obvious temptation is to make it do things.
Change the fan.
Reduce the temperature.
Start cooling.
Run a profile automatically.
That is not where I want to go.
At least not with RoastAid as I currently understand it.
The interesting problem is not making the Gene Café obey a computer.
The interesting problem is helping a person understand what is happening while there is still time to make a decision.
Imagine RoastAid eventually saying something like:
Machine behaviour looks normal.
Then later:
Candidate coffee-like activity increasing.
Or:
This roast is running later than comparable roasts of this coffee.
Or perhaps:
You are approaching the finish region used successfully last time.
None of those statements has to control anything.
They simply reduce the amount I need to remember while standing beside a noisy, hot machine.
The decision remains mine.
Calm decision support
That phrase has become increasingly important to me:
calm decision support.
I don’t want RoastAid flashing alarms because an algorithm thinks it heard one pop.
I don’t want a countdown timer pretending that every coffee develops identically.
And I don’t want it chasing a theoretical profile while ignoring what is actually happening inside this particular Gene Café.
I want it to know enough about the planned roast, the machine and the previous evidence to quietly add context.
If the evidence is weak, it should say less.
If something is only a candidate, it should call it a candidate.
If several independent observations begin to agree, then it can become more useful.
That is quite a different ambition from automation.
And oddly enough, I think it is the more difficult one.
Automation requires the machine to follow instructions.
Decision support requires the software to understand when it doesn’t know enough to give one.
A recorder that is slowly becoming a companion
RoastAid is still rough around the edges.
Buttons have misbehaved.
Version labels have lied.
Queues have needed checking.
Audio capture has produced contradictory status messages.
Weight entry has managed to be surprisingly exciting.
And none of that bothers me particularly.
Those failures are happening while the system is still allowed to fail safely.
The Gene Café continues roasting independently.
I continue making the decisions.
And the data continues teaching me what the next version needs to do better.
RoastSignal began with completed roasts and asked:
What might I have missed?
RoastAid is gradually moving that question closer to the machine:
What is happening now, and is there anything here that might help me decide what to do next?
That is the direction.
Not an automatic Gene Café.
Not an AI roastmaster.
Just a better-informed person standing beside the same roaster.
And, if I can make the technology quiet enough, perhaps a rather useful companion.