Support for EP3241

[poldim]

Looking to add support for this model. Happy to provide what I can. Previous discussion in this issue.

Updated video, hopefully of the correct direction:
Log: https://drive.google.com/file/d/1zgdv9gLjzWldKlpgCwNJoKhxN2zFkwBv/view?usp=sharing
Video of what I pressed when: https://photos.app.goo.gl/amxp7EkJXCvxmE3P7

[TillFleisch]

The log files contain the same content as in this comment (Messages from the display to the mainboard). Since we are currently interested in figuring out why the status sensor is not updating properly, messages from the mainboard to the display are required (as the sensor state is determined based on these messages).

Unlike the messages originating from the display, like:

D5 55 00 01 03 00 12 00 00 00 10 21 [idle]
D5 55 00 01 03 00 12 02 00 00 08 3A [espresso]
D5 55 00 01 03 00 12 00 02 00 08 38 [bean]
D5 55 00 01 03 00 12 00 08 00 3A 03 [milk]
D5 55 00 01 03 00 12 00 04 00 21 12 [size]
D5 55 00 01 03 00 12 08 00 00 38 0B [coffee]
D5 55 00 01 03 00 12 20 00 00 21 00 [americano]
D5 55 00 01 03 00 12 04 00 00 20 16 [cappuccino]
D5 55 00 01 03 00 12 10 00 00 08 31 [latte]
D5 55 00 01 03 00 12 00 01 00 1C 2D [hot water]
D5 55 00 01 03 00 12 00 10 00 0C 21 [aqua clean]
D5 55 00 01 03 00 12 00 20 00 29 20 [calc clean]
D5 55 00 01 03 00 12 01 00 00 1C 2C [power off]

(recorded display-to-mainboard messages; source)

The messages originating from the display are longer, as described in protocol.md#messages-from-the-mainboard-to-the-display.

@poldim, can you take a look at #41, as it's very similar to a part of this issue (idle state not detected on some EP2220 machines)? Maybe a similar, simple fix is possible for your machine.

[TillFleisch]

See #75, for more EP3241 related details.

[TillFleisch]

According to #75 (comment), the use of an ESP32 resolves this problem. The underlying issue has not yet been found/fixed.

[poldim]

Ok, I'll try a ESP32 board and report back

[poldim]

According to #75 (comment), the use of an ESP32 resolves this problem. The underlying issue has not yet been found/fixed.

@TillFleisch
I made a PCB to use a Wemos 32 S2 and for some reason, the ESP32 won't successfully boot / connect to wifi if I have GPIO17 connected. On my PCB this is connected to pin 5 of the main board connector which is the transmit pin from the MB to the DISPLAY so my display won't function without it. Have you come across this before?

Here's my schematic:

From what I can see it is aligned with yours...

[TillFleisch]

for some reason, the ESP32 won't successfully boot / connect to wifi if I have GPIO17 connected

My first though was that GPIO17 could be a bootstrapping pin, which does not seem to be the case.

According to espressifs general ESP32 documentation:

SPI0/1: GPIO6-11 and GPIO16-17 are usually connected to the SPI flash and PSRAM integrated on the module and therefore should not be used for other purposes.

The ESP-32-S2 documentation nor the ESP-32-S2 technical reference manual do not seem to mention this.

I would recommend trying a different pin to see if this resolves the issue or if there are other underyling problems.
Futhermore, measuing what happens on GPIO17 would be a good idea. The serial USB connection may also give hints. Maybe the ESP is booting into programming mode for some reason.

Also make sure the orientation of the picoflex connector is correct (seems to be correct) and that you don't have RX and TX mixed up throughout the interception.

From a software standpoint, a simpler firmware may be suitable for debugging. See ssiebs MITM component, which forwards traffic without further considerations.

[poldim]

@TillFleisch

My first though was that GPIO17 could be a bootstrapping pin, which does not seem to be the case.
I remember I looked at the strapping pins and intentionally avoided them, but that's the first thing I checked.

Then I used a bodge wire to try GPIO 34. That didn't work, same result. I thought maybe because it's input only so I tried GPIO 8. Same exact thing.

I'm confused as to why this works fine on 8266 but not 32-S2. It's super weird that three pins now prevent the ESP from booting.

Maybe I can add a MOSFET to connect that pin after a few seconds? Any idea if the drain should be toward the MB or the ESP?

[TillFleisch]

Maybe I can add a MOSFET to connect that pin after a few seconds?

This sounds like a patch and we should rather figure out the cause of this issue.
To rule out that this is related to the software of this repository, try running a simple blink sketch on the ESP and see if the issue persists. Similarly, I would recommend running the new board outside of the coffee machine and try powering it using a separate 5V power supply. Then you can experiment with pulling the pin/your exposed pin so GND/3.3V(logical high) to see if this causes the same error. Maybe even try sending/receiving data over the pin using a simple sketch as this could give more insight. It may also be the case that the issue is caused by something else and that GPIO34 not working is just a symptom. Perhaps the other line of the serial communication is causing the fault. Also make sure to not mix up the PIN and GPIO definitions, as they are sometimes used interchangeably.

Alternatively you could try using an entirely different pin with softwareserial (iirc the ESP32 can do HW serial on most pins in contrast to the ESP8266).