Philips EP3243/EP3246 Support

[sendorm]

Hello,

Is there a way to add support for EP3200 series coffee machines. The codes can be found here:

https://github.com/micki88/Philips-ep3200-testing

Thanks

[TillFleisch]

Yes, it is possible to add support for the ep3200, but the codes providedin the linked repository only include actions.
The state sensor part of this component may not work, as the ep3200 could use different messages for status indications.

I would recommended forking this repository and playing around with the codes provided in the linked repository. (Replace the once included in this repo with the new onces)

Adding support for different machines (and subsequent messages/protocols) would require restructuring this repository.
Maybe I will get around to doing that some day, but I cannot promise anything.

[sendorm]

I am not confident %100 but the linked repo was also a fork of ep2200 and the author stated that everything was working, so statws should be same. I have forked your repo and will give it a go. Thank you.

[quack3d]

@sendorm Any progress? I have a 3200 so I'm also interested.

[sendorm]

Tried to have a go but it was harder than I anticipated :)

[poldim]

@TillFleisch I'm working on a local copy of the custom component based on your repo. As you suggested in your comment above, the status sensor is not working. It never changes state from off state which means I can't turn off the machine through the ESP as the switch moves back to off state as soon as you turn it on

I'd like to try to see if I can see the messages on the bus to try to solve this. In your protocol.md document you said "The messages were obtained by listening to the bus." - Can you share how you did this? Was this using the ESP or some external debugger?

It might be nice to have a text sensor that publishes the protocol messages to debug similar to the MQTT impletementation. Unfortunately, my C++ skills aren't capable of making it.

[TillFleisch]

@poldim I would recomment using the built in ESPHome uart debug functionality.
Just add the following lines to one of the uart ports.

    debug:
      direction: BOTH
      sequence:
        - lambda: UARTDebug::log_hex(direction, bytes, ' ');

Publishing all messages via MQTT or a text sensor is not a feasible option, since the bus is always busy.

[poldim]

@poldim I would recomment using the built in ESPHome uart debug functionality. Just add the following lines to one of the uart ports.

    debug:
      direction: BOTH
      sequence:
        - lambda: UARTDebug::log_hex(direction, bytes, ' ');

Awesome, that worked. The semi-processed data is here that just regexed them into individual rows: https://pastebin.com/iuDnQb3S

It appears when I sent the power on command it went through this sequence:
D5 55 0A 01 02 00 02 00 00 00 0E 12 6x times
D5 55 02 01 02 00 02 00 00 00 38 15 6x times
^^^ these follow your protocol power on logic

D5 55 00 01 03 00 12 00 00 00 10 21 5800x times
^^^ these are unexplained as they have 03 and your protocol doesn't address that

D5 55 00 01 03 00 12 00 00 00 10 C8
D5 55 00 01 03 00 12 00 00 00 10 21
D5 55 00 01 03 00 12 00 00 00 88 C8
^^^ variants with different checksums on the end but ultimately
D5 55 00 01 03 00 12 xx xx xx xx xx was seen another 252x times

this is the rest of the data in a pivot table:

I'll have to run it for longer and see if I can find any pattern, but let me know if you have any other suggestions.

