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

Replace TCRT5000? #57

Open
luftpumpe83 opened this issue Feb 12, 2023 · 17 comments
Open

Replace TCRT5000? #57

luftpumpe83 opened this issue Feb 12, 2023 · 17 comments

Comments

@luftpumpe83
Copy link

Hi!
Just found your project and it's really amazing.
Will order some PCBs right now.
But one question: is it possible to replace the TCRT5000 with another sensor? I'd really like to use the cup detection, but don't want to cut a hole in the Senseo's housing.
Best regards,
Oliver

@ThomDietrich
Copy link
Owner

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!"

@Pierre-33
Copy link

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.

@ThomDietrich
Copy link
Owner

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 :)

@Pierre-33
Copy link

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.

@luftpumpe83
Copy link
Author

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

@luftpumpe83
Copy link
Author

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 ;)
IMG_20230309_133331

@ThomDietrich
Copy link
Owner

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

@luftpumpe83
Copy link
Author

luftpumpe83 commented Mar 9, 2023

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.

@ThomDietrich
Copy link
Owner

ThomDietrich commented Mar 9, 2023

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();
  }
}

@luftpumpe83
Copy link
Author

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?

@Pierre-33
Copy link

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.

@luftpumpe83
Copy link
Author

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)

@Pierre-33
Copy link

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

@ThomDietrich
Copy link
Owner

@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?

@Pierre-33
Copy link

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.

@Pierre-33
Copy link

@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);
...

@luftpumpe83
Copy link
Author

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

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

3 participants