Esteve wrote: the sensor board:

Is the sensor board just wiring? Some (but not all) I2C hookups require a pullup resistor, but that could be tacked onto the processor board so that it's just fly-wires to the sensor.

Any issues with alternate ESP32 boards? For example, there's a version with an integrated display that could be handy https://www.adafruit.com/product/5483 This board also supports CircuitPython and STEMMA QT, making it more accessible to a wider range of hobbyists. It's plug-in compatible (no soldering!) with a different HT sensor board https://www.adafruit.com/product/2857 which has a higher operating range (80C). A further benefit to the STEMMA QT interface is chainable, plug-in access to an ecosystem of yet other potentially interesting sensors, like CO2, VOCs, so you could turn this into an exhaust-gas analytical lab

The still-active thread "DIY Color Meter" may be a good architectural model to consider. It's approaching 700 posts and 9000 views, which may be related to the accessibility of the design. The photos in this particular post neatly summarize the component selection strategy: DIY Color Meter. That's what I'm contemplating as I think about how to shadow your results. Happy to hear you're using the Arduino libraries, and I bet the code architecture would port easily to Python, CircuitPython, etc.

Question for people with drum roasters:

Are there locations on your roaster where can access the roasting fumes separately from the heat source? The few pictures I've seen show what looks like a combined exhaust from the (electric or gas) heating system spillover and roasting fumes. Unfortunately, a combined exhaust would both dilute and potentially overwhelm the roasting fumes.

Are any of these approaches practical?
1) Replace or modify the tryer to draw an air sample right out of the circulating beans.
2) Hold an access door (load or dump) slightly ajar to slip in a 1/8 inch tube.
2) Drill a hole in your cherished roaster and insert a pipe fitting, somewhere in the range of 1/4 to 1/8 inch.

I'm presuming the air pressure in some drum roasting chambers may be net negative, with a fan downstream to pull out the fumes. So, this has me thinking the analyzer needs to actively pull the air sample. That may seem harder than it has to be (and unnecessary for the IKAWA), but this would also regulate and control the airflow through the cooling system to keep the sensor(s) from overheating. I'm estimating this would only add about $10 to the build cost.

If the interface is Bluetooth, doesn't that generally require a phone app? If I'm roasting, I'll likely be using the IKAWA app, so toggling between two apps would be a hassle. This is one of the key reasons I'm inclined to incorporate a display into the sensor. However, I may be displaying my bias because I don't create phone apps - maybe it's not that big of a deal?

Virtually all of the controller boards that have Bluetooth also have Wi-Fi, which opens up other ways to access the sensor data. For example, I use my desktop PC to SFTP .csv files off my temp logger via Wi-Fi, and eventually I'll have the logger just email the data. Getting logged into one's local network could be a barrier for some, so ideally the controller board would support WPS (I think the ESP32 boards might).

I concur that getting something working with the IKAWA first is a good place to start, given the Pro 100x is one of the few (only?) systems to benchmark against.

Initially, just producing .csv files should fine. It's not obvious to me if Artisan even has a mechanism for moisture data - but it might if this sensor works well and produces useful data.

Moisture (humidity) concurrent with chamber/exhaust temperature would be a powerful combination. I see the value in the ambient humidity sensor, but I expect it's readings would be largely flat during a roasting run, so there may be other ways to obtain the reading it would produce. Other gas and or particulate sensors would be highly experimental, brave new science that could be added later as long as the overall system architecture supports it.

As for system architecture, I like the approach taken with the DIY Color Meter: Use a controller board with a QWIIC connector to support chained I2C sensor boards. All available through hobbyist retailers like Adafruit and Sparkfun, who provide code support. I've only briefly dabbled with Ardunio before migrating to Python, so my personal preference is towards processors that support at least CircuitPython. It might be instructive if initially people are using different boards - that may uncover which one (or ones) are best.

I'm thinking about how to build the air cooling system and enclosure using commonly available parts and some 3D printing. For other projects here on H-B I've posted CAD files on GrabCAD and got no complaints about accessing the data. Is GitHub suitable for mechanical design data?