Publishing all messages via MQTT or a text sensor is not a feasible option, since the bus is always busy.
it appears they solved it by only publishing the value if it was different than the last, but I'm not sure if that can be implemented in ESPHome

  if (strcmp(newStatus, oldStatus) != 0) {
    mqttClient.publish("coffee/status", newStatus);
    strncpy(oldStatus, newStatus, 19);

[RichyT]

That's interesting. Checksums don't change. That's why they're checksums. Also notable is that the 10 repeats once then the C8 is repeated from earlier. Seems like something odd is going on with those two bytes. Could they just be some kind of serialization?

Also that the 1021 is repeated but with a different data packet is probably meaningful.

Is it confirmed that the 'checksum' doesn't work if it's not correct for the data?

(I guess these could also be errors introduced by the "man in the middle"?

[TillFleisch]

That 'checksum' problem is interesting.

Is it confirmed that the 'checksum' doesn't work if it's not correct for the data?

I quickly checked the following on my EP2200:
I've incrased the last byte of the turn on/off and make coffee button commands by 1. The coffee machine did not respond as expected(nothing happend). Logs showed a 00 .. 00 empty display response. In my case the machine is reading the messages and responding but not interpreting, since the checksum is wrong.

The messages seem to be very consistent. The checksums remains unchanged.
In between lots of these (D5 55 00 01 02 00 02 00 00 00 11 36) messages I found:
D5 55 00 01 20 02 00 00 00 11 36 which seems to be currupted. I presume the mainboard just ignored it.

I guess @poldim could be experiencing noise on the bus. It is wierd though, that only the last bytes are affected. This may be a phenomenon caused by filtering the messages starting with D5 55. I would suggest re-check wiring and proper ground connections.

[RichyT]

Noise would also help explain the apparent high number of what I would assume are retries.

It's a shame the checksum is so opaque. I tried various permutations against a checksum calculator and had no luck either.

[quack3d]

Hm. On my 3200 (EP3243) series I did get logs saying On/Off and Cleaning when it started to clean. Without customizing any code I think (I've now tried replacing the codes for the 2200 with 3200 from https://github.com/mkorenko/esp-phillips-3200/ ). But my problem is that my ESP32-S2 Mini won't boot if power pin is plugged in. I can plug it in after boot and turning on the machine works from HA and from display button and I can use the action to make a coffee from HA. But the display doesn't work even though there are lights on it. Does this look correctly wired to you?

[quack3d]

I replaced the S2 Mini with a Wemos D1 Mini and I'm now using a MOSFET instead. I've used debug logging to find pre-power, power with cleaning and power without cleaning. But when I turn it on with cleaning (either from HA or from the display button) the lights on the display go on normally in a circle but right when the water is supposed to come out there's a beep and it stops.

What could cause that? It won't finish the cleaning cycle.

[quack3d]

And when I hit 'Select Coffee' it selects coffee but starts by itself after 2 seconds but then stops immediately with a beep. I don't understand why it starts by itself and I don't understand why it stops.

[TillFleisch]

there's a beep and it stops

That sounds like the power off button is pressed (either hardware/stimulated).
I would recommend logging the messages and looking for power off messages. Maybe the ESPHome button component is turned off (possibly by accident, or timeout (since the machine status is not detected)), which would result in this behaviour.

when I hit 'Select Coffee' it selects coffee but starts by itself after 2 seconds but then stops immediately with a beep

The starting by it self could be a configuration problem. Based on the selected action, the play button is pressed automatically (actions stating with make_). As for the stopping, I have no clue but would recommend logging. Maybe this can give more insight. The beep sound indicates that a button was pressed (possibly play/pause which would abort the process).

[quack3d]

Maybe the Wemos D1 Mini I have is just weird. I have the USB-C variant. I went back to trying my ESP32 S2 Mini again and there it seems like everything works except for a consistent power on (which was reliable on the D1 Mini)... I think I need to use inverted = true but can't find a GPIO PIN working consistently. After the machine has been off for a while and I turn it on in HA the display lights up and works like it should. But if I turn it off and on after 10 seconds the display remains off. I've tried changing the default 1s to 0.3s, 0.5s and 1.5s and nothing seems to work reliably. Ideas?

[TillFleisch]

Sometimes, on my machine the display does not turn on (but the machine does), when turned on through HA.
Every once in a while, I wake up to the machine appearing to be turned off. If I press the power button, the machine is available immediately.
I have not figured out what the cause for this is. From a different project I know that the UART timing (after using flush) is weird ever since the ESPHome update that updated the Arduino core version to 2.0+. (The time between calling flush and the bus being written to is longer and inconsistent). I'm trying various different things, but due to the randomness of this problem, troubleshooting this issue takes a bit.

Is the waiting 10s to get it to not power the display on a consistent behaviour on your device?

[quack3d]

Current state: When power to the machine has been off I can't turn it on with the power button on the display. I have to use HA to turn it on. Then the display comes on normally. If I then turn off the machine (either from display or from HA), I can only turn on the machine (and display) from the display power button. Turning it on from HA makes the machine turn on but not the display. It doesn't matter if I wait 1 second or 10. But like you said, touching the power button makes the display come on immediately.

Current settings on my ESP32 S2 Mini:
power_pin: GPIO34
invert_power_pin: true
power_trip_delay: 1s

[quack3d]

This is my wiring atm:

[TillFleisch]

Sometimes, on my machine the display does not turn on (but the machine does), when turned on through HA.

The latest changes seem to have resolved this issue for me. The ESP will now perfrom multiple power trips, if the display does not turn on.
Maybe this helps with your problem as well.

[quack3d]

[19:23:00][W][component:214]: Component esphome.coroutine took a long time for an operation (1.00 s).
[19:23:00][W][component:215]: Components should block for at most 20-30ms.
[19:23:02][W][component:214]: Component esphome.coroutine took a long time for an operation (1.00 s).
[19:23:02][W][component:215]: Components should block for at most 20-30ms.
[19:23:04][W][component:214]: Component esphome.coroutine took a long time for an operation (1.00 s).
[19:23:04][W][component:215]: Components should block for at most 20-30ms.
[19:23:06][W][component:214]: Component esphome.coroutine took a long time for an operation (1.00 s).
[19:23:06][W][component:215]: Components should block for at most 20-30ms.
[19:23:08][W][component:214]: Component esphome.coroutine took a long time for an operation (1.00 s).
[19:23:08][W][component:215]: Components should block for at most 20-30ms.
[19:23:10][W][component:214]: Component esphome.coroutine took a long time for an operation (1.00 s).
[19:23:10][W][component:215]: Components should block for at most 20-30ms.
[19:23:11][E][philips_power_switch:024]: Power tripping display failed!

Same behaviour unfortunately. Display will only turn on from HA if power to the machine and ESP32 has been removed completely.

[quack3d]

Actually, if I just remove the power from VBUS (red cable) or push the RST button so that the ESP32 reboots it IS able to turn on the display each time. Any ideas why?

[TillFleisch]

I am pretty clueless. Maybe there is some way for current to flow and the mosfet 'removing' the ground pins isn't enough for the display to restart.

[quack3d]

I got a good suggestion at ESPHome on Discord. I replaced:

power_pin_->digital_write(!power_pin_->digital_read());
delay(power_trip_delay_);
power_pin_->digital_write(!power_pin_->digital_read());

With:

power_pin_->digital_write(false); // Turn off
delay(power_trip_delay_);
power_pin_->digital_write(true); // Turn on

And removed 'invert_power_pin: true'.

Then it seems to work every time. There's one weird issue though. If I cut the power to the machine and the ESP and turn it back on, it beeps after 11 seconds, then after 8 seconds and display comes on with lights on every drink and a blinking Aqua Clean. The display is not responding to touch and status in Home Assistant is that it's turned on and 'Cleaning'. Workaround seems to be to turn the machine on immediately after power plug is connected.

[TillFleisch]

power_pin_->digital_write(false); // Turn off
delay(power_trip_delay_);
power_pin_->digital_write(true); // Turn on

This should also happen with the pin inversion method if you use invert_power_pin: false (which is the default configuration). Can you verify that this is working as well?

The turning on after power-up is weird and may be a side effect from using a strapping pin. See this documentation for more information regarding strapping pins on the ESP32. Same goes for the 8266.

[quack3d]

This should also happen with the pin inversion method if you use invert_power_pin: false (which is the default configuration). Can you verify that this is working as well?

No. Just tested again. When I use

power_pin_->digital_write(!power_pin_->digital_read());
delay(power_trip_delay_);
power_pin_->digital_write(!power_pin_->digital_read());

And

invert_power_pin: false

It's not turning on the display.

[TillFleisch]

Hm.. it seems inverting the power pin isn't a valid move after all. I'll open up a pr to close this issue.

Are you using the Arduino or IDF Framework?

[quack3d]

Arduino?

esp32:
  board: lolin_s2_mini
  framework:
    type: arduino

[quack3d]

Btw, what will be the best way to update the status sensor with "Brewing" for instance after start button is pressed? I'd like to create some kinda logging of each coffee typed brewed. The 5400 series has that in the display but we could do it in HA. :) If we add 'Brewing' to status sensor I guess an automation in HA triggering on "to state 'Brewing'" and logging the from state could work. Maybe you have a better suggestion?

And what's your reasoning behind having one size adjustment and one beans adjustment for each coffee type? Simplicity? Wouldn't it make more sense to have just one size adjustment and one beans adjustment and it will work for every coffee type? My 3200 series has Coffe, Espresso, Americano, Cappuccino and Latte Macchiato.

I'm gonna fork this repo soon (when I can find time) for my EP3200 version. I added milk level settings and it seems like everything is working. I haven't figured out a good way of selecting ground coffee though. Not sure if a 4th level to size is the way too go.

[TillFleisch]

Btw, what will be the best way to update the status sensor with "Brewing" for instance after start button is pressed? I'd like to create some kinda logging of each coffee typed brewed.

For a quick solution I would recommend using template sensors and global variables in ESPHome directly. This way you could remember the last selected coffee type and then update your template sensor accordinly, once it goes to brewing. Keep in mind that the state change to [x] Selected must be awaited, since it is not always visible when using the make_coffee option on the button component.

And what's your reasoning behind having one size adjustment and one beans adjustment for each coffee type?

Your suggestion would work just as well. I added them per-type, such that configuration is easier. I think building automations with these components is easier as the 'available/unavailable' status can be used as a trigger, which results in less nested/complex yaml configurations.
If you want to build a single input for these, I believe you can set the individual number component to internal: true and merge them together using template components.

I haven't figured out a good way of selecting ground coffee though.

I would say a button component would be best suited for this application. I decided not to add this as a feature, as there is little/no point in automating this functionality. The assumption being: If someone needs to use the group coffee function, they have to interact with the machine anyways.

I'm gonna fork this repo soon (when I can find time) for my EP3200 version.

Happy coding!

[poldim]

Which coffee machine model do you own?
EP3241

While this is possible, I think it's a bad idea as there can be noise on the bus/ incomplete messages which would result in a lot of updates. This may be possible using templates in ESPHome. The lambda of the uart debug component could also manage this. See here.

I've seen some custom components implement this without issues. If the sensor is disabled by default, just mentioning that's it's for debug only should be sufficient.

[TillFleisch]

This UART debug config may be used to retrieve some logs from the display side. This uses some filtering but the bus seems very noisy, therefore there are a lot of updates/messages which may or may not be useful. Since we don't know how the checksum is calculate there is no elegant solution.

globals:
  - id: last_message
    type: std::vector<uint8_t>
  - id: same_message_count
    type: uint8_t

uart:
  - tx_pin: GPIO1
    rx_pin: GPIO3
    baud_rate: 115200
    id: uart_mainboard
    debug:
      direction: TX
      sequence:
        - lambda: |
            while (bytes.size()>=12)
            {
                // Search for start bytes
                // Checking byte 9 filters a lot of noisy (invalid) message but may also remove valuable message
                // Since we don't know how the checksum is calculated, this is the best we can do
                if (bytes[0] == 0xD5 && bytes[1] == 0x55 &&
                    (bytes[9] == 0x00 || bytes[9] == 0x01))
                {
                  // Assume D5 55 does not appear in messages, skip invalid messages
                  for (int i = 2; i < 11; i++){
                    if (bytes[i] == 0xD5 && bytes[i+1] == 0x55){
                      bytes.erase(bytes.begin(), bytes.begin() + (i-1));
                      return;
                    }
                  }

                  // Log byte subsection
                  std::vector<uint8_t> subset(bytes.begin(), bytes.begin() + 12);

                  if(subset != id(last_message)){
                    // Append message repetition count
                    id(last_message).push_back(0);
                    id(last_message).push_back(0);
                    id(last_message).push_back(id(same_message_count));
                    
                    // Filter out rare messages. This may also remove some valuable information
                    if(id(same_message_count) > 3){
                      UARTDebug::log_hex(direction, id(last_message), ' ');
                    }
                    id(same_message_count)=0;
                  }

                  id(last_message) = subset;
                  id(same_message_count)++;

                  // remove logged bytes from buffer
                  bytes.erase(bytes.begin(), bytes.begin() + 12);
                }else{
                  // remove first byte
                  bytes.erase(bytes.begin());
                }
            }

Generates a log like this:

[14:42:50][D][uart_debug:114]: >>> D5 55 00 01 02 00 02 00 00 00 11 36 00 00 08
[14:42:50][D][uart_debug:114]: >>> D5 55 00 01 02 00 02 00 00 00 88 F3 00 00 01
[14:42:52][D][uart_debug:114]: >>> D5 55 00 01 02 00 02 00 00 00 11 36 00 00 58  [this is an idle message]
[14:42:52][D][uart_debug:114]: >>> D5 55 00 01 02 00 02 00 00 00 44 F3 00 00 01
[14:42:56][D][uart_debug:114]: >>> D5 55 00 01 02 00 02 00 00 00 11 36 00 00 16
[14:42:57][D][uart_debug:114]: >>> D5 55 00 01 02 00 02 08 00 00 39 1C 00 00 15
[14:42:57][D][uart_debug:114]: >>> D5 55 00 01 02 00 02 08 00 00 39 C7 00 00 01
[14:42:57][D][uart_debug:114]: >>> D5 55 00 01 02 00 02 08 00 00 39 1C 00 00 12 [this is a select coffee message]
[14:42:57][D][uart_debug:114]: >>> D5 55 00 01 02 00 02 08 00 00 4E FC 00 00 01
[14:42:57][D][uart_debug:114]: >>> D5 55 00 01 02 00 02 08 00 00 39 1C 00 00 12
[14:42:58][D][text_sensor:064]: 'Status': Sending state 'Coffee selected'

As you can see there is a lot of noise. The last byte contains how often the message has been seen before a different message appeared.

[quack3d]

The POWER_MESSAGE_REPETITIONS set to 25 makes the display not turning on when started from HA on my EP3243. When I change it back to 5 it works again (#34). Could this perhaps be more related to variant of ESP and or mosfet/transistor rather than coffe machine model?

[sendorm]

The POWER_MESSAGE_REPETITIONS set to 25 makes the display not turning on when started from HA on my EP3243. When I change it back to 5 it works again (#34). Could this perhaps be more related to variant of ESP and or mosfet/transistor rather than coffe machine model?

I also have the same issue. But if I press the power switch again, the display turns on and it is not just a restart it just light up and the progress does not change. So I just double click the power button with a second interval. Can you repeat this behaviour?

[quack3d]

But if I press the power switch again, the display turns on and it is not just a restart it just light up and the progress does not change.

Yeah. It's the same behaviour we've experienced before.

[TillFleisch]

Could this perhaps be more related to variant of ESP and or mosfet/transistor rather than coffe machine model?

Maybe, probably, I'm not sure.

I've exposed the repetition count for power on messages now via the yaml config (and reverted the default value). I should have done this in the first place to not break any working machines.

[TillFleisch]

@sendorm any update on the Latte button? Based on the logs it looks like your machine uses the same codes as @quack3d's machine, therefore the Button should work as well.
Does the power switch (without cleaning) works as expected after using the machine once after power-loss?

[sendorm]

@sendorm any update on the Latte button? Based on the logs it looks like your machine uses the same codes as @quack3d's machine, therefore the Button should work as well. Does the power switch (without cleaning) works as expected after using the machine once after power-loss?

I found the problem, my configuration was wrong.
[00:46:05][D][button:010]: 'Select Latte Macchiato' Pressed.
[00:46:05][E][philips-action-button:166]: Invalid Action provided!

After changing it to "action: SELECT_LATTE" it works. Also the power without clean and with clean works.

The screen powers up each time too.

Thanks for the great work.

[TillFleisch]

@poldim based on the official product page, the EP3246 and EP3241 seem to be identical except for cosmetic differences (like the EP3243). Does the PR draft work for you? If so, we can add the EP3241 as an alias as well.

[poldim]

@poldim based on the official product page, the EP3246 and EP3241 seem to be identical except for cosmetic differences (like the EP3243). Does the PR draft work for you? If so, we can add the EP3241 as an alias as well.

How do I download the PR as a complete download?

[TillFleisch]

You can play around with these changes by using

external_components:
  - source: github://TillFleisch/ESPHome-Philips-Smart-Coffee@series-3200
    refresh: 30min

in your configuration. If you want a local copy you can (fork and) clone this repository and checkout the series-3200 branch.

[poldim]

You can play around with these changes by using

external_components:
  - source: github://TillFleisch/ESPHome-Philips-Smart-Coffee@series-3200
    refresh: 30min

in your configuration. If you want a local copy you can (fork and) clone this repository and checkout the series-3200 branch.

Just tried to build the bin from your example yaml in the 3200 branch

Initial error when trying to compile:

INFO ESPHome 2024.3.0-dev
INFO Reading configuration /config/esphome-espresso.yaml...
Failed config

text_sensor.philips_coffee_machine: [source /config/esphome-espresso.yaml:355]
  platform: philips_coffee_machine
  controller_id: philip
  
  ID 'status' conflicts with the name of an esphome integration, please use another ID name.
  id: status
  name: Status

I tried changing the id to philips_coffee_machine_status and also tried commenting out the status sensor, both gave me this error:

INFO ESPHome 2024.3.0-dev
INFO Reading configuration /config/esphome-espresso.yaml...
INFO Generating C++ source...
Traceback (most recent call last):
  File "/usr/local/bin/esphome", line 33, in <module>
    sys.exit(load_entry_point('esphome', 'console_scripts', 'esphome')())
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/esphome/esphome/__main__.py", line 1041, in main
    return run_esphome(sys.argv)
           ^^^^^^^^^^^^^^^^^^^^^
  File "/esphome/esphome/__main__.py", line 1028, in run_esphome
    rc = POST_CONFIG_ACTIONS[args.command](args, config)
         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/esphome/esphome/__main__.py", line 407, in command_compile
    exit_code = write_cpp(config)
                ^^^^^^^^^^^^^^^^^
  File "/esphome/esphome/__main__.py", line 192, in write_cpp
    generate_cpp_contents(config)
  File "/esphome/esphome/__main__.py", line 204, in generate_cpp_contents
    CORE.flush_tasks()
  File "/esphome/esphome/core/__init__.py", line 679, in flush_tasks
    self.event_loop.flush_tasks()
  File "/esphome/esphome/coroutine.py", line 246, in flush_tasks
    next(task.iterator)
  File "/esphome/esphome/__main__.py", line 184, in wrapped
    await coro(conf)
  File "/config/.esphome/external_components/1b42c715/components/philips_coffee_machine/number/__init__.py", line 70, in to_code
    parent = await cg.get_variable(config[CONTROLLER_ID])
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/esphome/esphome/cpp_generator.py", line 636, in get_variable
    return await CORE.get_variable(id_)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/esphome/esphome/core/__init__.py", line 795, in get_variable
    raise ValueError(f"ID {id!r} must be of type ID!")
ValueError: ID 'philip' must be of type ID!

[TillFleisch]

ValueError: ID 'philip' must be of type ID!

What is the ID of your main philips_coffee_machine component?

I tried changing the id to philips_coffee_machine_status and also tried commenting out the status sensor

If you are using a number (beverage settings) component a text status sensor is required.

You may want to try the 32xx related configurations which are used in the CI pipeline. See here and here. Your issue may also be related to ESPHome version 2024.3.x.dev, which I did not take a look at yet. The CI passed for the last publicly available (via pip) version of ESPHome.

[poldim]

ValueError: ID 'philip' must be of type ID!

What is the ID of your main philips_coffee_machine component?

I tried changing the id to philips_coffee_machine_status and also tried commenting out the status sensor

If you are using a number (beverage settings) component a text status sensor is required.

You may want to try the 32xx related configurations which are used in the CI pipeline. See here and here. Your issue may also be related to ESPHome version 2024.3.x.dev, which I did not take a look at yet. The CI passed for the last publicly available (via pip) version of ESPHome.

So I needed to change the id of the status text sensor and then also the status_sensor_id in the two numbers to match.

When I flashed using your config with the pins for my hardware setup, the display didn't turn on. Then I noticed you have invert_power_pin = true which was the culprit.

The good news is most of the stuff works, the bad news is that the new stuff for this machine (beans/size) don't work. Selecting any value didn't do anything on the machine. It stayed at the original 2 dots on both beans and size.
Status also didn't work.

For reference, the hex code that I pasted in an earlier post for beans / size / milk amount does work in my version of your code as manual buttons.

logger:
  baud_rate: 0

external_components:
####  - source: github://TillFleisch/ESPHome-Philips-Smart-Coffee@main
  - source: github://TillFleisch/ESPHome-Philips-Smart-Coffee@series-3200
    refresh: 30min

uart:
  # UART connected to the mainboard
  # - tx_pin: GPIO1
  #   rx_pin: GPIO3
  - tx_pin: TX
    rx_pin: RX
    baud_rate: 115200
    id: uart_mainboard

  # UART connected to the display
  # - tx_pin: GPIO15
  #   rx_pin: GPIO13
  - tx_pin: D1
    rx_pin: D5
    baud_rate: 115200
    id: uart_display

philips_coffee_machine:
  display_uart: uart_display
  mainboard_uart: uart_mainboard
  power_pin: D7
  invert_power_pin: false
  power_trip_delay: 750ms
  id: philip
  model: EP_3243

text_sensor:
  - platform: philips_coffee_machine
    controller_id: philip
    id: philips_coffee_machine_status
    name: "Status"

switch:
  - platform: philips_coffee_machine
    controller_id: philip
    name: "Cleaning Power"
    icon: mdi:coffee-maker
  - platform: philips_coffee_machine
    controller_id: philip
    name: "Power"
    clean: false
    icon: mdi:coffee-maker

button:
  - platform: philips_coffee_machine
    controller_id: philip
    action: MAKE_COFFEE
    name: "Make Coffee"
    icon: mdi:coffee

  - platform: philips_coffee_machine
    controller_id: philip
    action: SELECT_HOT_WATER
    name: "Select Hot Water"
    long_press: true
    icon: mdi:tea

  - platform: philips_coffee_machine
    controller_id: philip
    action: MAKE_LATTE
    name: "Make Latte"
    icon: mdi:coffee

  - platform: philips_coffee_machine
    controller_id: philip
    action: SELECT_AMERICANO
    name: "Select Americano"

number:
  - platform: philips_coffee_machine
    type: bean
    name: "Coffee beans"
    controller_id: philip
    status_sensor_id: philips_coffee_machine_status
    source: COFFEE
  - platform: philips_coffee_machine
    type: size
    name: "Coffee size"
    controller_id: philip
    status_sensor_id: philips_coffee_machine_status
    source: COFFEE

[TillFleisch]

Status also didn't work.

In any situation or only when selecting on of the new beverages? The codes from this comment seem to be identical with the ones of the current PR draft. Therefore, adding a button with action SIZE should work.
The beverage settings number component not working is likely a direct consequence of the status sensor not reporting the correct state. The selected beverage determines which number components are available/enabled.

@quack3d can you replicate this issue on the EP3243?

[quack3d]

Milk, bean and size all working fine here. Status works as well. I noticed @poldim uses source: COFFEE though. I haven't specified source so it's available for all the different beverages.

[TillFleisch]

@quack3d, can you do some testing (including beverage with specific source) on your EP3243 to validate the current proposal is working as intended. This would go a long way towards merging the PR, as I don't have the resources to test this. @sendorm feel free to chime in.

It may be the case that the EP3241 is just built differently. In this case we should open a separate PR for adding support, since this issue and the related PR draft is about the EP3243 (and the EP3246, as there are no differences).

[quack3d]

I tested now with @poldim's setup above but with different tx pins, rx pins, power pin and without power_trip_delay. After hitting Power the machine starts and status becomes 'Idle' after a bit like it should. @poldim But in your setup you don't have SELECT_COFFEE so the 'Coffee beans' and 'Coffee size' is not intended to work (if I understand @TillFleisch's intention here). You need to specify source to 'ANY' (or simply remove 'source: COFFEE') for them to work with all beverages. Otherwise you need one for each source like this one for Americano:

  - platform: philips_coffee_machine
    type: bean
    name: "Americano beans"
    controller_id: philip
    status_sensor_id: philips_coffee_machine_status
    source: AMERICANO

[TillFleisch]

The select option on the beverage settings component is intended to limit the availability of the provided number slider to a specific beverage. A size number component with source: COFFEE should only be available when Coffee is selected (should be reported by the status text-sensor).
A beverage setting component with source ANY should be available on any type of beverage.

@quack3d are there any other problems? Do all buttons, beverage settings (per type) and possible states of the status sensors work?

[quack3d]

Everything seems to work for me. But I haven't tested the buttons for AQUA_CLEAN and CALC_CLEAN - and I don't want to. 😊

[TillFleisch]

Everything seems to work for me.

Great, thank you!

But I haven't tested the buttons for AQUA_CLEAN and CALC_CLEAN - and I don't want to. 😊

That is totally fine and understandable. If you want, you can verify that the codes used in the PR draft match those retrieved via debugging when using them manually (IIRC a short press on those buttons does nothing). If they are matching, they should work like the others.

[poldim]

I tested now with @poldim's setup above but with different tx pins, rx pins, power pin and without power_trip_delay. After hitting Power the machine starts and status becomes 'Idle' after a bit like it should. @poldim But in your setup you don't have SELECT_COFFEE so the 'Coffee beans' and 'Coffee size' is not intended to work (if I understand @TillFleisch's intention here). You need to specify source to 'ANY' (or simply remove 'source: COFFEE') for them to work with all beverages. Otherwise you need one for each source like this one for Americano:

  - platform: philips_coffee_machine
    type: bean
    name: "Americano beans"
    controller_id: philip
    status_sensor_id: philips_coffee_machine_status
    source: AMERICANO

I changed my yaml to source: ANY for both of the numbers but they still did nothing. So I think your assumption that something is different between the models might be correct.
I also noticed that hitting Select Americano is near instant (similar to my code's presses) while Select Hot Water has a delay of 2-3 seconds. This is the only button where I've seen this kind of delay between the button press in esphome and the machine's action.

I also confirmed that my code allows me to manually control each of the functions correctly. My code doesn't have any logic, but the machine receives and acts on each button press correctly.

button:
  # - platform: philips_action_button
  #   controller_id: philip
  #   action: MAKE_COFFEE
  #   name: "${friendly_name} Make Coffee"
  #   icon: mdi:coffee

  # - platform: philips_action_button
  #   controller_id: philip
  #   action: MAKE_LATTE
  #   name: "${friendly_name} Make Latte"
  #   icon: mdi:coffee

  - platform: philips_action_button
    controller_id: philip
    action: SELECT_COFFEE
    name: "${friendly_name} Select COFFEE"
    icon: mdi:coffee

  - platform: philips_action_button
    controller_id: philip
    action: SELECT_ESPRESSO
    name: "${friendly_name} Select ESPRESSO"
    icon: mdi:coffee

  - platform: philips_action_button
    controller_id: philip
    action: SELECT_AMERICANO
    name: "${friendly_name} Select AMERICANO"
    icon: mdi:coffee

  - platform: philips_action_button
    controller_id: philip
    action: SELECT_CAPPUCCINO
    name: "${friendly_name} Select CAPPUCCINO"
    icon: mdi:coffee

  - platform: philips_action_button
    controller_id: philip
    action: SELECT_LATTE
    name: "${friendly_name} Select LATTE"
    icon: mdi:coffee

  - platform: philips_action_button
    controller_id: philip
    action: SELECT_HOT_WATER
    name: "${friendly_name} Select HOT WATER"
    icon: mdi:tea

  - platform: philips_action_button
    controller_id: philip
    action: PLAY_PAUSE
    name: "${friendly_name} Select PLAY / PAUSE"
    icon: mdi:play-pause

  - platform: philips_action_button
    controller_id: philip
    action: BEAN_AMOUNT
    name: "${friendly_name} Select BEAN_AMOUNT"
    icon: mdi:play-pause

  - platform: philips_action_button
    controller_id: philip
    action: WATER_AMOUNT
    name: "${friendly_name} Select WATER_AMOUNT"
    icon: mdi:play-pause

  - platform: philips_action_button
    controller_id: philip
    action: FROTHED_MILK_AMOUNT
    name: "${friendly_name} Select FROTHED_MILK_AMOUNT"
    icon: mdi:play-pause

[TillFleisch]

I also noticed that hitting Select Americano is near instant (similar to my code's presses) while Select Hot Water has a delay of 2-3 seconds.

This sounds like intended behaviour. Within the CI test files the Hot Water option has long press enabled, which has this exact effect.

I guess the status sensor is not updated properly. Does it show something like Coffee selected when you've selected one of the beverages and Idle after powering on/cleaning?

[poldim]

I also noticed that hitting Select Americano is near instant (similar to my code's presses) while Select Hot Water has a delay of 2-3 seconds.

This sounds like intended behaviour. Within the CI test files the Hot Water option has long press enabled, which has this exact effect.

Not sure on the EP3243 / EP3246 variants, but my EP3241 hot water is not a long press type of input. Looking at googled images, the user interface appears identical between the three.

I guess the status sensor is not updated properly. Does it show something like Coffee selected when you've selected one of the beverages and Idle after powering on/cleaning?

It just stays on off the entire time and does not change to anything else.

[TillFleisch]

Hot water is also a short press button on the other machines. The CI configuration has the long_press option set as a test case. This configuration doesn't actually make any sense.

Out of curiosity: Can you generate a log with messages form the mainbooard to the display (Mainboard UART, direction: RX)?

[poldim]

Hot water is also a short press button on the other machines. The CI configuration has the long_press option set as a test case. This configuration doesn't actually make any sense.

Yea, I think only the clean buttons need the long press

Out of curiosity: Can you generate a log with messages form the mainbooard to the display (Mainboard UART, direction: RX)?

Log: https://drive.google.com/file/d/16jwNCjNT1BRdtC6zLpgdCc6afMipGSlf/view?usp=sharing
Video of what I pressed when: https://photos.app.goo.gl/c4Dsf7BhDLq47HtS8

LMK if you need anything else

[TillFleisch]

The logs contain messages going from the display to the mainboard (based on the message length and >>>). I was originally interested in messages going the other way (mainboard, direction: RX), to find out why the status sensor is not working. Interestingly enough, the commands used are different from the other machines. Here is what I could recover from the logs/video (assuming I made no mistake, the video was very helpful):

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]

The good news is most of the stuff works, the bad news is that the new stuff for this machine (beans/size) don't work.
Selecting any value didn't do anything on the machine. It stayed at the original 2 dots on both beans and size.
Status also didn't work.

It's interesting to see that the commands from the EP3243 also work on the EP3241. The message content seems to be byte (8-10), they seem identical on the first look. The coffee selection (08 00 00) is even idential across all machines (including the EP2220).

I'm starting to think that bytes 5-7 (within messages from the display) are used as version indicators:
On my EP2220, they are always set to:
0x02, 0x00, 0x02
On the EP3243, they are always set to (seems to be the same on the EP3246 based on messages from this issue):
0x03, 0x00, 0x0E
On the EP3241, they are always set to:
0c03, 0c00, 0x12

Anyhow, now that we know the machines are different for certain, we should move the EP3241 related discussion elsewhere. (To figure out why the status sensor isn't working)