Trouble turning On

[mikulik86]

Hi and thank you so much for this awesome project!

I set it up on my Philips Series 2200 and everything works except one thing. Quite often (maybe 50% cases) when I turn the ON switch, the machine wont turn on and the switch returns into the OFF state. I would repeat the procedure a few times and maybe after 9 tries it finally works and the machine turns on (sometimes more, sometimes less).
But when after an unsuccessful attempt I push any button, e.g. Select Hot Water, the ON switch works immediately again.
Log attached: logs_coffeemaker_logs.txt

I hope you can help me resolve this issue. Thank you.

[TillFleisch]

I have experienced a similar issue after one of the ESPHome updates. The latest changes addressed this by performing the power trip multiple times. I've tested this on my machine and it resolved the issue, but your setup may be different.

[21:26:21][D][philips_power_switch:089]: Performed 1 power trip(s).

This should show more than one attempt if the display does not start communicating (turn on).

I would recommend the following things for trouble shooting this issue:

• check wiring (all grounds connected, uart pins correctly labeled)
• reduce logging, Observing the logs via Wi-Fi makes the ESP run slower. You can also try lowering the logging level
• increase power_trip_delay to i.e. 1 second
• add uart debug logging for messages from the display, to observe when/how it communicates during failed attempts (it should only communicate when the display is on, at least that's what it does on my unit)

What transistors/mosfet are you using?

[mikulik86]

I'm using MOSFET FQP30N06.
power_trip_delay increased to 2000 ms, no effect.

With uart debug logging looks failed attempt like this:
[01:11:51][D][switch:012]: 'Power' Turning ON.
[01:11:53][W][component:214]: Component esphome.coroutine took a long time for an operation (2.00 s).
[01:11:53][W][component:215]: Components should block for at most 20-30ms.
[01:11:53][D][philips_power_switch:089]: Performed 1 power trip(s).
[01:11:53][D][switch:055]: 'Power': Sending state ON
[01:11:53][D][uart_debug:114]: <<< 00:D5:55:00:01:00:00:02:00:00:00:01:14:D5:55:00:01:00:00:02:00:00:00:01:14:D5:55:00:01:00:00:02:00:00:00:01:14
[01:11:53][D][switch:055]: 'Power': Sending state OFF

[mikulik86]

Btw. don't you have a typo here: https://github.com/TillFleisch/ESPHome-Philips-Smart-Coffee/blob/main/protocol.md#messages-from-the-display-to-the-mainboard-1 ?
Didn't you mean "from the mainboard to the display"?

[TillFleisch]

D5:55:00:01:00:00:02:00:00:00:01:14

This message looks new to me, otherwise I would have noted it in the documentation you've linked (which does contain a typo).

The display is responding, which makes the component think it's powered on, therefore it does not try to perform the power trip multiple times. Can you verify using a voltage meter that the voltage on the display side drops out. I would recommend setting up a separate GPIO output pin component to toggle the power pin state manually.

[mikulik86]

I don't think that the problem is in the power trip because, as I wrote before, after i push any of the buttons the power ON switch immediately works after that.
Also if the display was not turning on, one could hear that the rest of the machine would turn on. But there is nothing turning on.
Also i confirmed that the power trip works with voltage measurement.

Could you plese explain what is the purpose of the pre-power on message?

[mikulik86]

The UART log configured like this:

# UART connected to the display
  - tx_pin: GPIO15
    rx_pin: GPIO13
    baud_rate: 115200
    id: uart_display
    debug:
      direction: RX
      after:
        bytes: 12

shows right after powering on from the touch panel this:

[21:54:16][C][api:139]: API Server:
[21:54:16][C][api:140]:   Address: 192.168.1.11:6053
[21:54:16][C][api:142]:   Using noise encryption: YES
[21:54:21][D][uart_debug:114]: <<< D5:55:01:01:00:00:02:00:00:00:35:05
[21:54:21][D][uart_debug:114]: <<< D5:55:01:01:00:00:02:00:00:00:35:05
[21:54:21][D][switch:055]: 'Power': Sending state ON
[21:54:21][D][uart_debug:114]: <<< D5:55:01:01:00:00:02:00:00:00:35:05
[21:54:21][D][uart_debug:114]: <<< D5:55:01:01:00:00:02:00:00:00:35:05
[21:54:21][D][uart_debug:114]: <<< D5:55:01:01:00:00:02:00:00:00:35:05
[21:54:21][D][uart_debug:114]: <<< D5:55:01:01:00:00:02:00:00:00:35:05
[21:54:21][D][uart_debug:114]: <<< D5:55:01:01:00:00:02:00:00:00:35:05
[21:54:21][D][uart_debug:114]: <<< D5:55:01:01:00:00:02:00:00:00:35:05
[21:54:21][D][uart_debug:114]: <<< D5:55:01:01:00:00:02:00:00:00:35:05
[21:54:21][D][uart_debug:114]: <<< D5:55:01:01:00:00:02:00:00:00:35:05
[21:54:21][D][uart_debug:114]: <<< D5:55:01:01:00:00:02:00:00:00:35:05
[21:54:21][D][uart_debug:114]: <<< D5:55:01:01:00:00:02:00:00:00:35:05
[21:54:21][D][uart_debug:114]: <<< D5:55:01:01:00:00:02:00:00:00:35:05
[21:54:21][D][uart_debug:114]: <<< D5:55:01:01:00:00:02:00:00:40:4D:C1
[21:54:21][D][uart_debug:114]: <<< D5:55:01:01:00:00:02:00:00:00:35:05
[21:54:21][D][uart_debug:114]: <<< D5:55:01:01:00:00:02:00:00:00:35:05
[21:54:21][D][uart_debug:114]: <<< D5:55:01:01:00:00:02:00:00:00:35:05
[21:54:21][D][uart_debug:114]: <<< D5:55:01:01:00:00:02:00:00:00:35:05
[21:54:21][D][uart_debug:114]: <<< D5:55:01:01:00:00:02:80:00:35:05:D5
[21:54:21][D][uart_debug:114]: <<< 55:00:01:00:00:02:00:00:00:01:14:75
[21:54:21][D][uart_debug:114]: <<< 55:40:00:02:00:00:00:01:14:D5:55:00
[21:54:22][D][uart_debug:114]: <<< 01:00:00:02:00:00:00:01:14:D5:55:00
[21:54:22][D][uart_debug:114]: <<< 01:00:00:02:00:00:00:01:14:D5:55:00
[21:54:22][D][uart_debug:114]: <<< 01:00:00:02:00:00:00:01:14:D5:55:00
[21:54:22][D][uart_debug:114]: <<< 01:00:00:02:00:00:00:01:14:D5:55:00
[21:54:22][D][uart_debug:114]: <<< 01:00:00:02:00:00:00:01:14:D5:55:00
[21:54:22][D][uart_debug:114]: <<< 00:00:00:01:14:D5:55:01:00:00:00:14
[21:54:22][D][uart_debug:114]: <<< D5:55:00:01:00:00:02:00:00:00:01:14
...

Does that mean, that my machine uses different power on message?

[mikulik86]

I think I figured it out. I increased MESSAGE_REPETITIONS to 24 in power.h and now it seems to be working reliably.

[TillFleisch]

Sorry for replying this late, I'm currently quite busy.

after i push any of the buttons the power ON switch immediately works after that.

This behaviour (machine on, display off) is exactly what happens if the power trip fails. Since there is no command for tuning on the display we need to perform the power trip in hopes of turning it on. (Multiple times if we don't succeed at firsts)

Could you plese explain what is the purpose of the pre-power on message?

We imitate what the display does when tuning on the machine. It sends multiple commands to turn on the motherboard. I have captured these using the UART debug functionality. The name 'pre-power on' was chosen arbitrarily as the following command actually turns on the machine. (Note that without the pre-poeer on message, the power on message won't work)

Does that mean, that my machine uses different power on message?

That may be the case. As pointed out in the related projects section (readme), the project from chris7topher uses different commands. This may be due to different hardware/firmware revisions of the coffee machine. I don't for sure.

I think I figured it out. I increased MESSAGE_REPETITIONS to 24 in power.h and now it seems to be working reliably.

That sound great, maybe one of the power on messages does not arrive at the mainbooard properly. Requiring multiple message repetitions points towards a possibly noisy communication on the bus. I would recommend double checking the wiring and making sure everything is grounded properly. Can you observe garbled message on the buses?

[mikulik86]

Thanks for comprehensive answer.

This behaviour (machine on, display off) is exactly what happens if the power trip fails. Since there is no command for tuning on the display we need to perform the power trip in hopes of turning it on. (Multiple times if we don't succeed at firsts)

I still don't understand one thing. How come when i eliminate the power trip (set an unused pin), the machine still turns on. Just the display stays off. But for me was neither machine, nor display turning on. Doesn't this behavior suggest that there is something wrong with the communication, rather than with the power trip?

That sound great, maybe one of the power on messages does not arrive at the mainboard properly. Requiring multiple message repetitions points towards a possibly noisy communication on the bus. I would recommend double checking the wiring and making sure everything is grounded properly. Can you observe garbled message on the buses?

I also noticed that to turn on using the touch panel, I have to hold the power button slightly longer, than the other buttons when choosing a drink etc. I suspect that the display controller repeatedly sends the respective message as long as the touch button is pressed. Can you confirm this?

[TillFleisch]

I suspect that the display controller repeatedly sends the respective message as long as the touch button is pressed. Can you confirm this?

Yes, the display repeatedly sends a messages as long as any button is pressed. This method is used to 'encode' (not really) long button presses.

How come when i eliminate the power trip (set an unused pin), the machine still turns on. Just the display stays off.

This is the expected behavior. The power trip is only used for the display. The mainboard is turned on using serial communication. I doubled checked this on my machine just now (using a different pin for power_pin) and the mainboard (in other words the machine) turns on and the display remains off. Pressing the power button afterwards immediately wakes up the display unit.

But for me was neither machine, nor display turning on. Doesn't this behavior suggest that there is something wrong with the communication, rather than with the power trip?

This could very well be the case. The display being unresponsive/slow, also suggestes that multiple messages must be sent until a valid message arrives at the mainboard. Noise on the bus could interfere with the power on message generated by the ESP which would result in neither the display nor the mainboard turning on. (If I recall correctly, the display also requires messages from the mainboard aside from the power trip to sucessfully turn on)
I would recommend double checking your wiring and using the UART Debug functionality to determine if there are garbled messages on the (mainbaord side) bus.

[mikulik86]

The display being unresponsive/slow, also suggestes that multiple messages must be sent until a valid message arrives at the mainboard. Noise on the bus could interfere with the power on message generated by the ESP which would result in neither the display nor the mainboard turning on. (If I recall correctly, the display also requires messages from the mainboard aside from the power trip to sucessfully turn on) I would recommend double checking your wiring and using the UART Debug functionality to determine if there are garbled messages on the (mainbaord side) bus.

I don' think that this is an issue. Seems to me more like a feature that was added in my revision of the machine. Because all other buttons work ok with default repetition count. Also when display connected directly to MB (no ESP in the middle) the power button still needs a longer press for machine to turn on, even though other buttons react immediately, including power button when turning off.

Anyways, I'm glad that it works now. And thank you so much for your patient assistance.

[TillFleisch]

#39 returns the default repetition value back to 5 and provides configuration of this value via the YAML configuration.