Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Component prevents machine from storing or respecting machine settings #91

Open
wtadler opened this issue Jan 14, 2025 · 2 comments
Open

Comments

@wtadler
Copy link

wtadler commented Jan 14, 2025

I have a EP3246/74 (which I purchased over other similar models because this project says it is compatible). The component works well overall! The sensors, switches, and buttons all behave as expected.

But I've noticed that, when the component is installed, the machine behaves differently. Specifically, it seems to have trouble either storing settings or respecting stored settings. I have not seen any mention of this in Issues or Discussions.

I've noticed three different problems that may all be related.

1. Drink settings

  • Expected behavior (manual): The user uses the physical buttons to select a drink, then aroma/size/foam settings, before brewing the drink. The next time the user selects that drink, even after power cycling the machine, the previously selected aroma/size/foam settings are retained.
  • Actual behavior: After I select a drink, aroma/size/foam are always set to medium (2 out of 3 lights), regardless of what the settings were the last time I made the drink.

2. Standby time

  • Expected behavior (manual): The user can follow a procedure to set the standby time, which will be respected.
  • Actual behavior: I can set the standby time to 60m. After a power cycle, if I go into the procedure again, I see from the lights that the machine seems to remember that 60m setting. But the machine seems to always go into standby after 20-30 minutes.

3. Maximum drink size

  • Expected behavior (manual): The user can follow a procedure to set the maximum drink size, which will be used the next time that drink is made.
  • Actual behavior: I can set the maximum drink size, but that setting doesn't seem to be respected the next time I make a maximum-size drink.

I have tested the machine with and without the component installed. I am pretty confident that issue 1 and 2 are due to the component. I'm a little less confident about whether issue number 3 is due to the component—I would want to do some more testing.

Is there an explanation for why this component might be causing these issues? I'd be happy to do some testing/debugging to try to get this sorted.

@TillFleisch
Copy link
Owner

Thank you for this very thorough issue description!

Is there an explanation for why this component might be causing these issues?

I don't have an explanation, but I would argue that it should not affect how the machine works and the modification should be transparent to the machine.

  1. Drink settings

I cannot observe this behavior on my EP2220. The selected size/... persist, but only if the selected beverage has been produced. Chaning the selection (without brewing coffee) and then restarting the machine will not save the selected changes. I presure this is intended/normal behavior.
A work-around could be an esphome-automation, that selects your preference settings once the beverage is selected.

  1. Standby time

I have not yet tried this. I use an ESPHome-Automation to shut down machine after 5 minutes after brewing a coffee (I only usually only drink one and therefore there is no reason to keep the machine pre-heated).

  1. Maximum drink size

I also have not played around with these settings. I would assume they are stored somewhere on the internal motherboard as that's responsible for performing the brewing procedure. IIRC the display only acts as a terminal/user-interface.

Since the programming part is probably a set-and-forget situation, do the changes persist if the modification is performed after the desired configuration has been programmed?

If you use ssieb's UART mitm component instead of this one, can you observe the same issues? In this situation, the change should be truely transparent and if the issue persists, it may be HW related.

@wtadler
Copy link
Author

wtadler commented Jan 21, 2025

Thanks for your thoughts! Yeah, it was also my impression that the component shouldn't cause these issues.

I'll try to give the ssieb component a shot (pun not intended) sometime and report back!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants