Hey Oliver,
certainly understandable and a valid question we asked ourselves as well.

Short answer: No.

Long answer: The TCRT is the best option I am aware of. I would refrain from any sensor under the cup (push button or pressure sensor) for the obvious reasons around moisture and cleaning. A contactless sensor is the way to go. An alternative might be an ultrasonic sensor or any other radio sensor, which might work behind the plastic - however, a probable issue is the limited space inside the machine. Be my guest to give it a try.

Honestly, in my humble opinion, don't bother. The small hole in the housing is barely visible and no one ever realized and asked about it. On the contrary, it was always convenient for me to say "yeah I've hacked the coffee machine, check out this sensor for cup detection!"

For your information, I plan to try this one very soon: https://www.az-delivery.de/en/products/ir-abstand-sensor-modul
It seems to be pretty much the same but with a different form factor. I hope to achieve something cleaner with two round holes for the leds than a clumsy rectangle (and I should be able to bend the led a bit if the space between the hole is not perfectly right.

I'll let you know how it goes, but I don't expect to be at the drilling stage before a few weeks.

Good idea. From the far my modification looks like a clean little rectangular element, as if it belongs to the machine design. Btw "from the far": because of the nozzle, you can't even see it when next to the machine. As said before: Don't bother :)

I received the distance sensor I mentioned before and it works exactly like the TCRT5000 you use but it's way bigger (basically the size of two LEDs). Turn out the TCRT5000 is way smaller than I imagined. No sure which one I'm going to actually use within my Senseo.

Okay... will think about it... Thank you :)

Used the TCRT5000, but I constructed a holder for it so I could simply drill a 10 mm hole instead of cutting out a little rectangular hole.
Looks almost like it belongs there ;)

Nice! Looks great
Btw which Senseo is that? Feel free to add it as supported to the Readme

It's Senseo Quadrante HD 7863/60 from 2013.
I've just uploaded the file to Thingiverse: https://www.thingiverse.com/thing:5900774
For the Quadrante it was easy to create because the surface is even. The "normal" Senseos have a curved housing, so you have to know its radius first to create a similar holder.
I just created an automatisation in HA to let it beep "tone3" if the cup is recognized and "tone4" if it's no longer recognized :)
It's because if you put the cup too close to the sensor, it will not be recognized. Tried to adjust the sensor but that behaviour didn't change, so I had to add a little audio feedback.
Is it possible to have a tone sequence for the buzzer? Tried to publish one tone after the other via MQTT but it seems you can only publish one value per payload.

I must admit that the buzzer handling is a bit of a weak spot of the code as it is today. tone() is a blocking method, which could theoretically fail other actions of the machine.

I have recently hacked together a better solution, which you might like. It utilized ezBuzzer instead of tone. Would you like to give this a try? I would appreciate a PR that replaces all tone() calls by ezbuzzer.

#include "SenseoLed.h"
#include "SenseoSM.h"
#include "pins.h"
#include "constants.h"
#include <ezBuzzer.h>

SenseoLed mySenseoLed(ocSenseLedPin);
SenseoSM mySenseoSM;
ezBuzzer buzzer(beeperPin);

int melody1[] = {
  NOTE_C7
};
int noteDurations1[] = {
  2
};

int melody2[] = {
  NOTE_E5, NOTE_E5, NOTE_F5, NOTE_C5
};
int noteDurations2[] = {
  4, 8, 8, 2
};

int melody3[] = {
  NOTE_C4, NOTE_C5
};
int noteDurations3[] = {
  4, 8
};

//void ICACHE_RAM_ATTR ledChangedHandler() {
void IRAM_ATTR ledChangedHandler() {
  mySenseoLed.pinStateToggled();
}

void senseoStateExitAction() {
  switch (mySenseoSM.getStatePrev()) {
    case SENSEO_OFF: {
      int length = sizeof(noteDurations3) / sizeof(int);
      buzzer.playMelody(melody3, noteDurations3, length);
      break;
    }
  }
}

