Problems with Artisan 2.10.0 on Ubuntu 23.10 with Hottop KN-8828B-2K+

[spwoolet]

I am running Artisan 2.10.0 on Ubuntu 23.10 with my Hottop KN-8828B-2K+. Everything was working fine for me with Artisan 2.8.4 but after upgrading to 2.10.0 I have encountered some problems.

When I try to print a report to PDF, I get a message:
Exception: htmlReport() No module named 'matplotlib.backends.backend_svg'@line 21147
I have the python3-matplotlib package installed. How do I get htmlReport() to work correctly?

I also have problems with "Control." When I take "Control" of my Hottop, nothing happens until after the "ON" button is pushed, and immediately after DROP everything shuts down and I have no control. With the previous version (2.8.4) when "Control" was pressed, the Door would be Closed and the Motor would turn On. After "ON" was pressed, the alarms would take over. At the end of the roast, after DROP, the fan would go to 10 and the heater to 0 and the stirrer would come on -- and I had control to start/stop motor, fan, stirrer, etc. via the bottom buttons on the screen.

Thanks for any suggestions.
Is there something in the settings that I failed to update when I upgraded to 2.10.0?

[MAKOMO]

I am running Artisan 2.10.0 on Ubuntu 23.10 with my Hottop KN-8828B-2K+. Everything was working fine for me with Artisan 2.8.4 but after upgrading to 2.10.0 I have encountered some problems.

The Hottop communication has been reimplemented completely.

When I try to print a report to PDF, I get a message: Exception: htmlReport() No module named 'matplotlib.backends.backend_svg'@line 21147 I have the python3-matplotlib package installed. How do I get htmlReport() to work correctly?

