IKAWA online profile editor ( with QR codes ) - Page 2
-
- Supporter ♡
Thanks for the feedback! I'll get to it
You are right even the delete button doesn't ask for confirmation
I think if people use it a login and save on the cloud will be useful, was thinking either GitHub and/or Google account.

You are right even the delete button doesn't ask for confirmation

I think if people use it a login and save on the cloud will be useful, was thinking either GitHub and/or Google account.
-
- Supporter ♡
Thanks for the feedback!
Done, I've added a checkbox that if clicked copies temperatures to comparison. If unchecked let's you modify TFC and TBRN for the comparison.GDM528 wrote: FC temperature is technically the inlet temperature at which FC is observed. Making all temperatures inlet-referred can enable user input first-order correction for environmental conditions and source material. As such, I have at times compared roasts with greens that had different FC thresholds, so you may want to consider the same for your comparison table.
Done. Also added it to delete profile.fjen wrote:to the "Populate Profile" button. I didn't know it would clear my temp set points if I had any data in therealert("Populating profile will clear set points");
Done. Let me know if that change addresses what you meant.fjen wrote: Round the values in the chart, right now it seems to go to like 20 sigfigs which isn't super useful and can be a little cluttered
Done.fjen wrote: Ability to remove a profile from the compare tab - right now, I can't seem to find a way to get the graph to not compare after I load in something to compare it to.
This would be interesting, maybe Geary has some more insight. But maybe if we first split and give a target AUC for each phase it could be done...fjen wrote: I wonder if it would be possible to go "backwards" from the statistics to the temperature set points. In other words, instead of specifying the temperature points, specify how long you want each phase to be, FC time, Dry time, etc... and have it work backwards the temperatures.
This is definitely something that if the tool get used will be implemented. I left everything ready for that to be "easy". This would enable sharing profiles (private/public profiles) and further collaboration. I was thinking that we could link it to green coffees, so that if someone else has used that coffee you can know FC temperature for example, or get a profile idea. And other simple stuff like green inventory tracking an so on.fjen wrote: This would be potentially an entire architecture change, but provide the option to have "user accounts" (tied to GitHub perhaps) where users can save down their profiles in case of a browser data wipe (such as "clear cache"). One of the cool ways I found a site called http://www.keyboard-layout-editor.com/ did it is using GitHub as the Auth provider and saving the raw data to a "Github Snippet" which can act as a very generous text store. That way, there is no true backend to be maintained.
.
Amazing work! I wonder if showing one more digit on RoR (and one less on temp) would be more ideal?
Not sure if Ikawa can take fractional temps so seems a little less useful have to a .0 at the end of each one - and some more advanced roasters may find the additional granularity of the RoR going to 2 decimal places helpful. I'm certainly not at the level where that becomes useful, but others might be. :shrug:
Is the project open source - perhaps some of us may be able to help with some of the changes as well.
Not sure if Ikawa can take fractional temps so seems a little less useful have to a .0 at the end of each one - and some more advanced roasters may find the additional granularity of the RoR going to 2 decimal places helpful. I'm certainly not at the level where that becomes useful, but others might be. :shrug:
Is the project open source - perhaps some of us may be able to help with some of the changes as well.
I briefly looked into curve-fitting the setpoints to roast metrics like dry/brown/dev time. It can be prone to the 'careful what you ask for' syndrome, where the setpoints can go to some crazy places in order to hit what end up being unrealistic goals. Instead of fussing over the setpoints, I would've spent an equal amount of time fussing over the goals instead.Esteve wrote: This would be interesting, maybe Geary has some more insight. But maybe if we first split and give a target AUC for each phase it could be done...
Another issue is the definition of those metrics. Exactly what is 'dry'? - might get more than one answer to that question. We could declare a Defacto standard, but then some yahoo shows up with humidity sensor data that may not agree with the fixed temperature thresholds...
Using an algorithm to calculate the intermediate setpoints guarantees a sensible curve, and only requires thinking about four numbers: start temperature, end temperature, roast time, and curvature. I've found that approach makes it really easy to dial in the timing of each phase, sometimes only requiring only one of those numbers to be tweaked.
The layout of the profile calculator spreadsheet (posted elsewhere) was designed to put the roast metrics on the same screen as the temperature setpoints, thereby giving instant visual feedback on the effects of changing the setpoints. That makes dialing in the numbers really easy.
If perchance you mean the curvature parameter used to generate the RoR points, I concur! Allowing two significant digits for the curvature enables greater control, such that it can be the only number tweaked to adjust first-crack timing down to the seconds (for example).fjen wrote:Amazing work! I wonder if showing one more digit on RoR (and one less on temp) would be more ideal?
-
- Supporter ♡
What do you mean ? The formula for the RoR line? It's a derivative of the inlet curve. I understood fjen's comment as just adding a decimal point on the RoR display.GDM528 wrote:If perchance you mean the curvature parameter used to generate the RoR points, I concur! Allowing two significant digits for the curvature enables greater control, such that it can be the only number tweaked to adjust first-crack timing down to the seconds (for example).
Regarding IKAWA temperatures. The number sent to the roaster is a 4 digit integer 1005 represents 100.5ºC, so 1 decimal point should suffice per IKAWA's resolution.
It is HTML and Javascript on the front end (you can explore the source using chrome developer tools). The backend is just python functions that convert from points to IKAWA protobuf and viceversa. I open sourced it a while back: https://github.com/esteveespuna/IkawaRoasterEmulatorfjen wrote:Is the project open source - perhaps some of us may be able to help with some of the changes as well.
I am not sure how to opensource the whole website, the code isn't super clean and also it is deployed on Google's Firebase which means that you'd need a similar setup or access to my hosting account. If anyone has experience we could look into how to opensource it.
So you got my request correct haha I was talking about the graph showing 2 decimal places for RoR. I believe he means on Advanced Profiling - GDM, the option to put in X.XX for Curvature.Esteve wrote:What do you mean ? The formula for the RoR line? It's a derivative of the inlet curve. I understood fjen's comment as just adding a decimal point on the RoR display.
Regarding IKAWA temperatures. The number sent to the roaster is a 4 digit integer 1005 represents 100.5ºC, so 1 decimal point should suffice per IKAWA's resolution.
It is HTML and Javascript on the front end (you can explore the source using chrome developer tools). The backend is just python functions that convert from points to IKAWA protobuf and viceversa. I open sourced it a while back: https://github.com/esteveespuna/IkawaRoasterEmulator
I am not sure how to opensource the whole website, the code isn't super clean and also it is deployed on Google's Firebase which means that you'd need a similar setup or access to my hosting account. If anyone has experience we could look into how to opensource it.
-
- Supporter ♡
Ah, makes sense. I changed it. I was converting it to an int not a float.fjen wrote:So you got my request correct haha I was talking about the graph showing 2 decimal places for RoR. I believe he means on Advanced Profiling - GDM, the option to put in X.XX for Curvature.