void senseoStateEntryAction() {
  switch (mySenseoSM.getState()) {
    case SENSEO_READY: {
      //tone(beeperPin, 1536, 500);
      int length = sizeof(noteDurations1) / sizeof(int);
      buzzer.playMelody(melody1, noteDurations1, length);
      break;
    }
    case SENSEO_NOWATER: {
      //tone(beeperPin, 4096, 1800);
      int length = sizeof(noteDurations2) / sizeof(int);
      buzzer.playMelody(melody2, noteDurations2, length);
      break;
    }
  }
}

void setup() {
  pinMode(ocPressLeftPin, OUTPUT);
  pinMode(ocPressRightPin, OUTPUT);
  pinMode(ocPressPowerPin, OUTPUT);
  pinMode(ocSenseLedPin, INPUT_PULLUP);

  digitalWrite(ocPressPowerPin, LOW);
  digitalWrite(ocPressLeftPin, LOW);
  digitalWrite(ocPressRightPin, LOW);

  //pinMode(beeperPin, OUTPUT);
  pinMode(resetButtonPin, INPUT_PULLUP);
  pinMode(cupDetectorPin, INPUT_PULLUP);
  pinMode(cupDetectorAnalogPin, INPUT);

  attachInterrupt(digitalPinToInterrupt(ocSenseLedPin), ledChangedHandler, CHANGE);
  tone(beeperPin, 1536, 2000);
  delay(2500);
}

void loop() {
  buzzer.loop();
  mySenseoLed.updateState();
  mySenseoSM.updateState(mySenseoLed.getState());
  if (mySenseoSM.stateHasChanged()) {
    senseoStateExitAction();
    senseoStateEntryAction();
  }
}

I REALLY would like to test it, but I have absolutely no idea where to put the code. I guess it has to be inserted in the SenseoWifi.cpp?
Maybe you could upload something like a beta version so I can copy the whole folder to Platform.io?

Grab the latest from my fork : https://github.com/Pierre-33/SenseoWifi
You should be able to request "melody1", "melody2" and "melody3" from MQTT now in addition to the previous tone. I couldn't test it myself but it does compile so it's a great start :)

You can then try to add yourself more melody in the buzz function.

Working! Thank you! Now I will find out how to use it and become a composer ;)
(btw: deleted senseo_wifi.yaml as you said in my other issue and it's still working)

Let me know if you came up with some nice tune and I’ll them to my pull request.

@Pierre-33 looks perfect! Because of the blocking method issue I would ideally get rid of tone() all together. Let's discuss in a PR?

The thing is that I don't know how to submit a PR with only the buzz change (I'm not so much confortable with git, I'm more of a peforce guy myself). So I was waiting for you to accept the one with HomeAssistant discovery before opening the one with the buzzer.

@luftpumpe83 how is going your Senseo? I'm affraid that by using AsyncMqttClient 0.9.0 in my fork I introduced an issue. Your Senseo won't be able to reconnect to the MQTT server if your wifi connection drop for a while.

This can be fix with by adding this dirty hack on the HomieEventType::WIFI_CONNECTED events:

void onHomieEvent(const HomieEvent &event)
{
    switch (event.type)
    {
    case HomieEventType::WIFI_CONNECTED:
        // If myIP is set, this is not the first time the wifi is connected
        if (myIP != IPAddress(0,0,0,0)) 
        {
            // With AsyncMqttClient 0.9.0, Homie can't reconnect to MQTT after a wifi disconnection
            // Unfortunately 0.8.2 (which is the version packaged with Homie), has a mqtt max payload size to low for sending Home Assistant Autodiscovery config
            // This is clearly a bad workaround but I have nothing better yet
            Serial.println("We lost Wifi Connection during Operation. The Esp need to reboot");
            Homie.reboot();
        }
        myIP = event.ip;
        ...
        break;
    ...
    }
}

You'll need to declare your variable somewhere in your SenseoWifi.cpp as well

...
HomieNode senseoNode("machine", "senseo-wifi", "senseo-wifi");
IPAddress myIP = IPAddress(0,0,0,0);
...

Hi,
it's still working fine. But as you say, sometimes the connection is lost. So I will try your "dirty hack" soon :)