This is unrelated to Hottop specifics and a regression in this version which has been reported (Issue #1430) and fixed already.

I also have problems with "Control." When I take "Control" of my Hottop, nothing happens until after the "ON" button is pushed,

Sure. ON starts the communication.

and immediately after DROP everything shuts down and I have no control.

Communication shuts down on OFF not DROP

With the previous version (2.8.4) when "Control" was pressed, the Door would be Closed and the Motor would turn On.

This changed.

After "ON" was pressed, the alarms would take over.

Still the case

At the end of the roast, after DROP, the fan would go to 10 and the heater to 0 and the stirrer would come on -- and I had control to start/stop motor, fan, stirrer, etc. via the bottom buttons on the screen.

Still the case

Thanks for any suggestions. Is there something in the settings that I failed to update when I upgraded to 2.10.0?

No

[spwoolet]

With the previous version (2.8.4) I would press OFF to stop the recording but still had control. Is this no longer the case? To keep control of the stirrer, fan, etc., I do not press OFF? So the recording continues as I cool the machine and beans?
Thank you for the response.

[MAKOMO]

yes

[spwoolet]

There is an action to START the recording sometime after the HOTTOP has been ON. But it appears the only action to stop the recording is OFF. Is there any plan to add a STOP action so that the recording can be stopped without turning the HOTTOP off?

[MAKOMO]

No, but as this is an open source project your are welcome to fork your own

[rmongiovi]

Is there some reason that you messed up the workflow this way? Why do I have to keep recording an empty roaster in order to keep the beans cooling in the cooling tray? You broke something that worked just fine.

[poundy]

I think your statement comes off a bit harsh.

The workflow makes little difference that I can see - it's a button press when you've COMPLETELY finished with the roast not just "mostly" finished and wanting to cool. The architecture of the roaster connection makes more sense to close on OFF, and (re-)open on ON. That's the way it's acheived with other roasters, and TBH just makes logical sense to me. The data you collect when the roaster is on but after DROP doesn't really affect anything, unless you can identify an issue I am not aware of?

Workflows are hard. Change is hard. At the end of the day, as pointed out above, this is an open source project that you can choose to fork. But having a more sensible workflow conversation, rather than coming in here and hating on a change, would be of more valuable to the community and help shape the future direction...

[MAKOMO]

There are technical reasons. The major problem is that HOTTOP decided to switch of the machine once it detects the connected software is not responding. On reviewing the first prototypes of the machines for HOTTOP I reported this as a major safety issue as if this happens while the machine is very hot it might be a lot better to release the beans and keep the fans running (maybe at max) to prevent overheating. I was ignored by the developers and managers.

Previous versions of Artisan did use parallel processing realize the communication with the Hottop which includes sending a regular ping to convince the machine that the software is still responsive. That process was kept alive after OFF. However, all parallel processing (essentially starting internally a full second Artisan process) was removed from Artisan to increase overall app stability and replaced by in-process threading. The trigger for this change was the discontinuation of support for such types of "parallel" applications by all major app bundling tools for the major platforms, mostly for stability, security and validation reasons. While Artisan is in OFF state the app is disconnected from everything and there is no longer any communication going on, which makes a cleaner app design. Just keep Artisan running while cooling down or try to convince HOTTOP to change their machines "connect loss" behavior to some more reasonable one.

[rmongiovi]

Harsh? 2.8.4 worked perfectly. The control button turned the hottop on. The control button turned the hottop off. The record button started recording and the off button stopped recording. Very clear button to function mapping. Nothing about it is broken. When I want to start the roaster I press control. When I want to start artisan I press on. When I want to start recording I press Start (actually I do it with an alarm). When the roast is finished and I've dropped the beans I press off. When the beans are cool I press control again. Every button has one function and I can control the roaster in a very logical A, B, C manner. What about that is broken that needed to be fixed? What is the overwhelming reason for breaking the "one button one function" mapping?

I will admit, the issue is minor. Leaving recording on so the beans can cool just leaves useless blank space in the recording. For what, some sort of idea that it makes "logical sense" to open the roaster connection with "on" and close it with off? Well, my "logical sense" says opening and closing the connection with "control" makes sense since, after all, that's what the button actually says it does. If you're going to insist on conflating turning artisan on with turning the roaster on then for the sake of all that is logical get rid of the control button. It's entirely superfluous.

[MAKOMO]

There is one more technical hurdle build into the Hottop firmware. While it is possible to take control by sending (regular) control requests, there is no mechanism foreseen to release control and just keep the communication state of the machine in read-only mode.

Concerning the CONTROL buttons relevance. Artisan is a generic roasting software not specifically designed for the HOTTOP. The CONTROL button plays in many configurations the role to configure the internal or external PID process.

Anyhow, if you are not happy with how things are, get ready and either improve Artisan by sending in your PRs, fork your own version of Artisan or build your own roasting software from scratch. Artisan is voluntarily shared with you and the planet for the better. If it does not serve you. Ignore it or improve it, but don't ask others to improve it for you. They already did what they could. Now it is your turn. Get active!

[rmongiovi]

I certainly won't argue there aren't issues with the Hottop. All I'm saying is that 2.10.4 represents a loss of functionality. That's not normally a goal I have with my own software so I thought I'd throw in my 2 cents. It's just my opinion and worth every penny you paid for it. For instance, there would be no loss of functionality if there was a mirror sequence to "on -> start" like "stop -> off" to keep the "recording" state and the "on/off" state separate. You seem to be able to keep the Hottop online after "on" and before "start" so I don't see why it would be an issue to keep it online after "stop" and before "off".

Unfortunately (or fortunately) I'm not a windows guy and I'm not inclined to create a windows build environment when I can just stick with 2.8.4. Making my own fork of artisan wouldn't be any improvement over that since I'd have to keep merging your changes to get future changes. Why would I do all that work to create my own fork to stick at 2.10.4 when I can just stick at 2.8.4?

[poundy]

I'm sorry, exactly what loss of functionality have you experienced? All I've heard so far is a clear change in workflow. Now you can't turn the logging off until you wish to shut down the roaster. Are you no longer able to do anything you were able to do before?
If the honest answer is yes, there's a loss, great - have a serious conversation about what the workflow SHOULD BE not just what you've gotten used to. As Makomo has mentioned above, there's technical reasons that the hottop was bought into line with other roasters' control methods, which helps build a more robust application for us all.

As you say, you're faced with choices. You could, as you say, keep using 2.8.4, but that then means you don't gain any of the benefit for current or future development. You could, as has been mentioned but you discounted, fork the code and find a way to keep your old workflow and incoroprate new code so you get a hybrid of the old and new. Or, you could just accept there's a new workflow, as you mention above it's a minor issue, get used to it, and let it become the new habit.

And yes, harsh. I still stand by that. You came in and left three sentences. They were blunt, direct, and not complimentary... That just sounds harsh. None of those were "the old workflow made much more sense, why was it necessary to change this, and is there any way we can go back to the old". And that is why I said if you come here with a more tempered approach, discuss the workflow implications, rather than yell at people to bring back the old way, you'd be taken more seriously.

[MAKOMO]

I certainly won't argue there aren't issues with the Hottop. All I'm saying is that 2.10.4 represents a loss of functionality. That's not normally a goal I have with my own software

but in this case unavoidable for the technical reasons I listed above. There is one other reason. Artisan has by now about 30k users with about 50% of those roasting commercially on large drum roasters. Hottop users are not in the focus of this project and we cannot afford to risk unstability just because a few users that are not willing to just keep the recording running during cool down which should not hurt anything or anybody.

so I thought I'd throw in my 2 cents. It's just my opinion and worth every penny you paid for it.

You could as well suggest to Apple they should come up with faster, lighter laptops with more ram and disk space and higher screen resolutions for less money with the obvious advantage of selling more and making users happy. There might be reasons they did not come up with this idea...

For instance, there would be no loss of functionality if there was a mirror sequence to "on -> start" like "stop -> off" to keep the "recording" state and the "on/off" state separate. You seem to be able to keep the Hottop online after "on" and before "start" so I don't see why it would be an issue to keep it online after "stop" and before "off".

The history of this project is long. Initially there was only a recording mode and no logging-only mode. At the time this was added there was still a STOP button to stop recording (fragments are still in some commented code), but it turned out that to keep it let to too many complication due to feature interactions that it was decided to remove it.

Unfortunately (or fortunately) I'm not a windows guy and I'm not inclined to create a windows build environment when I can just stick with 2.8.4.

Me neither. Never used Windows. You can run develop for Artisan on any of the supported platfors.

Making my own fork of artisan wouldn't be any improvement over that since I'd have to keep merging your changes to get future changes. Why would I do all that work to create my own fork to stick at 2.10.4 when I can just stick at 2.8.4?

To submit a PR and have it integrated with the trunk?

[rmongiovi]

See, I don't have a horse in this race. I'm just a guy sitting at home roasting for myself and 2.8.4 does everything I need it to do. At some point I'll decide to fork over the cash to upgrade from the Hottop and this will be a moot point.

@spwoolet complained about a loss of functionality and I seconded it. I replied the way I did because the previous responses were the standard "we like the way we do things and if you don't like it make a copy and do it yourself." That makes it really, really difficult to have a productive conversation with respect to making your product more user friendly. But honestly, it's the knee jerk reaction I always see here so I'm pretty used to it. You have no reason to listen to anyone, but don't expect folks to be excited by that attitude.

In your first response to me you made an appeal to logic to justify the current design. Honestly, I don't see the logic. If it's logical that the off button both stops recording and turns off artisan then why is it not logical that the on button turn on artisan and start recording? If logic is the basis of the design then why does the start button exist? Perhaps because it's useful? Well, a stop button would also be useful but naturally @MAKOMO rejected that suggestion with the standard "make your own fork" response. You do realize that the "make your own fork" response is insulting, right? What kind of reaction do you expect to get from "it's our game and if you don't like it go play somewhere else"?

With 2.8.4 I turn on super and then control. I do this so that at the moment I turn artisan on it's already in communication with the Hottop. I have an alarm set immediately after "on" to turn the Hottop heat to 100 to start warming up the roaster. Then at 200F after on I start recording so that I'm all ready to charge at 300F. I uninstalled 2.10.4 immediately after discovering a non-functional control button so this is a guess on my part, but I presume that since I have to wait until after pressing on to press control this alarm will fire before Hottop control is actually established. Being able to define alarms that fire after on but before control has been established doesn't seem particularly meaningful to me since the action won't be able to actually do anything. I suppose I can fix that by triggering the alarm some arbitrary time after "on" but I've always considered such arbitrary time specifications inelegant. Or is there an alarm trigger I haven't seen that lets me do something after control?

[MAKOMO]

See, I don't have a horse in this race. I'm just a guy sitting at home roasting for myself and 2.8.4 does everything I need it to do. At some point I'll decide to fork over the cash to upgrade from the Hottop and this will be a moot point.

@spwoolet complained about a loss of functionality and I seconded it. I replied the way I did because the previous responses were the standard "we like the way we do things and if you don't like it make a copy and do it yourself."

Not exactly true, right. There are technical reasons for this change and I tried to explain them.

That makes it really, really difficult to have a productive conversation with respect to making your product more user friendly. But honestly, it's the knee jerk reaction I always see here so I'm pretty used to it. You have no reason to listen to anyone, but don't expect folks to be excited by that attitude.

I disagree heavily, but my suggestion is to join the team and do better.

In your first response to me you made an appeal to logic to justify the current design. Honestly, I don't see the logic. If it's logical that the off button both stops recording and turns off artisan then why is it not logical that the on button turn on artisan and start recording? If logic is the basis of the design then why does the start button exist? Perhaps because it's useful? Well, a stop button would also be useful but naturally @MAKOMO rejected that suggestion with the standard "make your own fork" response.

I think you overlook the complexity of Artisan especially to the available resources available. The reasons are in the details and influenced by decisions made 10 years ago and recent developments in the tools Artisan is build upon. This is a rather complex environment.

You do realize that the "make your own fork" response is insulting, right?

Why? Forking open-source software which does not full fill exactly my needs is at the heart of open-source and very standard practice. A project can never satisfy every need, therefore there are many. Shouldn't you be happy to be able to not have to start from scratch because I shared my code with the world that I developed for my own use?

What kind of reaction do you expect to get from "it's our game and if you don't like it go play somewhere else"?

I am not a native speaker, but my intention was to motivate you to get active yourself instead of telling just others on what they should spend their time on.

With 2.8.4 I turn on super and then control. I do this so that at the moment I turn artisan on it's already in communication with the Hottop. I have an alarm set immediately after "on" to turn the Hottop heat to 100 to start warming up the roaster. Then at 200F after on I start recording so that I'm all ready to charge at 300F.

The advantage of this old behavior is clear, but the project is not able to maintain it any longer (working around issues in the >10 years old Hottop communication protocol).

I uninstalled 2.10.4 immediately after discovering a non-functional control button so this is a guess on my part, but I presume that since I have to wait until after pressing on to press control this alarm will fire before Hottop control is actually established. Being able to define alarms that fire after on but before control has been established doesn't seem particularly meaningful to me

for your setup, but as with many features, this has not been designed for the specific use with the (broken) Hottop, but works very well with many other machines.

since the action won't be able to actually do anything. I suppose I can fix that by triggering the alarm some arbitrary time after "on" but I've always considered such arbitrary time specifications inelegant. Or is there an alarm trigger I haven't seen that lets me do something after control?

Let me try calm this discussion down with a small addition to Artisan that about reconstructs the old behavior, but requires some specific configuration. One moment.

[MAKOMO]

I added an additional ´Hottop Commandnamedcontrol(n)` which takes one argument which can be either 1 to activate the Hottop control or 0 to deactivate it. This does the same as if you would press the CONTROL button, but does implicitly activates the super user mode if not yet active and can be triggered from event buttons.

Now if you activate the "Keep ON" mechanism in the Sampling configuration (menu Config >> Sampling) which turns Artisan ON automatically after an OFF

and tell Artisan to fire this new control(1) command on ON (menu Config >> Events)

the interruption in communication at 1sec sampling speed should be less then the limit set in the Hottop firmware after a communication interruption which turns it operation off.

A new continuous builds should be available within the next 30min which includes that new command.

As always, donations are welcome!

[rmongiovi]

I accidentally activated "keep on" once after you added that feature. Unfortunately, the end result is that I turn artisan off after the end of my roast and it turns itself back on at which point my "0 degrees after on" alarm fires and turns the roaster heat back on. I presume I could "fix" that by pressing my "heat 0" button but that seems more awkward than just leaving recording on. The whole "keep on" idea has never been clear to me. I presume it's for people who do multiple back-to-back batches but at some point you do want to stop, right?

I'm sorry, but I missed your explanation for why "on followed by start" is possible but "stop followed by off" would be impossible. Each seems like the other in the opposite direction. If something about the code causes issues with this it might be time to refactor.

I do like the ability to turn control on from an alarm. That's much nicer than having to remember to press it quickly after on. Does that action wait while control is established? Would making my "heat 100" alarm an "if" after the control alarm prevent it from firing before it was able to function?

I appreciate your enthusiasm for recruiting team members. Speaking just for myself, I spent 45+ years writing software for a living and I'm old and tired. There may come a time when I'm motivated to learn your code and contribute but right now that would be biting off more than I'm willing to chew. Not to mention that I'll die happy if I never have to deal with python.