Hi

My apologies for the late reply. I have been been out of the office for the last two weeks.

The thread you mentioned talked about using a Raspberry Pi with the new Roastmaster Datagram Protocol (RDP), and DIY hardware (Thermocouple board). That setup does not use the Phidgets hardware. It sounds, though, like you are trying to use a Raspberry Pi with a Phidgets Temperature Sensor, and the Phidgets software API in place of using a Phidgets SBC. Both of these avenues are possible, but they’re very different in terms of hardware and probe type within Roastmaster.

I have never tried using a Raspberry Pi with Phidgets before. Theoretically, it should work just fine. From what I understand, 2 things would need to happen:
1) The Raspberry Pi needs to be joined to the same WiFi network as your iPad/iPhone
2) The Phidget Web Service needs to be running on the Raspberry Pi.

From what you’ve said, it sounds like you’ve done both of those things. I would expect that to work.

On your laptop, you’d just need to
1) Create a new “Phidgets” Probe in Roastmaster
2) Enter the Phidget Temperature Sensor Serial number in Roastmaster. You can see this by opening the Preference Pane (Mac), or Control Panel (Windows) on your laptop. Enter that serial number into the Probe details screen in Roastmaster.
3) Enter the Port of the probe (0 - 4)

If you don’t receive a connection, it’s possible that a copy of the Web Service is still running on your laptop, and conflicting with the copy on the Raspberry Pi. Try stopping the Web Service on your laptop.

Danny

Hi cinderblock

Was a little preoccupied getting the latest version of Roastmaster released yesterday - getting back into the routine today.

Glad you were able to get things up and running. Using an SBC for a host is more forgiving with regard to a Firewall. Windows tends to be pretty aggressive with its filtering–certain routers as well (Comcast in the US).

For future googles...The Setting Up Phidgets page has links for purchasing hardware. Just search "Phidgets" on the home page in case that permalink changes.

Regarding the version chart on that page...Phidgets USED to be very finicky about the software API version - the build running on your probe host had to be identical to the build running in Roastmaster. That is no longer the case in practice. Technically, they say it still should, but I haven’t seen that problem occur in a few years. 9 times out of 10, the problem is Windows firewall.

A couple of weeks ago I aggregated of list of the tech support requests I’ve received for Phidgets, and prioritized them by the number of incidents. I'll try to post that list soon on the site as a "Troubleshooting" page. Phidgets can be a bit daunting to get up and running - and that type of documentation is currently lacking.

Any other questions, let me know.

For the coming update, I locked myself pretty tightly to a feature list back in the summer. Now that I've finally finished development on this rather large update, I can look toward the future.

I have contacted the maker of these products to see if they provide an API. I'll post back here what I find out.

Finally making my way back to this rather late. But, back in the fall, I was pretty much locked into this development cycle, and the punch list was already set. Now that development on the coming update is complete, I'm stretching my brain out for the next future update.

I've toyed with ideas of a graphical curve editor. Something that would allow you to shape an entire curve at once. Roastmaster already has the ability to expand or condense an entire curve linearly, but nothing with a more advanced transform matrix like this.

If you find you ever want to discuss this further, send me an email and we can set up a call. I'd love to hear your particular use case with four roasters, and what you experience as differences among them.

Hi

Thanks for the kind words - glad you are enjoying it!!!

I tried to design Roastmaster to be flexible. For home roasters, there’s a chance that your machine may not be capable of bean mass readings. If you’re a specialty roaster, you may have one or more production roasters that are, but also one or mare sample roasters that are not, which you use to tweak you profiles.

For this reason, there are different ways that Profiles can function. But, at their essence  (and the way most folks use them), Profiles are designed to house two types of curves: A) Reference Curves - those are the ones usually created in a roast, and propagated to a custom Profile by either tapping “Create Profile from Roast”, or copying and pasting them manually. These Reference Curves will populate (as you mentioned) in roasts that use that profile. The other type is B) Curve Templates. Those are blank curves stored in a profile, pre-configured with curve type, color, probe info, etc., that will create a blank, new curve in a roast for the means of recording NEW data.

The roast console will show both of these without distinction. The reason is that many shops will hone a profile via Control Curves, and not bother with live temperature readings–just roasting by sight and smell. For them, their profiles just house one control curve, and they view that as the de facto (albeit “inherited”) roast curve.

For others that log data (like you and me), the full-screen Analyzer provides a means to differintiate between “Reference Curves” and live “Data Curves” via the “Targeting Mode”. Setting the targeting mode to “Profile/Program” will show the “Reference curves” in your profile as dotted, and show the live Data Curves in your roast (created either via Curve Templates from your profile, or manually) as solid lines. So, the dotted reference curves provide the “base” you want to match, while the actual roast data is overlayed as solid line curves.

Most folks just use the main console to set up the roast, then open the full-screen analyzer to perform it, where all of the advanced curve functions reside. You can change the targeting mode to “Past Roast” during a roast, and swipe along the bottom axis to pan through recent roasts (the ones being displayed in the roast console when launching the analyzer), but most folks spend the majority of their time in “Profile/Program” targeting mode.

Hope this helps. Any other questions, just let me know.

Kind regards
Danny

Hi Stan

I've been working steadily on the next version of RM steadily for the last 6 months, hoping to get it out in tandem with the release of iOS 10, but development ran long. It’s basically a complete overhaul–same concepts, but a lot different in the interface. I'm going to redo the screencasts then, with a different approach - kind of a “tidbits” thing so each one isn’t such a daunting task, and I can afford to be more faithful with them.

1) Yes, Delta Curves is the verbiage RM uses for RoR curves. With that turned on, you will see them in the full-screen Roast Analyzer.

2) In an effort to keep the workflow as simple as possible for those not needing advanced functions (and a lack of screen real estate in iOS), I’ve designed many concepts as “opt in”. Some of the roast metrics fit that category. The turning point is defined by an Event. Events can be created in any curve as simple text-based markers, or static types, like Turning Point, Drying End, etc.

Events can be entered “on the fly” in the analyzer by selecting the target curve, then tapping the curve icon in the upper left corner. Once saved, the event will be pinned to that time in the current roast.

You can also define events in a curve before the roast begins, and set them to “Auto Trigger” at a specific temperature. Events play a role in some of the metrics available in reporting, so it’s good to use them.

Now, it would be cumbersome to define all of this in each roast, so Profiles have the ability to define “Curve Templates”. You can set up a profile with reference reading curves by copying and pasting from a roast into the profile, then creating corresponding curve templates, with auto-trigger events for for the things you’re interested in at the appropriate temperatures, as well as the probe binding, color and other details.

Then, when you tag that profile in a roast, the curve templates will spawn identical curves as “Data Curves” in the roast, with the probe already bound, and events ready to go. Using profiles makes it quite literally a one (or two) tap affair.

3) Auto-trigger events will help you here too. You could define control curves, but they are formed by time, not temperature. The way I roast is by having certain triggers set on my “Bean Temp” curve, like “Open Damper full” at 185° C, etc. Make sure to set the “Alert Type” so that it either dings or alarms at the appropriate temp. You’ll get a banner alert, along with a sound if specified, in the analyzer when they are triggered.

4) The best thing here, if you’re trying to capture all the data you can, is by defining “Control” curve templates in your profile. Then you can enter the actual data in the control curve as you change it on the roaster. That would give you a static record of what control changes you made and when. I used to always record my control changes in control curves. I’ve since just come to rely on auto-trigger events and intuition. But, you can use both in tandem.

Hope this helps. If you have any other questions, let me know.

Danny

Hmmm...interesting. I like that idea, and am definitely starting down a similar route in the coming update. The HUD is one of those steps, another is key commands that will be available via a Bluetooth keyboard in the analyzer. Those are pretty slick - there are navigation and zoom commands, along with curve selection, and many others. The thinking is to give folks the ability to monitor a roast from a distance greater than arms-length. Maybe it’s a small shop, where the roastmaster is bagging orders on a nearby table while a roast is going, or maybe a larger shop where the iPad sits on a mount above the roaster. Either way, it allows the Analyzer to be useful from greater distances or with less interaction, which ties right in to your point.

I’ll think on that - thanks for the input!

Hi Cees

Well, my first step to help folks in your situation is XML. That, actually, is complete in the development version that I'm currently beta-testing, and should be available soon. Also, there are some extra roast metrics included in the Tab-Delimited export. Roasts now have the concept of curve “Sorting” for its “native” curves, so RM will use the first curve to show lots of temperature metrics in Tab Delimited and XML export (Charge temp, crack temps, drying, pyrolysis and drop temps). Now, that stuff is great, but it involves either a software “back-end” to catalog this, or a lot of manual analysis to make sense of anything. Some folks have that - they will be elated. Others, are looking for a more Roastmaster-oriented solution.

So, taking this concept further, I want to introduce the concept of “Users” to Roastmaster, whereby every device could define separate users, having also the concept of the “current user”, allowing a user to switch users. In this setup, one device could function as the “Administrator”. Other devices could upload roasts at the end of the day to Administrator, where everything would be available on one device for analysis and reporting, along with who performed the roast.

I had wanted to tackle that in this update, but there wasn’t enough time. This update was essentially a complete UI rewrite from the ground up. I’ve modernized all of the code base, and it’s been a massive undertaking. But, it will also (thankfully) eliminate what I spend MOST of my time on - coding individual scenarios for the varying number of iOS devices, and screen sizes. This will let me concentrate on features instead.

I do hope to start working on the user concept soon. If you’d be interested in beta testing this with me, please shoot me an email at support@rainfroginc.com. I’ll definitely need a good team of beta testers to provide feedback and use cases.

Danny