You can now register and have all your profiles stored across devices. I have not fully tested it but should work well enough. You can also use the site without registering with the previous limitations. I think it is nice to make the profiles ahead of time on the computer and then just load it to the roaster when needed, removes the need for the QR basically.fjen wrote: but provide the option to have "user accounts" (tied to GitHub perhaps) where users can save down their profiles in case of a browser data wipe (such as "clear cache")
This is probably a stupid question but is it possible to load a Pro profile and automatically adapt it to a Home profile? TIA.
I don't think any real way of doing that will be reliable. Too many factors can affect bean temp that the Pro measures. The Pro sets the inlet temp (i.e., the heating element) automatically based on what it measures as the bean temperature. Therefore, the inlet temp will necessarily change from charge weight, bean characteristics, room temperature, etc...
There've been some posts comparing inlet and bean temp on a home unit, and the delta between the two seems to have been anywhere from 30-40 C throughout the roast. So, as a best approximation, I take a Pro profile, and subtract 35 from each number to start out. Though, it'll necessarily just be a rough approximation and a starting point to further tweak.
IKAWA Home - profiles
There've been some posts comparing inlet and bean temp on a home unit, and the delta between the two seems to have been anywhere from 30-40 C throughout the roast. So, as a best approximation, I take a Pro profile, and subtract 35 from each number to start out. Though, it'll necessarily just be a rough approximation and a starting point to further tweak.
IKAWA Home - profiles