filling event is not correctly recognized anymore since version v2.10.0

[peterweiser]

Describe the bug
Sometimes the filling-event isn´t recognized at all, sometimes it´s recognized too late, sometimes correctly.
The behaviour is somehow on a non regular basis since Artisan version 2.10.0.
This also applies to the drop-event, but there´s already an existing issue for that.
With older versions of Artisan, these events were recognized always accurate with my setup.

Setup (please complete the following information):

• Artisan Version [e.g. v2.10.1]:
• Artisan Build (number in brackets shown in the about box) [46ed365]:
• Platform (Mac/Windows/Linux + OS version) [Windows 10 Pro 22H2]:
• Connected devices or roasting machine [Dätgen DR12 with Modbus RTU and Phidgets]:

Please attach your current Artisan settings file (as exported via menu Help >> Save Settings as *.aset) file.
Please attach any relevant Artisan *.alog profiles.

artisan-einstellungen_12_2023.aset.txt
2023-12-21_0952_Thu_20231119 (2)_Brasil Fazenda Lagoa_Brasil Fazenda Lagoa_9.5Kg_18_19m_AUC1174_Bag-A60.alog.txt

Note that you need either add a .txt extension or zip the files before uploading. Otherwise you will receive a "Not a supported file type" error on uploading.

[MAKOMO]

Which existing open issue refers to the DROP event? There was one issue closed for v2.10 (Issue #1232).

Did you adjust the DROP or CHARGE events on the attached profile?
Could you please attach 2-3 more profiles where recognition of either CHARGE or DROP failed?

Thanks for your report! We are looking into this over the next days.

[MAKOMO]

Ah, you are maybe referring to Discussion #1350. Initial problem could be related, but turned into a discussion on alarms.

[MAKOMO]

Note that according to the attached settings you have the "CHARGE timer (10s)" activated which explains the CHARGE event mark exactly 10 seconds into the recording. After deactivating that CHARGE timer, the CHARGE is recognized correctly in our simulations.

Your DROP is hard to detect automatically as the BT temperature drop around your DROP is very gentle, a pattern which could as well be leading to a false positive caused by a bit of signal noise. Still we are looking into this and see if we can do anything about that one.

[MAKOMO]

I found the CHARGE timer broken in v2.10. Just fixed this one. A new build should be online within an hour.

[peterweiser]

Hi Marko,
now I ve time again to answer :-) thanks so far for your work - in earlier versions (I dont know the exact version anymore) the behaviour of the charge recognition was different. It worked almost always accurate with my setup. I activated the charge timer only additionally, so that if it doesn´t recognice the charge event, it automatically sets the charge time 10s later. That worked perfectly before. Now the charge event is recogniced accurate again.

[peterweiser]

about the DROP event:
the recognition is not as accurate as in earlier versions anymore.
Before (in earlier versions), it worked perfectly nearly every time
here are some profiles where DROP recognition failed:
(unfortunately, I dont have many of such profiles anymore because I always use the DROP button manually)

2024-01-10_1727_Wed_20231164 (2)_Indien Robusta Parchment PB__9.5Kg_25_24m_AUC2017_Bag-A56.alog.txt

2024-01-16_1729_Tue_20241184 (3)_Papua Neuguinea Sigri_Papua Neuguinea Sigri_9.5Kg_20_37m_AUC1414_Bag-A41.alog.txt

[roasterdave]

Thank you for these additional profiles.

The automatic marking of CHARGE and DROP is enhanced in the continuous build. Please download the current build since this change is more recent than the version used to record these profiles.

The sensitivity of CHARGE and DROP detection can now be set in the Config>> Events dialog. The detection mechanism also adjusts internally for sample rates less than 1 sec. For your setup I recommend using CHARGE set to Standard and DROP set to Sensitive.

When sampling at 0.5 sec it can be challenging to find these events, especially DROP. The change in temperature from one sample to the next at DROP time in your profiles is quite small, less than 0.1 degree. False early detection could occur in some setups due to noise in the BT signal when sampling at 0.5 sec or faster and with DROP set to Sensitive, The noise level in your setup appears to be low so this should not be a problem for you.

The screenshot below shows where Artisan would now mark DROP for this profile. The other profiles posted above would be marked similarly. CHARGE would be marked at the same point in time as in the supplied profiles.

Please try the continuous build and let us know how it performs for you.

Note that profiles with events marked manually are still useful to us. We can analyze where Artisan will mark a profile even when the events are marked manually.

[peterweiser]

Just want to report that - after about 200 roastings, I can say that the fill and drop features work perfectly since it´s possible to adjust the sensibility, even with a sample rate of 0.5s.
Thank you Marko for adding this feature.

[MAKOMO]

Thanks Peter for testing! It was actual Dave who implemented this functionality. I just added the UI for it.

However, today I worked a little more on the Linux builds. It turned out that the release build of Artisan v2.10.2 works for me on my Ubuntu VM despite this issue of the underlying Python 3.12.0. Not sure why this is an issue for you. Maybe you were running a previous beta build for testing? Anyhow, I did turn back the Linux build to Python 3.11 again, removed included Wayland shared libs which could lead to incompatibilities with the corresponding system provided libs of the OS, found that the startup script was not pointing to the correct location of the Qt plugins directory and fixed that. There test builds are here and should run under Wayland for you without any crashes.

https://github.com/artisan-roaster-scope/artisan/releases/tag/continuous

Those Linux builds runs well on my VM besides that under Wayland Artisan does not remember window position (for a lack of Wayland support to set positions of new windows) and that the UI somehow does not look as good as under X11.

If this also runs fine for you we could go for a v2.10.4 release with those changes. Let' us know.